On Wed, Feb 6, 2013 at 12:46 AM, Giovanni Bajo <[email protected]> wrote: > Il giorno 05/feb/2013, alle ore 15:06, Holger Krekel > <[email protected]> ha scritto: > > In the end, however, none of this prevents MITM attacks between a downloader > and pypi.python.org. Or between the uploader and pypi.python.org (using > basic auth over http often). Signing methods like > https://wiki.archlinux.org/index.php/Pacman-key are key. If a signature is > available (also at a download_url site), then we can exclude undetected > tampering. And there might not be a need to break currently working package > releases. > > > A signature is not enough; if you don't have a secure channel, signatures > can be replayed. Eg: if you install through an unsecure channel and you just > verify GPG signatures on the package, I can MITM you and serve you an older, > vulnerable package version (with its correct signature), and then go exploit > that vulnerability.
Don't let perfect become the enemy of better. There are a *truckload* of potential vulnerabilities in the way people currently use PyPI, and *all* of them need to be addressed over time. It's great that the problems with rubygems and the published MITM attack on PyPI have drawn attention to these issues, but it's important to remember that the reason most of them haven't been addressed before now is because they're *hard problems*, and because there's a tension between encouraging relative newcomers to Python (and open source in general) to share their work with the world, providing reasonable transition plans from existing insecure practices to more secure allternatives, and ultimately satisfying the dependency management needs of those that want to be able to obtain trusted versions of software directly from PyPI using the standard tools. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
