On July 24, 2014 at 11:58:01 AM, Justin Cappos (jcap...@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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
