Il giorno 06/feb/2013, alle ore 15:59, Zygmunt Krynicki <zygmunt.kryni...@canonical.com> ha scritto:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > W dniu 06.02.2013 15:38, Giovanni Bajo pisze: >> Il giorno 06/feb/2013, alle ore 14:41, Zygmunt Krynicki >> <zygmunt.kryni...@canonical.com> ha scritto: >> >>> W dniu 06.02.2013 11:57, Christian Heimes pisze: >>>> Am 05.02.2013 22:28, schrieb Zygmunt Krynicki: >>> >>>>> 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. >>>> >>>> No, you have to trust PyPI on some degree. PyPI is *the* >>>> authority of the relationship between users and projects. PyPI >>>> is the only entity in process that can truly verify that a key >>>> holder was a project maintainer at some given point in the >>>> past. >>> >>> But that information is worthless to me. Anyone can upload a new >>> project to pypi. What I want is to know if all the software that >>> I install via pip is from the trusted set of developers. If >>> someone introduces a new dependency I want to examine it and >>> trust the developer of the new dependency. This should never >>> happen automatically. >> >> I disagree with this statement. I think that PyPI *should*, by the >> default, be the central authority to be trusted specifically for >> this item, that is the association between developers, projects and >> their GPG signatures. This is important because most people would >> be perfectly fine with trusting PyPI and can not be reasonably >> asked to acquire valid GPG key fingerprints through external >> channels for all packages they want to install. We cannot sacrifice >> this UX part as it is crucial for the pip/PyPI experience. > > I agree that pypi "should" be the good guy we can trust. I argue that > none of the things offered in this thread can achieve that. > > There is a deeper problem here, apart from the current "OMG MITM" > issue that woke everyone up and realized how insecure their > infrastructure is. > > Even with a CA system, signatures, and ssl connection between the user > and pypi, installing $STUFF from pypi is the exact equivalent to > googling for a .exe on the internet. In this case you make the user > implicitly agree to installing "foo.exe" that came signed by "Foo > Corp" along with all of its dependencies. > > The "django" use case is interesting because we trust the "trademark" > that django carries more than anything else (and in fact this is > currently the only trust that people can apply to software from pypi). > What is more problematic is the association of trust to a particular > software and the trust to the whole pypi distribution channel. Without > a gatekeeper system, pypi cannot be treated as a storage for safe > software. It can just be an FTP site that has signed executables. > > In the end, you must let go of something: current user experience or > security. > > We can either let the UI tell the user that he's doing unsafe stuff, > giving full local user access to whoever owns the particular pypi > project that user choose to install (along with the full recursive set > of dependencies) _or_ start changing what pypi is. Can you please describe the UX you are devising? Say I start blank, I want to install 3-4 packages that globally bring another 10 packages as dependencies (made by different developers). What would be your suggested workflow? What should an user do? > If pypi becomes a gatekeeper / appstore with "review" process and the > like then what you describe is perfectly fine (to the extent that the > central review system can scale and stay effective). I think it's a false alternative. You're suggesting that either you *only* trust PyPI (like appstore or any Linux distro, where you only trust Canonical for all the packages you install through apt), or you *only* trust the end developers, by manually building a list of GPG signatures. I think that what we are suggesting here instead is a good compromise between security and usability, just like the current CAs in SSL have been for many years a good compromise between the final solution (yet to be devised) and using only self-signed certificates. In fact, CAs are still a very good compromise that work for 99.9999% of people and websites. I understand that we will need a final solution for SSL, but I think that for PyPI, forcing your suggestion is basically an instance of making perfect the enemy of good. Perfect security doesn't exist. At the end of the day, I can talk you into registering the wrong fingerprint for a package, I can phish you on the package name, I can compromise Django's developers' GPG keychains. Or, most important of all, I can simply go exploit a 0-day vulnerability on a totally-regular, phone-call sig-validated instance of Django installed on your server. An attacker will simply go for the lowest hanging fruit. -- 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