[Distutils] [tuf] Re: PEP 470 discussion, part 3

Justin Cappos jcappos at nyu.edu
Thu Jul 24 18:08:55 CEST 2014


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 <donald at stufft.io> wrote:

> 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/258095f3/attachment.html>


More information about the Distutils-SIG mailing list