I should mention that this scenario is the worst case scenario, and isn't the likely one. However I think the possible damages from it well outweigh the small amount of benefit from mutable packages.
The more likely scenarios (on the failure side) are either applications breaking upon install/deploy or silently corrupting data. Both of which, but especially the silently corrupting data case I think the possible damages again outweigh the small benefit from mutable packages. On Wednesday, February 1, 2012 at 6:06 AM, Yuval Greenfield wrote: > On Wed, Feb 1, 2012 at 11:14 AM, Chris Withers <ch...@simplistix.co.uk > (mailto:ch...@simplistix.co.uk)> wrote: > > On 01/02/2012 09:01, Yuval Greenfield wrote: > > > Would you testify that HTTP is secure because I can emulate TLS in > > > javascript? > > > > What's that got to do with the price of eggs? > > > > > > I can maintain my own personal log of package SHA-512's and thus locally > avoid this security hole in PyPI. The system as a whole is still vulnerable > by default. That's why HTTP is considered insecure even though you can build > secure solutions on top of it. PyPI would be the insecure infrastructure upon > which secure frameworks can be built. Immutability will make the default > behavior of pypi more secure. > > > > > PyPI should do what it can within reason to be consistent and safe for > > > all its users. > > > > *sigh* that's what the MD5s are for. What threat, exactly are you so > > worried about here? That someone investigates and chooses to use a package, > > and then, having done so, decides to re-download an identical version of > > that package which has been maliciously uploaded, and happens to have the > > same MD5 checksum as the one they've already downloaded? > > > > Let's assume I made a package called pybanker that requires a specific > version of SQLAlchemy (eg 0.6.8). When I tell people to download SQLAlchemy > 0.6.8 do I have to tell them the exact hash? Does the setup.py/cfg > (http://setup.py/cfg) allow me to require a specific hash on SQLAlchemy when > automatically resolving dependencies in pip/easy_install? So now when banks > around the world are going to use pybanker and thus SQLAlchemy 0.6.8 - they > don't know what was the original hash. In the meantime a security threat has > manifested in sqlalchemy (eg pythonpackages was hacked, an sqlalchemy > maintainer password/computer/network was compromised, etc). The hacker > modifies SQLAlchemy 0.6.8 to work perfectly while adding a backdoor to the > system or relaying all transactions to a remote server. > > I hope we don't have to wait for this attack vector to be used (and detected > and publicized) before this loophole is patched. > > Obviously this isn't the only problem if the account of an SQLAlchemy > maintainer is compromised - other threats can manifest as well. That doesn't > mean this specific threat should be ignored, especially considering that it's > a stealthy vector. > > tl;dr - the classic bait and switch is why user generated content is > immutable on most web services. If edits are allowed they are usually only so > for a limited amount of time or require an administrator in the loop. > > Yuval > _______________________________________________ > Catalog-SIG mailing list > Catalog-SIG@python.org (mailto:Catalog-SIG@python.org) > http://mail.python.org/mailman/listinfo/catalog-sig > >
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
