Il giorno 06/feb/2013, alle ore 18:20, Zygmunt Krynicki <zygmunt.kryni...@canonical.com> ha scritto:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > W dniu 06.02.2013 16:24, Giovanni Bajo pisze: > >>> 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? > > You would first download django (either signed or not) and get > prompted if you want to trust the signer for that project (or if the > file was not signed, to trust this particular file for django in the > future). > > As you go you would see many prompts like that, roughly identical to > what you get when SSH-ing to a new system. > > Note: At each step you could stop to manually examine the freshly > downloaded file. The user interface should be brief but to the point. You are not describing what an user should do when asked about this confirmation. For instance: $ bin/pip install geventconnpool Downloading/unpacking geventconnpool Downloading geventconnpool-0.2.tar.gz WARNING: the package was signed with the following GPG key Giovanni Bajo <ra...@develer.com> E870D9A369B8348A Do you want to continue and trust this key (y/n)? What should an user do now? Most users will just tap "yes" to get on with their task and ignore this prompt. > The most important aspect is what happens the second time you install > those packages -- you never get prompted (unless a package was > unsigned and got updated in the mean time). > > I realize this interface is not perfect but it solves practically all > of the current issues. Most importantly it can be applied to all > existing software today, so we get the benefits without asking > everyone to fix their story. I disagree. You are asking users to manually go verifying a GPG fingerprint (actually, many more than one, in case of dependencies) without giving any indication on how to do it. What will happen is that they will just tap "yes" without confirming, making the whole security castle invalid. Compared to SSH, there are many important differences here: 1) The number of servers you need to SSH into is far more limited, and they are all entities with which you have a direct connection. It might be a server of your company, a VM you rented, a friend's computer, a website like github. In all of these cases, you have a clear, direct communication channel already in place in case you want to be paranoid and double-check the SSH host key. When you install a package from PyPI you have zero connection with the author/maintainers; in fact, that packages might bring in dependencies you don't even know *what* they are used for, let alone who maintain them. There is no clear path here to check a GPG fingerprint, and one user might have to check 5-10 of them just to install a framework to hack away a simple program. 2) A SSH host key on a server is almost never updated, so whitelisting it after the first time is a good compromise because it is unlikely that you're being MITM the first time you connect it (let's say, far more unlikely than being MITM'd in one of all the other times you connect to it). The only real reason to update it is in case of a compromise, or when the IP address changes (in that case the host key is technically not changed, but SSH will still bail). On the contrary, the GPG key used to sign a package might change more often (not *daily*, but still more often than a SSH hostkey): different maintainers might have different keys (and all of them might be valid for that package); moreover, maintainers change over time for the same packages. You have absolutely no side channel to double-check this. 3) SSH has a per-usage storage for such a whitelist (~/.ssh/known_hosts). On the contrary, it is common to have a different pip installation (even different pip versions!) per each virtualenv, and virtualenv is usually thought to be sort-of a chroot for pip. That might bring to the point where the known_hosts for pip would be per-virtualenv; but that would be a disaster for the UX, because it would mean that one would have to re-approve GPG fingerprints per each virtualenv (or copy known_hosts between different virtualenvs). NOTE: I would like to stress that also the solution in which you trust PyPI "solves practically all of the current issues". It is just that you need to trust PyPI. I don't think this classifies as an issue per-se. As I said, I think that most people implicitly trust PyPI if they "go there" to download a file. I understand that you're striving to remove this trust, but I don't think it's an issue. >>> 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. > > Well not entirely. I agree there is something in the middle and this > is why in the 'distrust' tool 'dist' stands for 'distributed'. I > believe that with the collective power of developers and users > installing software using that trust system we can quickly build a > pretty full network of trusted software (via peer trust, if you trust > some package and I trust you, I can instruct the software to trust > your choices as mine). Also, everyone can share their signed trust > records. The amount of code effort required to automatize the above features in a way to make them usable by users that don't even have a GPG key in their keychain (as a normal pip user is) is quite big. >> 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. > > I agree that the proposed solutions protect against many class of > attacks and I will welcome them with open arms. > > In any case, nothing here prevents both approaches from being > developed. When combined (if someone chooses to do so) they would give > even stronger protection. My suggestion at this point is to have an option to remove trust on PyPI. This means that pip will not ask PyPI for a list of per-package trusted GPG fingerprints, and will just bail if the GPG fingerprint is not mentioned in its configuration file. >> 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. > > That is all true. Then again, what I'm advocating for is not about > security but trust. Those seem related but are really separate in many > respects. True, but trust is just a mean to security (at least in the context of this discussion). This is why I tend to prefer the shortest path that gives me an acceptable level of security. -- 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
