-----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. 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. It still remains open though, how users should get notified about malware (other than being burnt and manually revoking some trust records and spreading that through their network of connections). >> 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. > 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. > 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. Thanks for the detailed responses Zygmunt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJREpDfAAoJECiU6TooxntHr98QAKqXcIt3op4syaCPARfFk8qj kLvvchJgtoMSUiphbF9fvV+2I2PWjnlTci0S6QEjBG75ivt2E9Vm9U9SqcgE26v4 MzOmku0QO88dKo9n4xmHPz2Z6miZ6n0q5FiIEfXPzl2O7yPOSsU7RCs/IWvN60Qn mqp/NhrSbkTFWWjFDZjo39ZwhDJuEgqovcCVtnMHA+uREZKW+yt1nBDLDkFd60Zr zOwv3VoFaRONk7lpwHa7ntjbRF3ev6uVIMRTpekwO1OM/KN3ZC255DCb6Re4aBY1 uuDh5/3g8ySfD3RiD3kWCWampzG7a3cDq+I/vVisdt90/1TsaSeNyiwFgBSDm/GC bsmkWv9yXDS/0tZE8sWryk/juODucTJq1uH+tftLRpsszrrrOsrEXIHKxIRZyl9K WzRTq4yH0OUICB/cQc5lBJEMI/v1jpY+TaMP6vzwiOwGfpeVIQwYPXsDb/oHJ4cr nb8x4tlJqtDg0AxQ2XIcqpL6c4bceaPfYJ7ZXNizjBKQqoxQ9NHg2MTrVXbh6GnR ZqAck3nWNTOEerO4RhsJT1GRBwyk+WAZwynVijh2Q49MeAkpd9xnJqqD/UfFFraD uuP58lZwyETzY/Ks6lvYusKlZ93+Hl3Snh5KDIZIIACUY2rOD6h8KCY6Jl8j4M91 hUC/hmjgFyJE+iW4ngu/ =9e11 -----END PGP SIGNATURE----- _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
