Il giorno 05/feb/2013, alle ore 22:28, Zygmunt Krynicki <[email protected]> ha scritto:
>> * What is the expected end user reaction if someone revokes their >> key from PyPI? In other words if I've established a trust with key >> A, and the maintainer revokes that what happens when I try to >> install their package now with key B? * Similarly what if an owner >> removes a maintainer? * I think it should be a separate key ring. >> >> In general I think any system that depends on PyPI* to handle trust >> is going to not gain us what we're hoping for. This needs to be >> designed in a way that we assume PyPI is no longer operating in >> good faith. If we do require PyPI to still be on our "side", then >> we're only concerned for MITM and SSL should be enough there (Not >> as currently configured on PyPI though). > > I agree. I think that pypi should not have to be trusted. Real people > trust other (few, limited) real people. We don't normally trust large > bodies (corporations, groups) as that trust cannot be effective. It's an ideal goal I would agree with, but I think it makes things far more complicated. As you know, trust at the GPG level is based on chain of trust and real-life key-signing sessions. This means that when I get a package signed by "[email protected]", I have no clue whether it's really the Django developers, it's a phishing email, or it's a "fake" key generated for the real e-mail. If you totally remove PyPI from the trust loop, you are asking users to manually verify the identity of such keys, and a large number of them will simply *not* do it, because this is exactly something they can't be bothered with; they use "pip" so that they can install a package right away, not so that they have to go to key-signing parties before being able to install a package. This is also why CAs exist, browsers maintain CA bundles, and so on (it's not a perfect system, but it's still better than asking users to manually verify by themselves each and every SSL certificate they stumble upon). What PyPI must do is to stay in this loop only to certify that a specific GPG key is officially associated to a specific package, and can be safely used to verify that package's signature. This still guarantees that even if PyPI file storage is compromised, an attacker can't forge package contents. Obviously, you still need some level of trust in PyPI, for instance you need to trust that the GPG keys have not been modified by an unauthorized third-party (eg: a PyPI developer with write access to the DB holding the GPG fingerprints for all packages). -- 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
