Repository navigation
GPG signatures for source validation #612
Description
As we all know, today more than ever before, it is crucial to be able to trust
our computing environments. One of the main difficulties that package
maintainers of Linux distributions face, is the difficulty to verify the
authenticity and the integrity of the source code.
The Arch Linux team would appreciate it if you would provide us GPG signatures
in order to verify easily and quickly your source code releases.
Overview of the required tasks:
- Create and/or use a 4096-bit RSA keypair for the file signing.
- Keep your key secret, use a strong unique passphrase for the key.
- Upload the public key to a key server and publish the full fingerprint.
- Sign every new git commit and tag.
- Create signed compressed (xz --best) release archives
- Upload a strong message digest (sha512) of the archive
- Configure https for your download server
GPGit is meant to bring GPG to the masses.
It is not only a shell script that automates the process of creating new signed
git releases with GPG but also comes with this step-by-step readme guide for
learning how to use GPG.
Additional Information:
- https://github.com/NicoHood/gpgit
- https://help.github.com/categories/gpg/
- https://wiki.archlinux.org/index.php/GnuPG
- https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
- https://www.qubes-os.org/doc/verifying-signatures/
- https://lkml.org/lkml/2016/8/15/445
- https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https
- https://www.enigmail.net/index.php/en/
Thanks in advance.
PS: I plan to use this module in gpgit soon. However this and #611 is a blocking issue for this to happen. Would be really nice to see gpg signatures as well as this project part of gpgit.
Activity
Byron commentedon Apr 9, 2017
Thanks for offering your help in increasing the trustworthyness of GitPython releases! For now this is only assured by github, as it allows only a few select people to push into this repository.
I will just generate a new key and see how far I get :).
NicoHood commentedon Apr 23, 2017
This would be highly appreciated as currently we cannot fully trust the downloads. GPG would be much of a help.
Byron commentedon Apr 24, 2017
For a start, here is my public gpg key. I have made it known to github will use it to sign all my commits from now on.
So far I have never produced archives for use in distribution. In that area I would need a few more hints on how you suggest this should be accomplished. Personally I would be happiest if the current machinery using
pipcan be used to produce signed archives for download from pip.What do you think about that?
For completeness, find below my public gpg key.
Details
ankostis commentedon Apr 24, 2017
@Byron
twineshould be your one-stop solution for uploading to PyPi repo.NicoHood commentedon Apr 24, 2017
thanks! twine looks good for pypi. Please use gpgit for the github source tarballs and everything will be good to go :)
Byron commentedon Jun 10, 2017
@NicoHood There are no source-tarballs on github and I wasn't planning to release it that way. Pypi provides tarballs as well along with signatures.
Thus I will be closing this issue and hope you will be alright.
NicoHood commentedon Jun 13, 2017
@Byron Thanks. There are always auto generated github source tarballs. But it is more secure to generate your own (for example with GPGit).
Please also sign gitdb and smmap:
https://pypi.python.org/pypi/gitdb
https://pypi.python.org/pypi/smmap/0.9.0
Also the pypi versions seem to be outdated. On Github you have smmap 2.0.3 and on pypi 0.9
Byron commentedon Jun 17, 2017
Thanks for the clarification! To keep things simple though, I would like to refer people to the signed tarballs on pypi instead.
On the other note,
gitdbandsmmapare old packages owned by an account I am unable to access anymore, so thegitdb2andsmmap2packages have been created instead. They are signed by now as well :).NicoHood commentedon Jun 17, 2017
@Byron No the pypi guys can NOT sign the tarballs. The idea behind signing is security, not having a signature. If you upload it to them, they cannot verify if its uploaded really by you (account compromised etc). You need to sign it always in order to have the trustchain way up to the end user.
We as package maintainer package the software and sign them with our gpg keys which are trusted by the Archlinux keyring. However we also need to have a signature from you that we trust. So in the end the user trusts us (package maintainers) and also you. If you add another spot (pypi signatures) makes it less secure. And you cannot avoid signing your sources anyways. There is no way around that you sign the sources that you develop.
Byron commentedon Jun 17, 2017
@NicoHood I think I understand exactly what you mean. This is also why I am confused - after all the tarball/binaries I upload (see screenshot) ship with a signature I created. Once you have trusted the key that signed them is truly mine, you can verify the tarball was created by me.
However, your comment seems to indicate that you cannot trust or use the files provided on pypi.
To my mind this works fine, as I tried it myself and wrote about it in the readme.
Is there something I don't see?
NicoHood commentedon Jun 17, 2017
It is all fine now unless you keep your key secret with a strong passphrase.
We do not need to trust pypi, as your sources are signed now. But if they would resign them with their key (as you suggested) this would be bad. As we need to trust them, that they verify your software correct. Its just another risk in the chain we want to avoid. As it is right now, it is perfect. Thanks a lot!
NicoHood commentedon Dec 23, 2017
@Byron The GPG key used for signing the gitpython tarballs has recently changed. In order to verify the sources properly we cannot blindly trust the new key. Can you please give me some more information why the key changed and which fingerprint is the new one? It would be best to write the key down somewhere in the readme. In the current readme the old key is still present.
This is the old key:
4477ADC5977D7C60D2A7E3789FEE1C6A3B07188Fmakepkg reports me the new (short) keyid:
665F99FA9D99966Cwhich is not found on a keyserver.Edit: talking about the signature for release 2.1.8
Byron commentedon Dec 23, 2017
@NicoHood That's true! I changed my key in this commit (c7f657f) as my previous one was susceptible to that new attack which derives the private key from a public key. Thus I generated new keys in software and placed them on my yubikey. Indeed, my previous key was revoked without a reason, but I think it was just me missing that flag on the command-line.
Additionally I tried to understand why the alleged signing key fingerprint is
665F99FA9D99966C, and realized that this is the fingerprint of my signing subkey. What worked for me is to import my most recent master key (via my email address, or by importing the signing key file) and list the key in all details viagpg --with-colons --list-key 2CF6E0B51AAF73F09B1C21174D1DA68C88710E60.You will also find that all my commits are signed with the new key already.
I hope that helps.
NicoHood commentedon Dec 23, 2017
Alright. Make sure to also edit the readme then with the new key :)
Update README with new key fingerprints
Byron commentedon Dec 23, 2017
@NicoHood Thanks a lot for hinting at it once again :)! Totally forgot that was there :D!
NicoHood commentedon Jul 8, 2018
The gpg key got revoked. See gitpython-developers/smmap#36 (comment)
Please reopen or fix the issue.
Byron commentedon Jul 15, 2018
Sorry for the late reply. I have published version 2.1.11 with my most recent key in the hopes that this fixes the issue you encountered.
Update README with new key fingerprints