Security concerns

[mipastgt]

jDeploy is an interesting concept, but I am a bit concerned about the security aspects. Things like code signing and notarization give you at least some basic security and also give you the possibility to trace the origin of a software. jDeploy seems to bypass this completely as far as I understand the concept.

[shannah]

Valid concerns, and definitely areas that need to be developed. I have put together a crude diagram that lays out the different pieces of jDeploy. I'll refer to it throughout this post.

The diagram shows three actors: jDeploy, the App developer, and the app User. However there are two others to consider that aren't included in the diagram: The JVM distribution provider (Azul right now, but could be expanded to others later), and "the network".

I'll start with three core actions that the end user performs, and discuss who she has to trust for each of them.

1. Downloading the app from jDeploy.com
   No explicit trust is required for this step because it is simply downloading a tar.gz archive through the web browser. However, this step will impute a trust requirement on the installation step: They must trust jdeploy.com that the package they receive is "safe".

2. Running the App Installer.
   The installer launcher is codesigned by jDeploy (Me) when run on Mac --> So she is trusting jDeploy.
   The installer downloads the appropriate version of the launcher from npm. --> She is trusting jDeploy, npm, and "the network".
   The installer downloads the appropriate JVM to run the installer app. --> She is trusting JVM provider, and "the network".

3. Running the App.
   The app launcher was installed by the installer - this she is trusting the installer step.
   The app launcher downloads the appropriate version of the app from npm --> She is trusting the app developer, npm, and "the network"
   The app launcher downloads the appropriate JVM to run the app. --> She is trusting JVM provider, and "the network".

So, with the current configuration, the circle of trust includes:

1. jDeploy
2. npm
3. The App Developer
4. The JVM provider
5. The network

Reducing the size of the circle of trust

The best case scenario for the circle of trust is for the user to trust only one party: The App Developer. This is achieved using conventional distribution (e.g. jpackage) by including the entire app inside a single bundle, which is signed by the app developer's private key. Mac will enforce this trust by refusing the run the app if the bundle has been tampered with. This would require giving up most of the benefits of jDeploy, so I'll discuss a range of strategies that can reduce the size of the circle of trust, but can still retain the benefits of jDeploy.

The two main "features" that I want to preserve are:

1. Ease of deployment. (not having to spend too much time futzing with certificates every time I want to publish an app).
2. Auto-updates

These goals run counter to the goals of security, but I think there is a happy medium.

Removing npm and jdeploy from the circle of trust

The easiest members to expel from the circle of trust are npm and jDeploy. There are a few ways to accomplish this:

Strategy 1: Self Hosting:

1. The app developer signs and notarizes the installer with his own apple developer account. There are two difference scenarios for this:
   1.1. The app developer signs all of the app installers separately.
   1.2 The app developer signs only the installer, and the reuses this installer for all of the apps. This requires keeping a central registry on the app developer's website (or somewhere accessible at the time the installer is run), but makes the deployment of each individual app much easier.
2. The app developer generates the installers himself and publishes them on either github or on their website. This can be automated with GitHub actions for convenience.
3. The app developer sets up either a private npm repository where he publishes his app updates - or we add self-hosting option for updates.

Under this scenario, the circle of trust becomes: The network, the JVM provider, and the App developer.

Strategy 2: Codesigning

We could develop a codesign strategy similar to Apple's codesign, and have the launcher verify signatures of all bundles that it downloads against signatures that the App developer verifies. The app developer could sign the installer bundle, and all npm bundles with their private key, and publish a public key that users could use to verify that the installer, and app, and app bundles are signed. This could be baked into the App launcher itself, to verify all updates against the app developer's public key.

These changes would still allow us to use npm and jdeploy.com for the download page because the software could be verified by signature. I.e. we reduce the circle of trust to: The app developer and the JVM provider

To remove the JVM provider from the circle of trust, we would need to either bundle the JVM in the installer, or pin the app to a particular JVM bundle. Both of these are undesirable because it either increases bundle size, or decreases our flexibility for choosing a compatible JVM at runtime.

Strategy 3: a la carte

Perhaps a mix of these strategies to achieve a sweet spot.

[mipastgt]

What means do you have to ensure a valid identity of the software developer?

[shannah]

What means do you have to ensure a valid identity of the software developer?

Currently, none.

I think the best solution would be to have the software developer publish their public key, or share their public key with their users, and then the user could verify the identity that way.

I can imagine other strategies, but what mechanism would you suggest?

[mipastgt]

I don't know but being able to trust the given identity of the developer is a crucial part of the trust in the overall process. I have to assume that if the developer can stay completely anonymous he can commit any crime he wants and none of the other technical means could prevent that. But maybe we could hear some more voices on this issue.

[shannah]

What is your normal strategy for ensuring developer identity for software that you run? The same could probably be employed with jDeploy.

Personally, I'm usually satisfied that if I download a file from the dev's website or other "trusted" source, like their Twitter feed, facebook, github, etc.., that it is from the developer. In reality, I know that this isn't bullet-proof, as it is possible that I accidentally went to a phishing site, or that there was a MITM attack and i'm not getting what I think I'm getting. This is why some guys post a hash to compare against the file - but then how do I know that the hash I got from their website wasn't also hit by MITM.... and on...

The only "sure way" if the stakes are high, would be to get the public key before hand in person, and use it to validate signatures on every bundle that is downloaded over the network. But I've never done that. I've generally don't compare the hashes when they are available either. Maybe I should.

[mipastgt]

What is your normal strategy for ensuring developer identity for software that you run?

Well, I think I have a similar strategy as you have. For me there are two main aspects.

1. I need to trust the developer.
2. I need to be sure that what I download and install was actually produced by this developer.

For point 2 a technical solution like self hosting and/or code signing may be sufficient although not perfect as you have already stated.

Point 1 is more difficult. I often try to find out what the track record of this developer is. Is he well known on public channels? Has the software been reviewed, recommended by others? So the key feature is to be able to securely associate a trusted identity with some piece of software without making the whole process too cumbersome for the user.

[shannah]

I have opened an RFE in the issue tracker that describes a way forward for addressing these security concerns.

#58

[shannah]

The next release of jDeploy installer will display the following prompt when the user presses "Install".

By default the "verified website" will just be the project page on https://www.npmjs.org/package/YOURPACKAGENAME

If you place a hash into your actual homepage, then it will display your homepage instead. jdeploy publish will generate the following hashes on each deploy:

1. applicationSignature (unique to the application, but same for all versions)
2. versionSignature (each version will have unique signature)

If the installer finds any of these hashes on your app's homepage, then it will display that home page as the "verified" homepage.

The idea is to prevent a bad actor from publishing a malware app and claiming that they are someone else. Users will at least have the opportunity to inspect the website of the developer before proceeding with the installation to make sure it is legit.

This is the first of a progression of new security features I will be implementing.

[mipastgt]

I like this idea. I just don't like the default behaviour. It suggests that the project page on npmjs is somehow verified too which actually is not the case. I'd rather prefer a warning that this is a piece of software with no verified external home. Everybody who deploys some software via jdeploy should be able to provide some kind of external home as a reference. This could, e.g., just be the GitHub repository of the software. I think this is important to build up trust in this platform. Personally I would even go so far to not allow a deployment without external home.

[shannah]

It suggests that the project page on npmjs is somehow verified too which actually is not the case.

How is a github repository any more verified than an npmjs project page? The point of this is to allow the user to reason about where the software came from. The npmjs project page is always a verified source because that's where jdeploy downloads it from.

Personally I would even go so far to not allow a deployment without external home.

One of my main goals of jdeploy was to eliminate the friction involved in building and deploying desktop apps. Adding a requirement to verify against website goes against that. I agree that it is important to give users the ability to make an informed decision about whether it is safe to install an app - that's what this feature is supposed to address. The user can see what website claims responsibility for the app, and then they can decide if they trust that site.

[mipastgt]

1. Maybe I misunderstood the role that npmjs is playing here but my understanding was that the package on npmjs is created automatically by jdeploy when someone uploads a piece of software. If that's the case, then how is a npmjs project page tied to any specific person in any verifiable way? But anyway I would trust a link to a GitHub account much more because that's the place where the development goes on. I can check the crontributors, the issues, the history, even the source code and so on.
2. That's why I said "personally" :-)

[shannah]

Maybe I misunderstood the role that npmjs is playing here but my understanding was that the package on npmjs is created automatically by jdeploy when someone uploads a piece of software. If that's the case, then how is a npmjs project page tied to any specific person in any verifiable way?

The npm package is created automatically by jdeploy on publish, however you still need to have an npmjs.org account, and you need to be logged into this account to do the publish. As far as I can tell, accounts on npmjs.org have the same level of verification as accounts on github. I leave it up to the user to decide whether they trust that npmjs project page.

[mipastgt]

Ok, I misunderstood that point then.

[mipastgt]

Just some info on the verification aspect of GitHub accounts. There actually is a possibility for more verification than just creating an account. GitHub domain verification
An example where this is used is this:
https://pi4j.com/
https://github.com/Pi4J
See the verified label at the top.
I don't know if npmjs has a similar concept.