Got it. Thanks for clearing this up. Glad to hear that virtual dependencies are not an issue. It simplifies things a lot!
Justin On Thu, Jul 24, 2014 at 12:03 PM, Donald Stufft <[email protected]> wrote: > On July 24, 2014 at 11:58:01 AM, Justin Cappos ([email protected]) wrote: > > FYI: PEP 458 provides a way to address most of the security issues with > this as well. (We call these "provides-everything" attacks in some of our > prior work: https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf) > > > One way of handling this is that whomever registers the name can choose > what other packages can be registered that meet that dependency. Another > is that PyPI could automatically manage the metadata for this. Clearly > someone has to be responsible for making sure that this is 'off-by-default' > so that a malicious party cannot claim to provide a popular package and get > their software installed instead. What do you think makes the most sense? > > Even if only "the right" projects can create trusted packages for a > dependency, there are security issues also with respect to which package > should be trusted. Suppose you have projects zap and bar, which should be > chosen to meet a dependency. Which should be used? > > With TUF we currently support them choosing a fixed project (zap or bar), > but supporting the most recent upload is also possible. We had an > explicit tag and type of delegation in Stork for this case (the timestamp > tag), but I think we can get equivalent functionality with threshold > signatures in TUF. > > Once we understand more about how people would like to use it, we can make > sure PEP 458 explains how this is supported in a clean way while minimizing > the security impact. > > Thanks, > Justin > > > Sorry, I think the provides functionality is outside of the scope of what > we would use TUF for. It is *only* respected if you have that project > installed. In other words if there is a package “FakeDjango” which provides > “Django”, then ``pip install Django`` will *never* install “FakeDjango”. > However if you’ve already done ``pip install FakeDjango`` then later on you > do ``pip install Django`` it will see that it is already installed (because > “FakeDjango” provides it). > > IOW it only matters once you’ve already chosen to trust that package and > have installed it. This is to prevent any sort of spoofing attacks and to > simplify the interface. This doesn’t prevent a project which you’ve elected > to trust by installing it from spoofing itself, but it’s impossible to > prevent them from doing that anyways without hobbling our package formats > so much that they are useless. For instance any ability to execute code > (such as setup.py!) means that FakeDjango could, once installed, spoof > Django just by dropping the relevant metadata files to say it is already > installed. > > -- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
