Il giorno 13/feb/2013, alle ore 11:29, Robert Collins <robe...@robertcollins.net> ha scritto:
> On 13 February 2013 15:12, Giovanni Bajo <ra...@develer.com> wrote: > >> Yes, that's correct. GPG chain-of-trust concept is not used in my proposal, >> because I don't think it would be a good fit for this problem given its >> requirements. Specifically, I believe pip users should not be bothered with >> useless click-through questions for each new package they install, which is >> what you would get far too often in case chain-of-trust were used. > > But this means someone that gets access to the PyPI server can just > mark their own key as trusted and compromise any package they want. Yes, with full access (eg: root) to the PyPI server you can do that. In fact, if you as an user are worried about this, there is a way to keep full end-to-end trust: by manually editing (= reducing, freezing) the trust file. See task #6 in my doc (http://goo.gl/qLFQR). Notice that you need a full compromise; if you compromise a third-party file mirror (or PyPI itself, but just the file storage), for instance, there is no problem. This is exactly the compromise between flexibility and security I'm proposing: * Standard user: trust PyPI, no questions asked * Advanced user: manually handle trust, don't trust PyPI My opinion is that it makes sense to assume that users running "pip install <package>" to install <package> from PyPI are trusting PyPI on that. I don't think people would expect that a full compromise of PyPI would mean absolutely nothing to all pip users in the world. In fact, when you type "apt-get install foo", you're trusting Debian, not the single package maintainer. If Debian Archive's keys are compromised, you're doomed. Any alternative design (eg: *offline* signing key for the trust file / trust delegation) would have to be analyzed in detail from an UX perspective. Let's say we keep a master key offline, and we let package maintainers submit requests (eg: "please add this gpg fingerprint", "please add this maintainer to this package"). How are you going to make sure that these requests, routed through a compromised server (PyPI) can get to the master key officer untampered? Are you going to sign them? If so, we need to devise a command-line interface for PyPI maintainers to submit such requests (so that they can be automatically signed), and we should shut down the web interface that allows to do this. Is the officer meant to blindly execute requests after verifying signatures, or would the officer have to double check requests through a side channel? How can the officer verify the signatures of such requests? Is he going to have his offline GPG fingerprint list / keychain? If so, how do we handle multiple officers to speed up the process (eg: 3 people in 3 different timezones)? How do we synchronize trust among them? All the above questions have good (and bad) answers of course. It's just that we need to explore them. Moreover, since we would have a command line to register packages, upload packages, admin package ownership/maintainership, do we still need a web interface for PyPI (I mean, the maintainer part of it of course)? Do we need maintainer accounts on PyPI? Probably not. -- Giovanni Bajo :: ra...@develer.com 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 Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
