My impression is this only holds for things signed directly by PyPI because the developers have not registered a key. I think that developers who register keys won't have this issue. Let's talk about this when you return, but it's really projects / developers that will be stable in the common case, not packages, right?
Justin On Wed, Jul 17, 2013 at 9:29 PM, Trishank Karthik Kuppusamy < t...@students.poly.edu> wrote: > On 07/18/2013 03:24 AM, Ronald Oussoren wrote: > >> I'm trying to understand what this means for package maintainers. If I >> understand you correctly maintainers would upload packages just like they >> do now, and packages are then automaticly signed by the "unstable" role. >> Then some manual process by the PyPI maintainers can sign a package with a >> stable row. Is that correct? If it is, how is this supposed to scale? The >> contents of PyPI is currently not vetted at all, and it seems to me that >> manually vetting uploads for even the most popular packages would be a >> significant amount of work that would have to be done by what's likely a >> small set of volunteers. >> > > I think Daniel put it best when he said that we have been focusing too > much on deciding whether or not a package is malicious. As he said, it is > important that any security proposal must limit what targeted attacks on > the PyPI infrastructure can do. > > You are right that asking people to vet through packages for inclusion > into the stable role would be generally unscalable. I think the best way to > think about it is that we can mostly decide a "stable" set of packages with > a simple rule, and then *choose* to interfere (if necessary) with decisions > on which packages go in or out of the stable role. The stable role simply > has to sign this automatically computed set of "stable" packages every now > and then, so that the impacts of attacks on the PyPI infrastructure are > limited. Users who install the same set of stable packages will see the > installation of the same set of intended packages. > > Presently, I use a simple heuristic to compute a nominal set of stable > packages: all files older than 3 months are considered to be "stable". > There is no consideration of whether a package is malicious here; just that > it has not changed long enough to be considered mature. > > > Also, what are you supposed to do when FooBar 2.0 is signed by the stable >> role and FooBar 2.0.1 is only signed by the unstable role, and you try to >> fetch FooBar 2.0.* (that is, 2.0 or any 2.0.x point release)? >> >> > In this case, I expect that since we have asked pip to install FooBar > 2.0.*, it will first fetch the /simple/FooBar/ PyPI metadata (distinct from > TUF metadata) to see what versions of the FooBar package are available. If > FooBar 2.0.1 was recently added, then the latest version of the > /simple/FooBar/ metadata would have been signed for the unstable role. > There are two cases for the stable role: > > 1. The stable role has also signed for the FooBar 2.0.1 package. In this > case, pip would find FooBar 2.0.1 and install it. > 2. The stable role has not yet signed for the FooBar 2.0.1 package. In > this case, pip would find FooBar 2.0 and install it. > > Why would this happen? In this case, we have specified in the TUF metadata > that if the same file (in this case, the /simple/FooBar/ HTML file) has > been signed for by both the stable and unstable roles, then the client must > prefer the version from the stable role. > > Of course, there are questions about timeliness. Sometimes users want the > latest packages, or the developers of the packages themselves may want this > to be the case. For the purposes of bootstrapping PyPI with TUF, we have > presently decided to simplify key management and allow for the protection > of some valuable packages on PyPI (with limited timeliness trade-off) while > allowing for the majority of the packages to be continuously released. > > There are a few ways to ensure that the latest intended versions of the > FooBar package will be installed: > 1. Do not nominate FooBar into the "stable" set of packages, which should > ideally be reserved --- for initial bootstrapping purposes at least --- for > perhaps what the community thinks are the "canonical" packages that must > initially be protected from attacks. > 2. The stable role may delegate its responsibility about information on > the FooBar package to the FooBar package developers themselves. > 3. Explore different rules (other than just ordering roles by trust) to > balance key management, timeliness and other issues without significantly > sacrificing security. > > We welcome your thoughts here. For the moment, we are planning to wrap up > as soon as possible our experiments on how PyPI+pip perform with and > without TUF with this particular scheme of stable and unstable roles. > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig