[Catalog-sig] [Draft] Package signing and verification process

[Giovanni Bajo]

Il giorno 07/feb/2013, alle ore 17:21, Donald Stufft <donald.stufft at gmail.com> ha scritto:

> On Thursday, February 7, 2013 at 10:50 AM, Giovanni Bajo wrote:
> 
> 1. If we're going to implicitly trust PyPI when it says that key X is valid for package Y,
>     do we really gain much here? If we're trusting PyPI then we only really need secure
>     ingress and egress neither of which need packaging signing.

Adding GPG signature on top of SSL helps mitigating (at least) the following concerns:

1) If a PyPI account password is compromised (stolen, bruteforced, etc.), an attacker cannot upload a package that will be installed by package managers. This also requires making sure that a GPG fingerprint cannot be added to the account without a second factor authentication (can be anything from a link to a security email address, to a SMS). Notice that PyPI passwords are currently saved in the filesystem in clear ($HOME/.pypirc).
2) If the PyPI server is compromised in any way that let an attacker have write access to the file storage area, the attacker cannot tamper the packages.
3) If we decided to go with a third-party CDN service to serve the packages, we (and our users) don't need to trust them.

> 2. Any solution that includes the step "install GPG" is going to leave a significant
>     portion of people without it. If the tools mandate GPG then people won't upgrade,
>     if the tools don't mandate it people will skip that step.

You didn't explain why you believe so. I believe GPG installation can be automated on Linux and Mac in most scenarios (this must be elaborated as there are currently several different ways to install pip), and it is a single stand-alone installation on Windows.

Question: is your position that we shouldn't ask the user to install *anything* in addition to pip (IOW, whatever steps are performed to install pip should also install whatever is necessary for crypto, eg: gpg), or is there something specific in installing GPG that worries you?

> We (probably) won't be
>     using GPG's trust model so it ends up being just a "dumb" signature method of
>     which there are multiple. If we're going to sign packages we should be looking at
>     something that we can ship out of the box with Python proper at least in future
>     releases. (And I really didn't want to get into Bikeshedding Signature methods :/ ).

GPG still gives some values:
* People interested in hardening the security can manage signatures manually with familiar tools. This would be the same if we go with another suite, but not if we roll up our crypto/file-formats/protocols.
* GPG still has concepts of keyserver, keychain, downloading of sigs, passphrases; some of these concepts would be transparenly used by users installing packages, others would be (semi-)transparently used by maintainers uploading packages.

I don't think that not using the trust model of GPG automatically qualifies for making the whole tool useless and/or redundant.

> Let's keep in mind a few things:
>     - The right answer might be "not to sign packages", With proper egress/ingress protections
>       we have a huge avenue of attack solved. Slapping signatures that don't buy us anything
>       additional but introduce complexity is a net loss.
>     - This isn't an urgent pressing issue. Make sure we take the time to explore all the options,
>       including the take no action option, and arrive at a good solution.
>     - A lot of this discussion is going around in circles because there are no parameters, threat
>       model, requirements, or anything else of that nature. It would be more useful at this point
>       to figure out what exactly we are trying to achieve before running off half cocked to achieve
>       "something with package signatures".


I agree we shouldn't rush.

I elaborated in this email (and others) on what benefits bring us. I will also repeat it in the document I'm drafting.

FWIW (since there are many emails here and something might get lost), I repeat that I'm also volunteering to attempt the implementation of whatever we agree upon.
-- 
Giovanni Bajo   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130207/f572c637/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130207/f572c637/attachment.bin>