-
Notifications
You must be signed in to change notification settings - Fork 37
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
release: Sign release with GPG #1203
Comments
Is it alright if I add the following line to https://github.com/cbm755/octsympy/releases/tag/v3.0.1 and upload the corresponding signature? This should be harmless as far as I can tell but I could have overlooked something... --- a
+++ b
@@ -6,6 +6,8 @@ Octave users can usually install with `pkg install -forge symbolic` (from within
**CAUTION**: SHA256 hash should almost always be used. [MD5](https://en.wikipedia.org/wiki/MD5) is [cryptographically](https://crypto.stackexchange.com/questions/2994/what-is-the-recommended-replacement-for-md5) [broken](https://security.stackexchange.com/questions/19906/is-md5-considered-insecure). MD5 hash is provided for compatibility only.
+All uploaded files are signed with the PGP subkey `EF2811198AE14716DF2AE3F26D40BA0E3BE60105` which belongs to one of the co-maintainers. The corresponding public key can be downloaded [here](https://***.***/***).
+
### Octave package: symbolic-3.0.1.tar.gz
md5: 579bd589f6189315c5aebd8cd0779d3e |
Sounds fine to me, the only downside I can think of is if I do a release and it doesn't have this than maybe that sets up alarm bells for someone... But I guess that can be revolved by documenting this a bit in the HOWTO-release file? |
Is this something you can do post-release? |
Sure, I can do it. There're basically 2 approaches. One is to use my own key to sign the package. The other way is to generate a new key pair and then use it to sign the package, e.g. the Tor Project uses the following key:
I think the 2nd approach is the more modern one but the 1st approach could be a bit simpler. I can also share the private key with you via private message if the 2nd approach is used. |
In the original post, I had the 1st approach in mind. But after thinking about it again, I realise that might not be the modern approach. |
I think I can do it. Right now I'm already signing all my commits, so basically it takes no extra effort to sign the releases (as co-maintainer) using the same key.
Since I don't use PGP's web of trust, the authentication scheme for my key will be TOFU (trust on 1st use). What it means is that during the 1st verification, users will download my key from the internet, (blindly) trust it to be authentic and use it to verify the release. On subsequent verifications, users will use the key downloaded previously to verify new releases. This way we only need to take the risk during the 1st verification. If nothing goes wrong, subsequent verifications will be secure.
The text was updated successfully, but these errors were encountered: