[Distutils] PEP 470 discussion, part 3

Donald Stufft donald at stufft.io
Thu Jul 24 18:03:53 CEST 2014


On July 24, 2014 at 11:58:01 AM, Justin Cappos (jcappos at nyu.edu) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140724/3c2b6b00/attachment.html>


More information about the Distutils-SIG mailing list