gnu-octave / symbolic

A Symbolic Package for Octave using SymPy
https://octave.sourceforge.io/symbolic/
GNU General Public License v3.0
152 stars 36 forks source link

release: Sign release with GPG #1203

Open alexvong243f opened 2 years ago

alexvong243f commented 2 years ago

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.

alexvong243f commented 2 years ago

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
cbm755 commented 2 years ago

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?

cbm755 commented 1 year ago

Is this something you can do post-release?

alexvong243f commented 1 year ago

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:

pub   rsa4096/0x4E2C6E8793298290 2014-12-15 [C] [expires: 2025-07-21]
      Key fingerprint = EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290
uid                   [ unknown] Tor Browser Developers (signing key) <torbrowser@torproject.org>
sub   rsa4096/0xE53D989A9E2D47BF 2021-09-17 [S] [expires: 2023-09-17]

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.

alexvong243f commented 1 year ago

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.