GPG signatures for source validation

[NicoHood]

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.

[Byron]

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]

This would be highly appreciated as currently we cannot fully trust the downloads. GPG would be much of a help.

[Byron]

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.

(1)	Sebastian Thiel (In Rust I trust!) <[email protected]>
	  4096 bit RSA key 9FEE1C6A3B07188F, created: 2017-04-24

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 pip can be used to produce signed archives for download from pip.

What do you think about that?

For completeness, find below my public gpg key.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: GPGTools - https://gpgtools.org

mQINBFj+MasBEACak+exWFzTyjtJfz1D7WgSSJ19ZW36IfAX4/E2cxLCZ/hFUPqE
+9EI0EsmysDs6m7eYk5TIIeqHlGtAQRcryTAMK7swd0ORGG0N7NJxAuc9cWomZII
I+vrQI0VcQGr1ovXROz7Zf6wuN2GLRpQm4p4CAA/bC6NRAEn9uTwmKrW/Xv+Hhro
QWznTgNsOCb4wu8BZs0UkH/9ZG67Jhf/5sqI9t6l7DcuSWy+BhGRQazgAslCY4rl
/9VL9LzsGiqXQJKIDdrQWVhCBDOknz8W0yxW/THc2HBMvh/YXG5NBDucXL6nKtUx
eLfQep8iHQy7TBSoyn5Gi0Wi7unBwSHKiBzI7Abby43j4oeYSdul7bVT+7q7sPqm
cWjZmj3WsVUDFjFRsHirjViLiqRuz7ksK5eDT9CneZM7mSomab+uofpKvRl67O9L
LmZ5YjEatWqps7mH80pLk0Y4g28AR3rDx0dyLPqMJVBKPZLIpG43bccPKjj6c+Me
onr6v5RimF5/rOqtIuw9atk4qzWQMtQIxj7keYGEZFtG8Uf7EIUbG/vra4vsBvzb
ItXAkASbLxxm5XQZXICPhgnMUcLi5sMw/KZ6AHCzE5SiO8iqEuU7p9PMriyYNYht
6C7/AOtKfJ46rPAQ6KEKtkAe5kAtvD2CAV/2PnBFirLa+4f6qMUTUnWmdwARAQAB
tDdTZWJhc3RpYW4gVGhpZWwgKEluIFJ1c3QgSSB0cnVzdCEpIDxieXJvbmltb0Bn
bWFpbC5jb20+iQI3BBMBCgAhBQJY/jGrAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4B
AheAAAoJEJ/uHGo7BxiPhsAP/jkPbYyUBQO9htkUudZeuv/wAPH5utedVgPHzoP6
ySMas/Se4TahwfBIEjAQwEeCwLPAERjNIALzt1WiQZ00GrYYQKqcus42wcfydYSQ
MPXznJ2RTtMvGRXs40sQrPXJimumElLDVROsOH6WWeBYaKHPrazI2zGzDPFKyUHI
v8VKzLVMRBgMKoud/l6l4MCVVOllMDDjkVHLYCUBQnoo/N2Z1WQXqvdIacUwb5sF
A0JTjO9ihFxK3JLm8qMXSi3ssYr99I3exqQm3kbwgUE6dZmT6xpm95uPsPEP0VVM
yjMfnanmbizZ0/Juvx2G597E+XS1P9S2gBXaF++lL3+OUr3FOkdw+HkLT0uAIvyT
AjMZnIOArftB6yPnh6rD3rMpeLuWsMn3deBrsvgFZHqOmSCT22VFM1J4A1qNrVyT
uBDXQIZkGGAv280mtBGhWD1ighShuQAJncRdo7zLx4ntf38O1EIe1GXhnuIuZrZ0
7nOOCMsDBufkE2lZOLtpgsygfOLmlwvC/7TgsO6mF08o1ugADYXpsr4PojXjM5rR
MMekoWGyO953oYhtotxtyjq7iRJVPDy04XY40IdAcmy7nFwG+2YMJtqHGSYTdMa1
pJbzJ+LDQDr7vL3vcm1UHcbs6LcJjHTHyy0waZGMjMHyVBxkE1QycQySp6iItnET
5vZ3uQINBFj+MasBEACZgcOJ5QYbevmBAcuW5jpyg8gfssGACK0HGtNXVVbEfU8h
FtuzFAtJzLq8Ji8gtP0Rvb+2OmaZHoz3xcWLvBRZwLMB+IOjD9Pfh75MdRjjZCkZ
haY9WcFw0xvEModweL61fNgga2Ou7cK/sRrbs0zcEXDNyOK+1h0vTOJ6V3GaL6X9
2ewM3P8qyuaqw9De3KJd2LYF814vtBd75wFsnxESrfxaPcjhYO0mOMBsuAFXF4VF
uPYxRUqQZj4bekavS/2YDLRe0CiWk6dS2bt9GckUxIQlY+pPAQ/x5XhfOtJH3xk/
SwP05oxy+KX20NXNhkEv/+RiziiRJM1OaDFnP2ajSMzeP/qYpdoeeLyazdlXbhSL
X8kvNtYmuBi7XiE/nCBrXVExt+FCtsymsQVrcGCWOs8YF10UGwTwkzUHcVU0fFeP
15cDXxHgZ2SO6nxxbKTYPwBIklgu0CbTqWYFhKKdeZgzPE4tBZXW8brc/Ld5F0WX
2kwjXohm1I9p+EtJIWRMBTLs+o1d1qpEO0ENVbc+np+yOaYyqlPOT+9uZTs3+ozD
0JCoxNnG3Fj3x1+3BWJr/sUwhLy4xtdzV7MwOCNkPbsQGsjOXeunFOXa+5GgDxTw
NXBKZp2N4CP5tfi2xRLmsfkre693GFDb0TB+ha7mGeU3AkSYT0BIRkB5miMEVQAR
AQABiQIfBBgBCgAJBQJY/jGrAhsgAAoJEJ/uHGo7BxiP8goP/2dh4RopBYTJotDi
b0GXy2HsUmYkQmFI/rItq1NMUnTvvgZDB1wiA0zHDfDOaaz6LaVFw7OGhUN94orH
aiJhXcToKyTf93p5H9pDCBRqkIxXIXb2aM09zW7ZgQLjplMa4eUX+o8uhhFQXCSw
oFjXwRRtiqKkeYvQZGJ0vgb8UfPq6qlMck9w4cB6NwBjAXzo/EkAF3r+GGayA7+S
0QD18/Y2DMBdNPIj8x+OE9kPiYmKNe9CMd2AQshH1g1fWKkyKugbxU9GXx+nh9RG
K9IFD6hC03E9jl7nb0l9I57041WKnsWtADb67xq+BIUY05l5vwdjviXKBqAIm0q3
/mqRwbxjH4jx26dXQbm40lVAR7rpITtMxIPV9pj0l1n/pIfyy/4I+JeAm6c1VNcN
bE06PCvvQKa9z3Y9HZEIvzKqFSWGsFVgMg5vqauYI/tmL/BSz49wFB65YBB1PsZm
sossuQAdzs9tpSHyIz3/I9X9yVenzZgV8mtnWt2EpLJEfYx86TIDM/rPFr9vy+F9
p6ov/scHHMKGYNabGtdsH0eBEgtCC7qMybkysIGBKFEAACARbdOGq4r0Uxg4K0Cx
JOsUV4Pw6I3vAgL8PagKTt5nICd5ySgExjJWiBV8IegBgd/ed1B1l6iNdU4Xa4Hb
TxEjUJgHKGkQtIvjpbbJ7w9e9PeAuQINBFj+MasBEACaSKGJzmsd3AxbGiaTEeY8
m1A9OKPGXHhT+EdYANIOL6RnfuzrXoy5w08ExbfYWYFTYLLHLJIVQwZJpqloK9NV
4Emn0PCgPB1QwjQN3PnaMpy8r57+m6HlgbSqWEpJcZURBSQ3CiQLfzC96nzTFGqc
NZU+KwUAwS5XFl0QeblKtA54IwI0+tH9B95WPzz0BOS2x6hXIdjB/rSQLY9ISDix
kiRHDsrU6lb339iVuSjW39J1mVxIAvvB+cswOLgTsp8cxuii2Yx9NFPllemABy6K
mRFqwd2peJGOmjJWEOhDAkadvAhT0B526e3JPXX0+yTXsKH/IR2C//kQarRiUCFv
w/N/Wi8Z/1I1Ae+mPSJHfBMQXFPxti7hYD22h27yiFZP7XMPgafXDauKb9qIg132
sEB6GkEjFM58JlJugna4evR2gp/pPwarYPcotkB5vAuWbYv1UM7gYMepER4LkL3r
uaWRMxP9lL1YvSnHRTbIRl6BCNdsQ/BOmuM9J16MhwhdaAUNZ4+69pTcq7nI7ZwH
ghnSM2Vc3z93vo+rEP6nW1pwk9U4qBz2y4hCfPmV2aAJhN8f9z+CP0BJufn1EGIY
VU1jS4pn/12GwXykdKs2g396QjuQsGzAq9QpbAciv8M9sg2KYIh2DNWqo6DTTh+e
HSWeGVYAuhexlBmMSb/hqwARAQABiQIfBBgBCgAJBQJY/jGrAhsMAAoJEJ/uHGo7
BxiP0SMP/R85QTEgJz+RN4rplWbjZAUKMfN2QWqYCD5k20vBooVnTDkY4IM5wQ+q
YP+1t/D1eLGTZ1uX9eZshIWXXakTJYla+niT8aP4SllNNwfeyZcCn1SwRAZ0ycjj
xN24rhV0aMWvtTrvo1kph9ac275ktNXVlFlrPsFokpK9Ds14Uzk7m2mqEBEH/TlO
Y4nBegRs6SmdBWOwKDWAINh+yzvFkTLr5r10D7aUukYuPZAiwnya0kLLXnoPmcys
LNxFuys78dS8EDC4WFWNVMdzvcUl3LArnfwYT7KqoR/j/MTps3fEq4tqhTxxVuV9
W53sF4pRqj8JTTZxKXz+50iRpT48VLBcCCsXU208giiFZCKgJgHtaxwNK6eezf7b
JaYfyg2ENmyp/tYsyZcCTv5Ku61sP3zu3lPHD4PNyTVpE60N/AAZaF0wRNmIVMoj
HaXTXPiBJHhmfI/AgtJ25HibifFLal/16bOQ58n/vgkdMomGfb7XZWEyO/zxEfhZ
OrUp1xSVgGdCflCEa95pWA6GSDxCsTSxkMUCYkaLPhE+JBFUq35ge4wsd1yS+YqA
2hI42+X8+WGxrobK2g2ZElEi92yqVuyUokA3aDbZDy9On3Hd9G7Bjxm7GKJ6vRTv
Mqb/lQkte2hBEShNrGSVAGNCkMv+jFlhVSB3OnVJcLQ2JVBW9Uyv
=H2BO
-----END PGP PUBLIC KEY BLOCK-----

[ankostis]

Personally I would be happiest if the current machinery using pip can be used to produce signed archives for download from pip.

@Byron twine should be your one-stop solution for uploading to PyPi repo.

[NicoHood]

thanks! twine looks good for pypi. Please use gpgit for the github source tarballs and everything will be good to go :)

[Byron]

@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]

@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]

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, gitdb and smmap are old packages owned by an account I am unable to access anymore, so the gitdb2 and smmap2 packages have been created instead. They are signed by now as well :).

[NicoHood]

@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]

@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]

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]

@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: 4477ADC5977D7C60D2A7E3789FEE1C6A3B07188F

makepkg reports me the new (short) keyid: 665F99FA9D99966C which is not found on a keyserver.

Edit: talking about the signature for release 2.1.8

[Byron]

@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 via gpg --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]

Alright. Make sure to also edit the readme then with the new key :)

[Byron]

@NicoHood Thanks a lot for hinting at it once again :)! Totally forgot that was there :D!

[NicoHood]

The gpg key got revoked. See gitpython-developers/smmap#36 (comment)

Please reopen or fix the issue.

[Byron]

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.