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

release: Sign release with GPG #1203

Open
alexvong243f opened this issue Aug 9, 2022 · 5 comments
Open

release: Sign release with GPG #1203

alexvong243f opened this issue Aug 9, 2022 · 5 comments
Assignees
Milestone

Comments

@alexvong243f
Copy link
Collaborator

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
Copy link
Collaborator Author

alexvong243f commented Aug 12, 2022

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

@alexvong243f alexvong243f self-assigned this Aug 12, 2022
@cbm755
Copy link
Collaborator

cbm755 commented Aug 12, 2022

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
Copy link
Collaborator

cbm755 commented Mar 20, 2023

Is this something you can do post-release?

@cbm755 cbm755 added this to the 3.3.0 milestone Mar 20, 2023
@alexvong243f
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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.

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

2 participants