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.
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!
8 remaining items