On May 8, 2014, at 11:19 AM, Stefan Krah <ste...@bytereef.org> wrote:
> Donald Stufft <don...@stufft.io> wrote: >> hosted packages are brittle and more prone to failure. Every single external >> server adds *another* SPOF into any particular install set. Even if every >> external server has a 99.9% uptime, when you combine multiple of them the >> total >> uptime of any particular set of requirements drops quickly. This has been a >> major complaint that people have had over time. > > We have been through that many times; to me this is an indication that > people are using pip under circumstances when they should not. pip is > not apt-get. > > [I am aware that *you* know that, just stating it again for the broader > audience.] > > >>> 2) Last time I looked, access credentials (via "lost login") were sent >>> out in plaintext. >> >> The existence of other security issues is not an excuse to not fix a security >> issue. There are other problems and we're slowly working on trying to clear >> them out. > > It is, however, a reason to avoid error messages that could *imply* (rightly > or wrongly) to users that the combination of pip and internal packages is > safe. > > >>> 3) AFAIK people can upload a different (malicious) version of a >>> package with *the exact same name*. >> >> Yes, a malicious author is needfully outside of the threat model for >> PyPI/pip. > > How so? I'm avoiding this attack by publishing sha256sums at release time. > The point is that I *cannot* change cdecimal-2.3.tar.gz without a user digging > up a checksum mismatch from the mailing list archives. Practically speaking exactly zero people will ever bother to dig up the checksum from a mailing list archive, or even verify the hash that you have right on PyPI itself. Worse security that people actually use is infinitely better than better security that nobody uses. > > >>> 6) D.J. Bernstein, who is somewhat security minded, has been shipping >>> his software *for years* with just plain HTTP and published checksums. >> >> Argument from authority doesn't really hold up very well when DJB doesn't >> distribute is software in a way that is intended to be consumed mechanically. >> Also while he may be a crypto expert he is far from an expert on successfully >> distributing software, unless you also think that the signature checking in >> most OS provided package managers is pointless. > > That is sort of a strawman. The whole point *is* that certain distribution > models don't lend themselves to mechanical consumption. I cannot speak > for DJB, perhaps he is just thinking that GPG signing is pointless if > users can't validate the signature and SSL is pointless because one cannot > trust governments. > > OS package signing is useful since the packages are curated. If anyone > could upload a package to Debian, whereupon it would be signed with the > official key, apt-get would lose its usefulness. People are going to mechanically consume them. You can tell them it’s wrong all you want but they are going to do it. > > > > Stefan Krah > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com