Il giorno 07/feb/2013, alle ore 17:21, Donald Stufft <[email protected]> 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 :: [email protected] Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
