Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code-signing support (Not Apple Code-signing) #58

Open
shannah opened this issue Apr 8, 2022 · 0 comments
Open

Code-signing support (Not Apple Code-signing) #58

shannah opened this issue Apr 8, 2022 · 0 comments

Comments

@shannah
Copy link
Owner

shannah commented Apr 8, 2022

In order to address security concerns of some users (e.g. #57 ), we should add the option to produce signed apps. I'm not talking about Apple Code-signing - I'm talking about a cross-platform approach that would allow the user to verify the origin of all code running in an app.

How it works

  1. The developer has the option to enable "code-signing" in the package.json file. (Would need to think of word that doesn't confuse it with Apple's code-signing).
  2. With code-signing enabled, the "package" action would use the developer's private key to sign all bundles produced: the installer, the app bundles, and the payload that is published on npm. If they don't have a private key, it will auto-generate a key-pair and store them in a standard location on the developer's machine.
  3. With code-signing enabled, the "package" action would download and embed the JVM directly in the installer and app bundles, and sign them.
  4. With code-signing enabled, the "publish" action would publish the sha1, sha256, md5 hashes for the installer bundles to trusted feed locations, such Twitter, or GitHub.
  5. When the user downloads the installer from either the developer's website, GitHub, or jDeploy.com, they can manually verify it against the hash, and the developer's public key, which could be published in a trusted location, or simply provided to the user out of band.
  6. When the launcher downloads updates from the cloud (e.g. npm), it can compare the signature of the payload against the signature of the app launcher to ensure that they match.
  7. No JVM downloads occur in this scenario because the JVM is embedded into the app bundle.

Draw-backs of this approach

  1. Bundles will be much larger due to embedded JVM.
  2. Space complexity for hosting is exponentially larger for jDeploy.com. Currently all apps use the same installer, so jDeploy.com doesn't actually need to store installer bundles for each app. It just uses the same installer and adds appropriate metadata. With this approach, each app bundle needs to be pre-built and stored somewhere. It might make sense to integrate this with github actions and bind it to the github release process so that the installer bundles are automatically uploaded as artifacts of GitHub releases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant