Log file Viewer
#pypa logs for Tuesday the 9th of December, 2014
[11:02:55] <iElectric> any chance someone could take a look at https://github.com/pypa/pip/pull/1473
[15:17:48] <sieve> apollo13: can I generate some metadata and then upload that to S3 and point pip at it?
[15:18:15] <apollo13> I don't know S3 that well, but usually a http server with a document index is enough
[15:21:52] <sieve> Will pip be able to install whichever version of a particular package from an apache index?
[20:32:57] <AuroraBorealis> So.....may i ask what is the point of signing a wheel if pip doesn't verify it
[20:33:19] <Alex_Gaynor> AuroraBorealis: debian looks at them if they build a package... that's pretty much it
[20:36:21] <AuroraBorealis> well isn't the point signing the record.JWS file, that way if any of the files change / gets removed it knows about it?
[20:37:40] <AuroraBorealis> i mean they added the ability to sign them, so obviously there was some use case =P
[20:38:15] <AuroraBorealis> its just that pip doesn't check them, and actually invalidates them itself (by adding things to record.JWS, like .pyc files)
[20:39:06] <Alex_Gaynor> If you ahve a signature, you need a public key to verify it against. Unless you have some external mechanism for trusting public keys, just checking that a signature is valid doesn't say anything more than a simple hash.
[20:39:19] <Alex_Gaynor> https://caremad.io/2013/07/packaging-signing-not-holy-grail/ has smore details on this
[20:44:14] <AuroraBorealis> if you have your own packages signed / uploaded somewhere for that "super xtra security"
[20:59:00] <AuroraBorealis> im assuming it just follows this: https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-37#section-4
[20:59:54] <dstufft> The signatures inside of Wheels will almost certainly never be validated in pip
[21:00:55] <dstufft> For one, they are wheel specific however most things are being installed as sdists and ther eis no real reason to marry the signature scheme to the package format, the signature scheme should more or less just treat the package file as a binary blob
[21:01:32] <dstufft> for two, without some mechanism of trust a signature doesn't do anything except make people feel good because they applied some cryptography, but it adds zero additional security
[21:03:41] <dstufft> for three, even if pip added some way to say "yes I explicitly want to trust these signatures" the benefit would be so negligable as to not even matter. If you install 100 signed packages and 1 unsigned package then you've just gotten exploited potentionally and verifying the signatures on those 100 don't matter. So not only do you need the ability to sign the packages, and the ability to determine who to trust, you need to make the process easy
[21:10:08] <doismellburning> dstufft: I disagree with "doesn't matter" (it sounds rather like the worrying "security is a yes/no question" rubbish that comes up"), but sure
[21:36:46] <dstufft> doismellburning: Can you tell me in what situations installing 100 signed packages and 1 unsigned packages made you safer?
[21:37:41] <AuroraBorealis> well right now the limiting factor is pypi, which you hope that no one gets their credentials stolen and uploads a malicious build
[21:38:15] <dstufft> right, but as soon as you install 1 unsigned package from a particular source you've opened yourself up to being exploited
[21:38:33] <dstufft> does it really matter if the exploit code you downloaded was run as part of django-foo instead of Django
[21:39:10] <AuroraBorealis> no, but im guessing the idea is going towards a solution that doesn't require installing unsigned packages
[21:39:28] <AuroraBorealis> cause actualy someone stealing someones pypi credentials would be very bad lol
[21:42:15] <dstufft> I am pretty much opposed to adding any feel good cryptography that doesn't fundamentally address the issues of trust and usability
[21:42:48] <AuroraBorealis> well the whole wheel signature thing, i thought that was more like, a developer putting up the sha1 hashes on their website
[21:43:17] <AuroraBorealis> you know it came from _them_ at least, and would maybe through something would prevent someone haxing their pypi account and uploading a bad build of django
[21:44:28] <AuroraBorealis> only solution i know is like ubuntu PA's where you gotta manually add the keys which is annoying
[21:44:49] <dstufft> there are like 20 different reasonable technologies that get you some cryptography
[21:45:15] <dstufft> and without trust the cryptography doesn't do anything but make people feel good
[21:45:17] <AuroraBorealis> but even if wheel isn't very good for pypi, if you are developing stuff and have your own builds of packages, i feel there should be an option to verify the signatures that all come from you
[21:46:06] <dstufft> AuroraBorealis: pip verifies TLS, you can verify that they all came from a server you control by making your own CA Bundle
[21:46:47] <AuroraBorealis> ehhh, either you buy your own cert or you self sign and then you gotta put that on the server, which is the same amount of work as just verifiyng the wheel sigs
[21:47:24] <dstufft> except A) it works for more than just Wheels and B) it also works on PyPI itself
[21:47:50] <AuroraBorealis> can you even do that without installing the cert to the whatever keychain the OS uses?
[21:48:37] <dstufft> with the next version of pip (6.0) you can even use a client cert too to verify that the pip that is doing the install is allowed to access those packages
[21:49:41] <dstufft> the server certificate proves that the server holds a particular private key, the client certiifcate proves that the client holds a particular private key
[21:52:07] <dstufft> it has benefits over TLS for sure, namely that it reduces the attack surface (right now a compromise of PyPI itself can compromise all packages since TLS requires an "online" key) and that it allows trust to be "transferred" easier. e.g. right now you can't use a mirror of PyPI without trusting that mirror, since TLS only protects you to the place the TLS is terminated, but with package signing a mirror just serves the sigs and you can verify
[22:18:34] <dstufft> doismellburning: you don't reduce the number of vectors though if you don't install all the packages from a particular source signed
[22:23:17] <AuroraBorealis> im like, if they stole your email, then they reset the password, use the email for two factor, then blam
[22:36:01] <doismellburning> dstufft: and then you have a platform for turning your opt-in signing to opt-out to compulsory
[22:36:24] <dstufft> doismellburning: or we could just design it from the get-go with usability in mind :D
[22:36:57] <doismellburning> it's nice to live in the academic world of "that's imperfect so fatally flawed", but it does exclude some routes
[22:37:59] <dstufft> the system we're looking it as imperfect, but it can be designed up front with usability in mind and with the medium it's being applied to
[22:39:28] <dstufft> doismellburning: I said it's based on TUF, they have a website, there's also one or two PEPs but I haven't reviewed those yet
[22:41:33] <dstufft> i eman if you just want some feel good crypto, PyPI already lets you upload pgp signatures, hardly anyone does it though
[22:48:01] <carljm> dstufft: I GPG sign all my releases! I would be surprised if a single person had ever checked those sigs, though.