Testing pip security without and with TUF
Hello everyone, Recently, we tested how pip would respond, without and with TUF, to attacks on PyPI: https://github.com/theupdateframework/pip/wiki/Test-pip-security-without-and... TUF now uses the portable PyCrypto cryptography library, though we are watching cryptography-dev with great interest. In our internal tests, pip-with-TUF works on Microsoft Windows 7-8 32/64 bit, Apple OS X (10.7-10.8), and Debian/Ubuntu GNU/Linux 32/64 bit. We also have integration tests where we show TUF protecting against other kinds of attacks: https://github.com/theupdateframework/tuf/tree/develop/tests/integration Previously, we demonstrated that we could efficiently secure PyPI with TUF metadata: https://mail.python.org/pipermail/distutils-sig/2013-August/022276.html *** We need your guidance here! *** Our next step is to integrate TUF with the PyPI server itself to see how everything would work in production. This would allow us, amongst other things, to build better package-signing tools for developers, and make continuous release of packages as smooth as possible. Before we go any further, though, we would like your thoughts on the matter. Should we modify the PyPI server ourselves? Or should we wait for Warehouse instead? We want to work together with the DistUtils SIG community on all of this, and would appreciate any feedback and thoughts you have for us. What would you like to see from us? Thanks, The TUF Team
Couple questions inline On Sep 21, 2013, at 5:14 PM, Trishank Karthik Kuppusamy <tk47@students.poly.edu> wrote:
Hello everyone,
Recently, we tested how pip would respond, without and with TUF, to attacks on PyPI: https://github.com/theupdateframework/pip/wiki/Test-pip-security-without-and...
TUF now uses the portable PyCrypto cryptography library, though we are watching cryptography-dev with great interest. In our internal tests, pip-with-TUF works on Microsoft Windows 7-8 32/64 bit, Apple OS X (10.7-10.8), and Debian/Ubuntu GNU/Linux 32/64 bit.
Is it possible to do this in a pure python library? I know there are pure python libraries for ed25119 that are written by the author so they should be good to use.
We also have integration tests where we show TUF protecting against other kinds of attacks: https://github.com/theupdateframework/tuf/tree/develop/tests/integration
Previously, we demonstrated that we could efficiently secure PyPI with TUF metadata: https://mail.python.org/pipermail/distutils-sig/2013-August/022276.html
*** We need your guidance here! *** Our next step is to integrate TUF with the PyPI server itself to see how everything would work in production. This would allow us, amongst other things, to build better package-signing tools for developers, and make continuous release of packages as smooth as possible.
Before we go any further, though, we would like your thoughts on the matter. Should we modify the PyPI server ourselves? Or should we wait for Warehouse instead? We want to work together with the DistUtils SIG community on all of this, and would appreciate any feedback and thoughts you have for us. What would you like to see from us?
What does an integration look like? What time frame are you looking at completing this? Warehouse is where the future of PyPI is and I'm loathe to add much else to the old code base, but Warehouse is very incomplete at the moment. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Hello Donald, On 09/21/2013 05:54 PM, Donald Stufft wrote:
Is it possible to do this in a pure python library? I know there are pure python libraries for ed25119 that are written by the author so they should be good to use.
It should be possible to do in pure Python all the cryptography that TUF needs. The performance may not be so good with sufficiently large RSA keys, but I think that is a bottleneck only when creating those keys and signing metadata with those keys. Verifying signatures created by those keys should be cheap enough, and that is how most people would use TUF (for reading, not writing). Vlad, what do you think?
Before we go any further, though, we would like your thoughts on the matter. Should we modify the PyPI server ourselves? Or should we wait for Warehouse instead? We want to work together with the DistUtils SIG community on all of this, and would appreciate any feedback and thoughts you have for us. What would you like to see from us?
What does an integration look like? What time frame are you looking at completing this? Warehouse is where the future of PyPI is and I'm loathe to add much else to the old code base, but Warehouse is very incomplete at the moment.
By an integration, we mean this scenario: developers will be able to register their package-signing keys with PyPI (by uploading their public keys), and sign for package metadata themselves with their private keys. Among other things, the PyPI server will also have to change a bit to generate some TUF metadata itself. I think it would make the most sense for us to figure out how to integrate TUF with Warehouse since that is the future of PyPI. Is now a good time for us to discuss how to do that? What is your timeframe for Warehouse? Thanks, Trishank
On Sep 21, 2013, at 6:12 PM, Trishank Karthik Kuppusamy <tk47@students.poly.edu> wrote:
Hello Donald,
On 09/21/2013 05:54 PM, Donald Stufft wrote:
Is it possible to do this in a pure python library? I know there are pure python libraries for ed25119 that are written by the author so they should be good to use.
It should be possible to do in pure Python all the cryptography that TUF needs. The performance may not be so good with sufficiently large RSA keys, but I think that is a bottleneck only when creating those keys and signing metadata with those keys. Verifying signatures created by those keys should be cheap enough, and that is how most people would use TUF (for reading, not writing). Vlad, what do you think?
Ok good, as long as what someone installing a package needs done can be done in pure python that's fine. Pip can't have dependencies in the traditional sense so everything needs to be embeddable and pure python. An optional C module for speed ups is fine. Packaging tools on the other hand IMO can require compiled code.
Before we go any further, though, we would like your thoughts on the matter. Should we modify the PyPI server ourselves? Or should we wait for Warehouse instead? We want to work together with the DistUtils SIG community on all of this, and would appreciate any feedback and thoughts you have for us. What would you like to see from us?
What does an integration look like? What time frame are you looking at completing this? Warehouse is where the future of PyPI is and I'm loathe to add much else to the old code base, but Warehouse is very incomplete at the moment.
By an integration, we mean this scenario: developers will be able to register their package-signing keys with PyPI (by uploading their public keys), and sign for package metadata themselves with their private keys. Among other things, the PyPI server will also have to change a bit to generate some TUF metadata itself.
I think it would make the most sense for us to figure out how to integrate TUF with Warehouse since that is the future of PyPI. Is now a good time for us to discuss how to do that? What is your timeframe for Warehouse?
Right now i'm porting over database tables to be "owned" by Warehouse (Warehouse and legacy PyPI run in tandem). After that i'll be working on porting the existing API. I'm hoping to have something that people can install from to test in a month or two. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 09/21/2013 06:17 PM, Donald Stufft wrote:
Is it possible to do this in a pure python library? I know there are pure python libraries for ed25119 that are written by the author so they should be good to use.
It should be possible to do in pure Python all the cryptography that TUF needs. The performance may not be so good with sufficiently large RSA keys, but I think that is a bottleneck only when creating those keys and signing metadata with those keys. Verifying signatures created by those keys should be cheap enough, and that is how most people would use TUF (for reading, not writing). Vlad, what do you think?
Ok good, as long as what someone installing a package needs done can be done in pure python that's fine. Pip can't have dependencies in the traditional sense so everything needs to be embeddable and pure python. An optional C module for speed ups is fine.
Packaging tools on the other hand IMO can require compiled code.
Aha, I see, that's good to know! That sounds like a good plan: we will have pip-with-TUF "read" cryptography in pure Python, and have the packaging tools use whatever is deemed best.
Before we go any further, though, we would like your thoughts on the matter. Should we modify the PyPI server ourselves? Or should we wait for Warehouse instead? We want to work together with the DistUtils SIG community on all of this, and would appreciate any feedback and thoughts you have for us. What would you like to see from us?
What does an integration look like? What time frame are you looking at completing this? Warehouse is where the future of PyPI is and I'm loathe to add much else to the old code base, but Warehouse is very incomplete at the moment.
By an integration, we mean this scenario: developers will be able to register their package-signing keys with PyPI (by uploading their public keys), and sign for package metadata themselves with their private keys. Among other things, the PyPI server will also have to change a bit to generate some TUF metadata itself.
I think it would make the most sense for us to figure out how to integrate TUF with Warehouse since that is the future of PyPI. Is now a good time for us to discuss how to do that? What is your timeframe for Warehouse?
Right now i'm porting over database tables to be "owned" by Warehouse (Warehouse and legacy PyPI run in tandem). After that i'll be working on porting the existing API. I'm hoping to have something that people can install from to test in a month or two.
Okay, that sounds good. Certainly there will be many details to be worked out; I am not sure yet exactly how TUF will fit into Warehouse, so we will need to talk about that. It may be better to move some of this discussion offline, so that we don't have to inundate the mailing list with unnecessary details until we are ready to publicly present them for discussion later. Talk to you soon, Trishank
On Sat, Sep 21, 2013 at 6:17 PM, Donald Stufft <donald@stufft.io> wrote:
On Sep 21, 2013, at 6:12 PM, Trishank Karthik Kuppusamy < tk47@students.poly.edu> wrote:
Hello Donald,
On 09/21/2013 05:54 PM, Donald Stufft wrote:
Is it possible to do this in a pure python library? I know there are
pure
python libraries for ed25119 that are written by the author so they should be good to use.
It should be possible to do in pure Python all the cryptography that TUF needs. The performance may not be so good with sufficiently large RSA keys, but I think that is a bottleneck only when creating those keys and signing metadata with those keys. Verifying signatures created by those keys should be cheap enough, and that is how most people would use TUF (for reading, not writing). Vlad, what do you think?
Ok good, as long as what someone installing a package needs done can be done in pure python that's fine. Pip can't have dependencies in the traditional sense so everything needs to be embeddable and pure python. An optional C module for speed ups is fine.
What about a precompiled Python extension? Bundling wheels?
Packaging tools on the other hand IMO can require compiled code.
Before we go any further, though, we would like your thoughts on the matter. Should we modify the PyPI server ourselves? Or should we wait for Warehouse instead? We want to work together with the DistUtils SIG community on all of this, and would appreciate any feedback and thoughts you have for us. What would you like to see from us?
What does an integration look like? What time frame are you looking at completing this? Warehouse is where the future of PyPI is and I'm loathe to add much else to the old code base, but Warehouse is very incomplete at the moment.
By an integration, we mean this scenario: developers will be able to
register their package-signing keys with PyPI (by uploading their public keys), and sign for package metadata themselves with their private keys. Among other things, the PyPI server will also have to change a bit to generate some TUF metadata itself.
I think it would make the most sense for us to figure out how to
integrate TUF with Warehouse since that is the future of PyPI. Is now a good time for us to discuss how to do that? What is your timeframe for Warehouse?
Right now i'm porting over database tables to be "owned" by Warehouse (Warehouse and legacy PyPI run in tandem). After that i'll be working on porting the existing API. I'm hoping to have something that people can install from to test in a month or two.
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Sep 21, 2013, at 8:47 PM, Vladimir Diaz <vladimir.v.diaz@gmail.com> wrote:
What about a precompiled Python extension? Bundling wheels?
The problem is when pip has a dependency on something and someone accidentally uninstalls that dependency it leaves pip in a broken state. Additionally pip uses itself to bootstrap itself so any extra dependency is something else the user has to install prior to bootstrapping pip. Dependencies can be "inlined" inside of pip to work around this issue. Then we come to the compiled code problem. Pip currently should work on any Python interpreter and not just CPython. PyPy for instance does not support the C API very well and there's a good chance that using C code without using something like CFFI, however using something like CFFI breaks the first rule. Adding C code into the pip repository also has some other problems related to Windows installation. Does TUF require the use of RSA? I've never found a pure Python RSA implementation that I would personally trust. It's one of the major reasons when I was planning out some ideas for a signing system my plan was to use ed25519 (http://ed25519.cr.yp.to/). It's a fast deterministic signature scheme that has a pure python implementation (~100 lines of code) written by DJB. Additionally the public keys are very small (32 bytes). Additionally there's lib sodium (which I've wrapped in PyNaCl) which implements ed25519 in high performance C code (which PyNaCl makes available in Python). ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 9/21/13 9:09 PM, Donald Stufft wrote:
On Sep 21, 2013, at 8:47 PM, Vladimir Diaz <vladimir.v.diaz@gmail.com <mailto:vladimir.v.diaz@gmail.com>> wrote:
What about a precompiled Python extension? Bundling wheels?
The problem is when pip has a dependency on something and someone accidentally uninstalls that dependency it leaves pip in a broken state. Additionally pip uses itself to bootstrap itself so any extra dependency is something else the user has to install prior to bootstrapping pip. Dependencies can be "inlined" inside of pip to work around this issue.
Then we come to the compiled code problem. Pip currently should work on any Python interpreter and not just CPython. PyPy for instance does not support the C API very well and there's a good chance that using C code without using something like CFFI, however using something like CFFI breaks the first rule. Adding C code into the pip repository also has some other problems related to Windows installation.
All very valid points, and we do not disagree.
Does TUF require the use of RSA? I've never found a pure Python RSA implementation that I would personally trust. It's one of the major reasons when I was planning out some ideas for a signing system my plan was to use ed25519 (http://ed25519.cr.yp.to/). It's a fast deterministic signature scheme that has a pure python implementation (~100 lines of code) written by DJB. Additionally the public keys are very small (32 bytes). Additionally there's lib sodium (which I've wrapped in PyNaCl) which implements ed25519 in high performance C code (which PyNaCl makes available in Python).
No, nothing about TUF mandates RSA. ed25519 certainly sounds interesting, and we will consider it when we review our cryptography. As you said, it is important that our "read-only" cryptography is in pure Python for best portability. Let us get back to you on this matter. In the meantime, we will also get in touch with you about Warehouse. Thanks, Trishank
On Sat, Sep 21, 2013 at 6:12 PM, Trishank Karthik Kuppusamy < tk47@students.poly.edu> wrote:
Hello Donald,
On 09/21/2013 05:54 PM, Donald Stufft wrote:
Is it possible to do this in a pure python library? I know there are pure python libraries for ed25119 that are written by the author so they should be good to use.
It should be possible to do in pure Python all the cryptography that TUF needs. The performance may not be so good with sufficiently large RSA keys, but I think that is a bottleneck only when creating those keys and signing metadata with those keys. Verifying signatures created by those keys should be cheap enough, and that is how most people would use TUF (for reading, not writing). Vlad, what do you think?
According to the author the pure python implementation is very slow and vulnerable to side-channel attacks, although we have not compared it against the cryptography libraries we have considered. It is also only an elliptic-curve public key signature scheme. We should consider, especially if we are being restricted to pure Python, but the Python implementation appears (IMO) to be for educational purposes.
Before we go any further, though, we would like your thoughts on the matter. Should we modify the PyPI server ourselves? Or should we wait for Warehouse instead? We want to work together with the DistUtils SIG community on all of this, and would appreciate any feedback and thoughts you have for us. What would you like to see from us?
What does an integration look like? What time frame are you looking at completing this? Warehouse is where the future of PyPI is and I'm loathe to add much else to the old code base, but Warehouse is very incomplete at the moment.
By an integration, we mean this scenario: developers will be able to
register their package-signing keys with PyPI (by uploading their public keys), and sign for package metadata themselves with their private keys. Among other things, the PyPI server will also have to change a bit to generate some TUF metadata itself.
I think it would make the most sense for us to figure out how to integrate TUF with Warehouse since that is the future of PyPI. Is now a good time for us to discuss how to do that? What is your timeframe for Warehouse?
Thanks, Trishank
participants (3)
-
Donald Stufft -
Trishank Karthik Kuppusamy -
Vladimir Diaz