We present [PEP 458](http://legacy.python.org/dev/peps/pep-0458/), a standard that we have been working on closely with DistUtils-SIG. PEP 458 proposes using [The Update Framework](http://theupdateframework.com/) (TUF), a software update framework [developed](https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf) by security researchers (some from the Tor project), to transparently secure PyPI against attacks. TUF has been [ported to RubyGems by Square](http://corner.squareup.com/2013/12/securing-rubygems-with-tuf-part-1.html), and will soon be [used by the LEAP project](https://groups.google.com/forum/#!msg/theupdateframework/44Dai54l5G4/CW6Nw_bUnbwJ). PEP 458 proposes giving project owners a choice: either *claim* their projects (and sign for their own packages), or let PyPI instead sign for their packages. The implications are simple to understand. In either case, all projects will be transparently protected against man-in-the-middle attacks. In the worst case, if PyPI itself is compromised, then claimed projects are immediately safe because their packages cannot be tampered with without being detected by TUF. All of this is transparent to project developers. Developers of a claimed project use the TUF [developer tools](https://github.com/theupdateframework/tuf/blob/develop/tuf/README-developer-tools.md) to easily sign for their packages. All other projects will simply let PyPI sign for their packages. All of this is also transparent to end-users. When PEP 458 is deployed on PyPI, users who use pip will not be able to tell that they are using TUF at all to securely download packages, _except_ when there is a security problem, in which case TUF would halt and report an exception instead of allowing a potentially compromised package to be downloaded and installed.