Re: [Catalog-sig] Merge catalog-sig and distutils-sig
That should work. Sounds like a plan. On Thu, Mar 28, 2013 at 4:04 PM, holger krekel hol...@merlinux.eu wrote: On Thu, Mar 28, 2013 at 15:42 -0400, Donald Stufft wrote: On Mar 28, 2013, at 3:39 PM, PJ Eby p...@telecommunity.com wrote: On Thu, Mar 28, 2013 at 3:14 PM, Fred Drake f...@fdrake.net wrote: On Thu, Mar 28, 2013 at 2:22 PM, Donald Stufft don...@stufft.io wrote: Is there much point in keeping catalog-sig and distutils-sig separate? No. The last time this was brought up, there were objections, but I don't remember what they were. I'll let people who think there's a point worry about that. Not sure if there's some official process for requesting it or not, but I think we should merge the two lists and just make packaging-sig to umbrella the entire packaging topics. There is the meta-sig, but the description is out-dated: http://mail.python.org/mailman/listinfo/meta-sig and the last message in the archives is dated 2011, and sparked no discussion: http://mail.python.org/pipermail/meta-sig/2011-June.txt +1 on merging the lists. Can we do it by just dropping catalog-sig and keeping distutils-sig? I'm afraid we might lose some important distutils-sig population if the process involves renaming the list, resubscribing, etc. I also *really* don't want to invalidate archive links to the distutils-sig archive. All in all, +1 on not having two lists, but I'm really worried about breaking distutils-sig. We're still going to be talking about distribution utilities, after all. Don't care how it's done. I don't know Mailman enough to know what is possible or how easy things are. I thought packaging-sig sounded nice but if you can't rename + redirect or merge or something in mailman I'm down for whatever. I've moved lists even from external sites to python.org and renamed them (latest was pytest-dev). That part works nicely and people can continue to use the old ML address. Merging two lists however makes it harder to get redirects for the old archives. But why not just keep distutils-sig and catalog-sig archives, but have all their mail arrive at a new packaging-sig and begin a new archive for the latter? holger - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] A modest proposal for securing PyPI with TUF
On Wed, Mar 13, 2013 at 5:13 AM, Trishank Karthik Kuppusamy t...@students.poly.edu wrote: Hello Nick, On 3/13/13 4:09 AM, Nick Coghlan wrote: - the PSF board generally stays out of the technical details of running the python.org infrastructure, so it's likely that any root keys would be handled by the PSF infrastructure committee. A (2, 4) or (3, 5) trust configuration would likely be manageable at this level. Understood. We think a higher (t, n) [where t out of n signatures are needed to trust the metadata for a role] is better for the root role simply because its crucial metadata (the authorized keys for top-level roles) should change very rarely. - at the target delegation level, PyPI supports the registration of new projects through the web service (see http://docs.python.org/2/distutils/packageindex.html). If my understanding of target delegation is correct, this means the simple and packages/source/letter delegations will need to be (1, 1) and online. - higher levels of the target delegation hierarchy could conceivably be kept offline, but there seems little value in doing so if they're trusting on online (1, 1) key Fortunately, the targets/simple and targets/packages/(version)/(letter)/ roles should not require (1, 1) online keys, as their metadata (simply target delegations and no actual target files) should also fluctuate fairly rarely. I should make this clearer in our design document. - many PyPI packages are maintained by single developers, so (1, 1) or (1, n) is likely to be the only generally feasible level of signing at the project level. Yes, the package developers themselves could choose any (t, n) they like. In our design, we propose that PyPI could eventually delegate to stable packages which need little change (and use more security with more offline keys) and to unstable packages which need frequent change (and use less security with more online keys). With the current focus being on getting an improvement from the status quo that we can successfully deploy in a reasonable period of time, the target delegation side of things probably needs to be substantially simpler in the initial iteration. Yes, it leaves us open to certain vulnerabilities we would like to remove in the long run, but we need to be very cautious in the additional demands we place on the users uploading to PyPI. It may even mean the initial iteration allows projects to rely on a PyPI provided signing key for their TUF metadata, using the existing upload mechanisms to add the files to PyPI. I agree that there is a delicate problem of balancing security with usability here, especially in the beginning. You raised a very good issue there: on first migration, how would PyPI accommodate packages which have not had their target files delegated to their developers? We imagine that in this case, PyPI could assume initial responsibility for these packages, and later PyPI would delegate those packages to their respective developers. Thanks for your input, Trishank With all the different kinds of metadata, It's interesting to note that currently TUF seems to only be concerned with the available file names and their integrity. (Some of us will think of PEP 426 PKG-INFO first when we hear the word metadata.) It looks like the D metadata lists all the filenames for Django, and then Django lists them again with hashes and signatures. Why all the lists? Does every Django release re-assert all the versions of Django that are available on the index? How might I deal with producing the official source distribution myself and having a friend produce the official Windows build of a package? As an aside PyPI has been doubling in size every 1.5 - 2 years. Thanks Daniel Holth ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] V3 PEP-draft for transitioning to pypi-hosting of release files
On Wed, Mar 13, 2013 at 3:33 PM, M.-A. Lemburg m...@egenix.com wrote: On 13.03.2013 20:08, Donald Stufft wrote: On Mar 13, 2013, at 2:57 PM, M.-A. Lemburg m...@egenix.com wrote: On 13.03.2013 12:21, holger krekel wrote: [V3 proposal] I must say, don't like this change in motivation compared to V1 and V2. The original of the discussion was to make PyPI more secure and the installation process faster and more reliable by moving away from crawling arbitrary external web pages. Both can be had by: * limiting the crawling to package author defined specific URLs, with added hashes to make sure that the URLs and their target content is not modified (this is the securing external downloads part - see here for an example: https://pypi.python.org/pypi/egenix-pyopenssl/0.13.1.1.0.1.5), and * adding a way for the package authors to say PyPI, please go ahead and cache/copy my distributions files (this is the increase download reliability part - can be had by doing opt-in CDN caching/proxying of external links via PyPI) Now, with V3 of the proposal, you are moving towards a system that basically says do it this way, or stay out of our eco system, which, in my book, is not what the Python eco system is all about. I don't see how? The -with-externals index will still contain all the existing links, and indeed PJ Elby has already stated that setuptools will move to support this index by default but with proper warnings to people so they know they are installing a package off site. This allows existing tools to be moved to a secure by default position. Allows future tools to choose if they want to enable the existing behavior through use of -with-externals (hopefully with a warning or opt-in sort of thing like laid out by PJE, but it's certainly not required). And even allows users of existing tools to opt into the old behavior via the -i option. Maybe i'm missing it but in what way does this force authors to do it this way or stay out of our eco system since all the same options are available as there are today? The proposal marks all external links as evil, and instead of making external links more secure, the user is left with the option to either not enable external links at all, or to let the devil in :-) That's not nice. It's also security theater. The real problem is unreviewed code getting executed by users, or worse, automated build systems. Yet, we let users believe that everything is secured on PyPI. Taking an extreme position, it would probably be better just leave everything as it is and instead educate users about the risk they are taking with a pip install AngryBirds, signed with keys issued by the PSF on the official PyPI server, delivered straight to your drive via the latest in crypto technology, only to wipe your notebook... But then, I don't like extreme positions, so would rather like to incrementally improve the situation both from the server and the client side, both addressing user and author concerns, and keeping the Python eco system a friendly place to be. Your V2 was much more inviting in this respect. Perhaps it would be better to decide whether it is reliability theater and concentrate on consistency rather than whether the code actually does what you want. It is nice to have a system that at least prevents targeted third party bad-package attacks. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] A modest proposal for securing PyPI with TUF
On Wed, Mar 13, 2013 at 8:11 PM, Trishank Karthik Kuppusamy t...@students.poly.edu wrote: On 03/13/2013 02:15 PM, Daniel Holth wrote: With all the different kinds of metadata, It's interesting to note that currently TUF seems to only be concerned with the available file names and their integrity. (Some of us will think of PEP 426 PKG-INFO first when we hear the word metadata.) Yes, you are right that the many different kinds of metadata in this discussion (TUF metadata, PyPI metadata) makes things a little confusing sometimes! :)) My understanding of PEP 426 is that the distribution metadata is specified by the developer with the setup.py script. To take the running Django example, since the Django developers will sign everything under the Django role with their own keys that the D role will talk about, setup.py, as well as the generated PKG-INFO, will be signed by the Django developers. This means that pip + TUF will be able to verify these distribution metadata indirectly via the source distribution package. Does this answer your question? Thanks, yes. The individual .tar.gz distributions do contain PKG-INFO but we would eventually like to expose it in a more efficient way. Then to be suitably paranoid you would also have to check that it matched the package you downloaded! :( Also note that on http://crate.io the simple index works the same way as on pypi, except that the actual packages are on a different (CDN) host. Thanks, Daniel It looks like the D metadata lists all the filenames for Django, and then Django lists them again with hashes and signatures. Why all the lists? Does every Django release re-assert all the versions of Django that are available on the index? Good observation. For D, you are talking about the paths attribute here: https://updateframework.com/pypi/repository/metadata/targets/packages/source/D.txt For Django, you are talking about the targets attribute here: https://updateframework.com/pypi/repository/metadata/targets/packages/source/D/Django.txt Why is paths in D listing all the targets that Django already talks about? Presently, this is because our target delegation tool (signercli.py) is being paranoid and making sure that D is explicitly delegating only targets matching these paths. However, the TUF specification allows for D to simply say, I delegate any target whatsoever under Django, by settings paths to packages/source/D/Django/**: https://www.updateframework.com/browser/specs/tuf-spec.txt#L525 How might I deal with producing the official source distribution myself and having a friend produce the official Windows build of a package? There are a few solutions. You could have your friend produce the official Windows build for a package, and then you could sign it, implicitly trusting your friend but not publishing that trust. A more secure solution would have you delegate that target to your friend. As an aside PyPI has been doubling in size every 1.5 - 2 years. Exponential growth strikes again! We have anticipated this, and we have a few solutions to curb the growth of TUF metadata. Since TUF metadata is simply text, GZIP compression would go a long way. Alternatively, we could implement delta updates of TUF metadata. The more difficult problem is how to ensure that target delegation structure scales with PyPI growth. A good design will keep this in mind and plan accordingly. Speaking of which, it may be the case that our design document for integrating PyPI with TUF may not be terribly easy to understand. (After all, you do need to understand TUF first, but TUF is fairly easy once you understand its main ideas.) I plan to publish a friendlier document which introduce TUF at a very high-level and instead discuss more pragmatic issues (such as workflows). ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] pre-PEP: transition to release-file hosting at pypi site
It will probably wind up working more like every other package manager I'm familiar with, where you have a sources.d that lists the repositories you would like to search. Use Plone, add their repository to the list. We also seem to be making good progress on contact the central repository much less often by keeping local copies of the packages you actually need. The most frustrating thing about pypi being down was that you already had a virtualenv with all the packages you actually needed, but maybe you couldn't re-install them elsewhere without contacting pypi again. Wheel signatures are handy because they travel with the archive but the eventual security system will probably look very different, at most taking advantage of the feature when available but doing something else for sdists. The trust chain is the tricky part. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] PyPI/pip security: waiting for input
Super impressed after reading all the TUF papers and comparing it to my own feeble proposal, they had addressed a whole bevy of problems that I hadn't even thought of - infinite-length download attacks, server-asserted timestamps, quorum signatures, sophisticated trust delegation, consistency of all the metadata all the time ... ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
[Catalog-sig] PEP 425 / 427 compatibility tags
On Fri, Mar 1, 2013 at 11:37 AM, PJ Eby p...@telecommunity.com wrote: On Fri, Mar 1, 2013 at 4:24 AM, M.-A. Lemburg m...@egenix.com wrote: On 01.03.2013 10:02, Reinout van Rees wrote: On 28-02-13 21:08, holger krekel wrote: I have seen that position in this discussion (I have to upload 120 files per release, so I won't do that, for instance). haven't seen that. Marc-Andre Lemburg said this, which I took to mean 120 uploads per release: However, taking our egenix-mx-base package as example, we have 120 distribution files for every single release. Uploading those to PyPI would not only take long, but also ... Correct, with a total of over 100MB per release. However, the above quote is slightly incorrect: I did not say I won't do that, just that there are issues with doing this: * It currently takes too long uploading that many files to PyPI. This causes a problem, since in order to start the upload, we have to register the release on PyPI, which tools will then immediately find. However, during the upload time, they won't necessarily find the right files to download and then fail. Actually, easy_install doesn't pay any attention to what releases are registered. It just looks for primary and secondary links. If there are links for a version that it can use, it uses it. If it does not find links for a version, then that version does not exist, as far as it is concerned. So registering without files is not a problem. The proposed pull mechanism (see http://wiki.python.org/moin/PyPI/DownloadMetaDataProposal) would work around this problem: tools would simply go to our servers in case they can't find the files on PyPI. That proposal is unnecessary, actually. You could *right now* simply place binary download links (with optional #md5= verification) in your package's description field, and the moment you registered the package, existing tools would find those links and download them from your site. You could then remove your home page and download URLs from the relevant fields, and place them also in the description. (easy_install does not follow non-download links within the description -- i.e., links that don't end in .egg, .tgz, etc. and don't have an #egg tag.) * PyPI doesn't allow us to upload two egg files with the same name: we have to provide egg files for UCS2 Python builds and UCS4 Python builds, since easy_install/setuptools/pip don't differentiate between the two variants. They can if it's part of the platform string; the catch is that right now it's not. We'd have to go through an upgrade cycle of the tools to support that. I need to take a look at what PEP 427 is doing (and you should too, if you haven't already) to get this part sorted out. The compatibility tags are specified in http://www.python.org/dev/peps/pep-0425/ and are first used with PEP 427. The scheme defines a tag which is a combination of implementation, abi, and platform tags, and an algorithm for choosing the most preferred among the available builds for a particular release of some distribution. The ABI tags are basically abbreviated versions of the tags from http://www.python.org/dev/peps/pep-3149/ and look like cp32dmu for a debug, malloc, wide unicode build of CPython 3.2, or just cp32 for a Python 3.2 with none of those features compiled in. Your package would probably use tags like cp32-cp32mu-linux_x86_64. Even though PEP 3149 is a Python 3.2 feature, the *PEP 425* ABI tags are supposed to work in the same way with older version of Python, e.g. py26u for a Python 2.6 unicode build. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Deprecate External Links
On Thu, Feb 28, 2013 at 7:43 AM, Reinout van Rees rein...@vanrees.org wrote: On 27-02-13 16:26, Donald Stufft wrote: 2. External links decrease the expected uptime for a particular set of requirements. PyPI itself has become very stable, however the same cannot be said for all of the hosts linked that the toolchain processes. Each new host is an additional SPOF. A very good practical illustration: my colleague cannot pip install mercurial right now as the mercurial.selenic.com website is down for hours now. All the download links on http://pypi.python.org/simple/Mercurial/ point at things like http://mercurial.selenic.com/release/mercurial-1.5.tar.gz I'm very happy to have a local buildout egg cache, otherwise the mercurial website's failure would bring a couple of my buildouts to a grinding halt. A couple of those project that don't bother to put their packages on pypi can bring your pip or buildout *down* quite often. Reinout I've been promoting a similar workflow with pip wheel (a proposed command present in the wheel fork of pip): pip wheel -w /wheel/directory dependency pip install --no-index --find-links /wheel/directory dependency You wind up with cached builds for every package you are using and its dependencies and only consult the index when you are willing to be surprised. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Deprecate External Links
Would it be wrong to ask for a /complex API at the same time? The simple api, with 28k package names on one page, is getting a little silly. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Python Version support in PyPI
On Wed, Feb 27, 2013 at 3:02 PM, Donald Stufft donald.stu...@gmail.com wrote: On Wednesday, February 27, 2013 at 2:59 PM, Monty Taylor wrote: Yeah - it's not so much that _I_ want to use something to know - it's more that I want pip to not try to install python3-only packages when I'm clearly running in python2. The reverse should also be true of course. I know we all want the next-gen package tools to solve our problems, but waiting on them doesn't really seem to be so workable ... how opposed would people be to adding some logic in to pip to be helpful with this? The problem is mostly pip doesn't really get much information ATM. It basically has the filename and that's all. Yep. For example, https://pypi.python.org/pypi/python-dateutil/json ; https://pypi.python.org/pypi/python-dateutil/1.5/json . This package does not declare requires_python or use classifiers, and I don't know whether requires_python would show up there anyway. pip doesn't even read those json files, but if it did it would be very slow. pip reads this page: https://pypi.python.org/simple/python-dateutil/ and I suppose also the linked labix homepage. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Deprecate External Links
On Wed, Feb 27, 2013 at 3:08 PM, Aaron Meurer asmeu...@gmail.com wrote: On Feb 27, 2013, at 1:01 PM, Donald Stufft donald.stu...@gmail.com wrote: On Wednesday, February 27, 2013 at 2:56 PM, Aaron Meurer wrote: On Wed, Feb 27, 2013 at 12:49 PM, Monty Taylor mord...@inaugust.com wrote: On 02/27/2013 02:47 PM, Aaron Meurer wrote: On Wed, Feb 27, 2013 at 11:37 AM, holger krekel hol...@merlinux.eu wrote: On Wed, Feb 27, 2013 at 19:34 +0100, Lennart Regebro wrote: On Wed, Feb 27, 2013 at 5:34 PM, M.-A. Lemburg m...@egenix.com wrote: I'm not saying that it's not a good idea to host packages on PyPI, but forcing the community into doing this is not a good idea. I still don't understand why not. The only reasons I've seen are Because they don't want to or because they don't trust PyPI. And in the latter case I'm assuming they wouldn't use PyPI at all. And of course, nobody is forcing anyone, just like nobody is forcing you to use PyPI. :-) I understood there is the idea to disable external links within a couple of months. That does break backward compatibility in a considerable way. holger But wouldn't this only be a change in pip/easy_install, not PyPI itself? I suppose you could explicitly break the external links by having them point to nothing if you are worried about the security or if it's some performance issue (that would indeed be a bad compatibility break, in case people are using those for other purposes). Otherwise, if it's a problem, then just use the old version of pip. If we don't remove the feature from pypi itself, then it won't help the folks for whom its a problem, because there will be no incentive for the folks hosting their software that way to actually upload their stuff to PyPI - which means that client-side disabling of external_links is fairly likely to never be usable. How would you remove it from PyPI itself? Would that just require changing some urls, so that pip doesn't know where to find stuff any more? Modify the PyPI software to no longer link to those urls. Right. As I was saying, this would break any other tools that might use those urls, perhaps for less nefarious purposes. But then again, that's somewhat speculative. If someone can point out something that uses them, that will be something to consider, but for now, the main thing we know uses it is pip (and easy_install), and the whole point is to break them. Aaron Meurer Sorry if this is obvious. I'm not a pip/PyPI developer. Just a package maintainer who has been irked several times by pip's/PyPI's/easy_install's idiotic external links policy. Or just expose a new no external links API the same as the simple API (pretty sure crate offers this) that will be the default in the next release of pip, giving people a little more control over when their packaging tool breaks. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] User profile: PGP Key ID
Bikeshed detected.
RSA primitives exist in pure python just fine too FYI.
In TUF (theupdateframework) key revocation is handled entirely inside the
framework. No trust comes from outside the system and something like an
OCSP server is not needed. Consider that keys can be revoked per-project
for example when a developer leaves one project and joins another. (This
has nothing to do with the signature algorithm.)
On Wed, Feb 20, 2013 at 3:25 PM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2013-02-20 21:12:18 +0100 (+0100), M.-A. Lemburg wrote:
[...]
At that point, the SSL infrastructure becomes just as difficult to
deal with as GPG/PGP, so there isn't much to win both ways, IMO.
You just have to deal with it...
And OpenPGP/GnuPG has the benefit that most prominent free software
developers use it and have done so for many years, have their keys
published in well-known keyservers, established web of trust, et
cetera. S/MIME, while interesting, lacks significant penetration
into the free software developer community and is mostly the domain
of enterprises and commercial interests.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
___
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
___
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] New PyPI stats available
Who will remember the distinction without a glossary? On Feb 18, 2013 10:31 PM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Feb 19, 2013 at 10:18 AM, Richard Jones rich...@python.org wrote: On 19 February 2013 10:03, Éric Araujo mer...@netwok.org wrote: Le 18/02/2013 17:58, Richard Jones a écrit : Thanks, I'm aware of vanity; it reports on one package. The latest-totals is all packages. I can’t say if you’re talking about a project, a release or a distribution here. package is a name registered on PyPI. release is a version of a package. A distribution isn't referred to as far as I'm aware, but could be a label applied to what PyPI calls package file - a single file related to a release. We've been trying to move to distribution as the thing projects register on PyPI to better distinguish them from the kind of package you can import directly. The general taxonomy as I understand it: - projects are an overall activity. They have policies, bug trackers, source control systems, mailing lists, developers, etc and may control multiple distributions. Hence Project-URL - distributions are what you register on PyPI: you intend to distribute Python software using that name. Hence Requires-Dist, etc. - packages and modules are the things you can actually import at runtime - most, but not all, distributions will ship exactly one module or package with the same name as the distribution - a version is a [pre-|post-]release as described in the metadata spec - sdists are source archives for a particular version of a distribution - wheels are binary archives for a particular version of a distribution - eggs are binary archives in an alternative (discouraged) format We can get away with PyPI continuing to be the Python *Package* Index (rather than the Python *Distribution* Index), because most distributions contain packages, and it isn't worth the hassle of trying to change it. It would be good to have PyPI calling distributions by that name in the UI, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] RubyGems Threat Model and Requirements
On Tue, Feb 12, 2013 at 11:27 AM, Giovanni Bajo ra...@develer.com wrote: Il giorno 12/feb/2013, alle ore 14:12, Nick Coghlan ncogh...@gmail.com ha scritto: On Tue, Feb 12, 2013 at 10:09 PM, Giovanni Bajo ra...@develer.com wrote: Hello Nick, I've added the initial Requirements and Thread Model section to my document. I've also added a section Future scenarios at the end of the document. I hope they complete what you were feeling was missing from the proposal. Thanks, that helps me a lot in understanding the overall goals of your approach - in particular, it more clearly puts several things out of scope :) Your Task #6/#7 (related to PyPI generating the trust file, and pip verifying it) are the ones where I think the input of the TUF team will be most valuable, as well as potentially the folks responding to the rubygems.org attack. My undestanding is that #6/#7 are not currently covered by TUF. So yes, I would surely value their input to review my design, evolve it together or scratch it and come up with something new. Sorry for the repetition, but I also volunteer for implementation. I don't mind if someone else does it (or a subset of it, or we split, etc.), but I think it is important to say that this is not a theoretical proposal that someone else will have to tackle, but I'm happy to submit patches (all of them, in the worst case) to the respective maintainers and rework them until they are acceptable. The rubygems.org will also be looking at server side incident response - I suspect a lot of that side of things will end up running through the PSF infrastructure team moreso than catalog-sig (although it may end up here if it involves PyPI code changes. While I do have some ideas, I don't think I'm fully qualified for that side of things. Primarily, my proposal helps by not forcing PyPI to handle an online master signing key with all the required efforts (migration, rotation, mirroring, threat responses, mitigations, etc.). If you read it, you had seen that PyPI is only required to validate signature (like pip), not sign anything. The alternative is to just use a system implemented by several PhD [candidates?] in 2010 based on years of update system experience, before pypi security was cool. A doc from last week is a hard sell. It makes sense that system package managers would not use TUF directly since those other projects are not written in Python. At first I didn't like the idea of pypi running a CA or an associated CA but I think it is a fantastic idea. There would be no key revocation or third-party keyservers, just up-to-date positive assertions (including necessary keying material) about whether a key was allowed to sign a particular package. The threshold signatures (n of m signatures required, both can be 1) feature is pretty mind-blowing as well. We should trust our servers. We already do for https, the keys are online, and it is a good thing. When pypi is hacked Martin will tell us and we can roll back to some earlier verifiable state. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] RubyGems Threat Model and Requirements
On Tue, Feb 12, 2013 at 1:39 PM, Jesse Noller jnol...@gmail.com wrote: On Tuesday, February 12, 2013 at 1:36 PM, Donald Stufft wrote: On Tuesday, February 12, 2013 at 1:22 PM, Jesse Noller wrote: On Tuesday, February 12, 2013 at 12:44 PM, Daniel Holth wrote: On Tue, Feb 12, 2013 at 11:27 AM, Giovanni Bajo ra...@develer.com(mailto: ra...@develer.com) (mailto:ra...@develer.com) wrote: Il giorno 12/feb/2013, alle ore 14:12, Nick Coghlan ncogh...@gmail.com (mailto:ncogh...@gmail.com) (mailto:ncogh...@gmail.com) ha scritto: On Tue, Feb 12, 2013 at 10:09 PM, Giovanni Bajo ra...@develer.com (mailto:ra...@develer.com) (mailto:ra...@develer.com) wrote: Hello Nick, I've added the initial Requirements and Thread Model section to my document. I've also added a section Future scenarios at the end of the document. I hope they complete what you were feeling was missing from the proposal. Thanks, that helps me a lot in understanding the overall goals of your approach - in particular, it more clearly puts several things out of scope :) Your Task #6/#7 (related to PyPI generating the trust file, and pip verifying it) are the ones where I think the input of the TUF team will be most valuable, as well as potentially the folks responding to the rubygems.org (http://rubygems.org) (http://rubygems.org) attack. My undestanding is that #6/#7 are not currently covered by TUF. So yes, I would surely value their input to review my design, evolve it together or scratch it and come up with something new. Sorry for the repetition, but I also volunteer for implementation. I don't mind if someone else does it (or a subset of it, or we split, etc.), but I think it is important to say that this is not a theoretical proposal that someone else will have to tackle, but I'm happy to submit patches (all of them, in the worst case) to the respective maintainers and rework them until they are acceptable. The rubygems.org (http://rubygems.org) (http://rubygems.org) will also be looking at server side incident response - I suspect a lot of that side of things will end up running through the PSF infrastructure team moreso than catalog-sig (although it may end up here if it involves PyPI code changes. While I do have some ideas, I don't think I'm fully qualified for that side of things. Primarily, my proposal helps by not forcing PyPI to handle an online master signing key with all the required efforts (migration, rotation, mirroring, threat responses, mitigations, etc.). If you read it, you had seen that PyPI is only required to validate signature (like pip), not sign anything. The alternative is to just use a system implemented by several PhD [candidates?] in 2010 based on years of update system experience, before pypi security was cool. A doc from last week is a hard sell. A doc from last week trying to address and triage the same things that we're looking at that could help both communities, the same threat models, the same types of trust issues? Is it really that bad that we at least *try* to work with them and cross pollinate or are we really that awesome to completely ignore them and roll our own. The Ruby Doc and TUF are different pieces of the puzzle. The Ruby Doc was written independently of TUF and is mostly a requirements/spec sheet etc. Whereas TUF has that (in some forms) but it's also an implementation of something that satisified some of the requirements. I've shown the ruby guys TUF and they are looking into using that spec (reimplementing it in Ruby ofc). Trying to solve this problem without knowing what we are trying to solve is the wrong way of doing things. Also just accepting TUF was right is also the wrong way. Determining a proper set of requirements etc first, and then evaluating the options (of which TUF is one) is the way to go. The folks in #rubygems-trust have expressed interest in sharing information/ideas in the plan/design phases and then breaking off into our own respective communities for the actual implementation. More eyes are a good thing :) Pretty much It is very cool to work with the Ruby community. Cross-language-community collaboration is an excellent result. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] RubyGems Threat Model and Requirements
On Tue, Feb 12, 2013 at 2:20 PM, holger krekel hol...@merlinux.eu wrote: On Tue, Feb 12, 2013 at 12:44 -0500, Daniel Holth wrote: On Tue, Feb 12, 2013 at 11:27 AM, Giovanni Bajo ra...@develer.com wrote: Your Task #6/#7 (related to PyPI generating the trust file, and pip verifying it) are the ones where I think the input of the TUF team will be most valuable, as well as potentially the folks responding to the rubygems.org attack. My undestanding is that #6/#7 are not currently covered by TUF. So yes, I would surely value their input to review my design, evolve it together or scratch it and come up with something new. Sorry for the repetition, but I also volunteer for implementation. I don't mind if someone else does it (or a subset of it, or we split, etc.), but I think it is important to say that this is not a theoretical proposal that someone else will have to tackle, but I'm happy to submit patches (all of them, in the worst case) to the respective maintainers and rework them until they are acceptable. The rubygems.org will also be looking at server side incident response - I suspect a lot of that side of things will end up running through the PSF infrastructure team moreso than catalog-sig (although it may end up here if it involves PyPI code changes. While I do have some ideas, I don't think I'm fully qualified for that side of things. Primarily, my proposal helps by not forcing PyPI to handle an online master signing key with all the required efforts (migration, rotation, mirroring, threat responses, mitigations, etc.). If you read it, you had seen that PyPI is only required to validate signature (like pip), not sign anything. The alternative is to just use a system implemented by several PhD [candidates?] in 2010 based on years of update system experience, before pypi security was cool. A doc from last week is a hard sell. For one, not all PHDs follow clean implementation and automated testing principles. Secondly, I appreciate Giovanni's input, work, and his offer to help with implementation. Let's not be too quick to dismiss it. On a funny sidenote, he is the only one with a successfully openssl-verified email in these security related email threads, just saying :) best, holger Well as someone whose own very similar scheme has been brutally rejected I should know better. My initial reaction was that GPG sucks and no one wants to use it. Reading the document you aren't really using GPG's signature web of trust feature. Instead, pypi maintains a well-known mapping of keys to packages and serves it over HTTPS. I don't see much difference between doing GPG and HTTPS versus running your own CA and having pypi do some other kind of online signing of the trust file. In the CA model the signature would just include the complete and recently signed keys chaining all the way back up to the (potentially offline) master key(s) and there would not be separate key retrieval traffic. Perhaps there would be a second server for key revocation apart from disassociating a key's permission to sign any particular package. I like online trust! You can send the server a challenge and get a response about what is permitted -right-now- rather than at some time in the past. If the key - package trust is secured by HTTPS you are doing online trust anyway, why not embrace it. Wheel had the same idea of Giovanni's document of transmitting singly-signed or https-secured lists of package[key] mappings, but with elliptic curve cryptography and bare, short 256-bit keys there was never any indirect referencing of keys; the complete trusted public key was included. There was also no concept of certificate chains or trust delegation. Although technically worse it may have been able to be used, implemented and understood profitably without understanding concepts such as DER encoding etc. Not cryptographically-provably yours, Daniel Holth ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Pull request to migrate PyPI to bcrypt
On Mon, Feb 11, 2013 at 10:20 AM, M.-A. Lemburg m...@egenix.com wrote: On 11.02.2013 14:49, Christian Heimes wrote: Am 11.02.2013 14:38, schrieb Donald Stufft: On Monday, February 11, 2013 at 8:15 AM, M.-A. Lemburg wrote: Giovanni Bajo wrote: Il giorno 11/feb/2013, alle ore 13:25, Jesse Noller jnol...@gmail.com mailto:jnol...@gmail.com ha scritto: Actually I was thinking about this in the shower: the likelihood that pypi users used the same passwords as they did on the wiki is probably much higher than any of us assume. Given that the passwords were unsalted in both instances, a set intersection is enough to verify. The moin wiki passwords were salted. The reason we reset the passwords, was that the attackers had access to both the salt and the hashes. What were they hashed with? Even with a salt a fast hash is trivial to bruteforce for a large number of passwords in practically no time with trivial hardware. It uses SSHA, that's sha1(password + salt) with a seven char salt. Right, should have added that information. BTW: I wonder why salt and password are usually stored together in the same place. The moin implementation also did not add any application salt to the password string before calculating the hash value (ie. x = hash(random_salt + application_salt + password)). Not sure whether passlib does, either. The salt, which should be random and unique for every user, is only there to obsolete precomputation attacks and to make sure two users will not have the same password hash even if they choose the same password. It is not a secret. IMO per-application salt should be called hash function customization. I don't think it buys you much over normal per-password salts. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] PyPI and setuptools
Sure, and I'd love to see something like pip in the std library. With wheel files (PEP 427), metadata 1.3 (PEP 426) and the database of installed packages in PEP 376 it should be possible to create a basic, but fully functional, version of a packaging tool in the stdlib that interoperates nicely with more advanced tools like pip and buildout. It would be very costly to freeze packaging innovation now. I'd like to see a version of pip that worked as a script without being importable by the current environment. The hardest part would be creating a generic interface for building wheel files that doesn't rely on distutils (but without excluding it). It would not be that difficult to write a pure-Python-only wheel builder that did not compile extensions, syntax-checked a hand-written PKG-INFO file (Metadata 1.3), and archived everything up nicely. Anyways, not using pip doesn't mean having a hopelessly outdated build system :-) You could also use buildout 2.0 or Bento :-) ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] PyPI and setuptools
On Mon, Feb 11, 2013 at 4:16 PM, Ronald Oussoren ronaldousso...@mac.comwrote: On 11 Feb, 2013, at 19:38, Daniel Holth dho...@gmail.com wrote: Sure, and I'd love to see something like pip in the std library. With wheel files (PEP 427), metadata 1.3 (PEP 426) and the database of installed packages in PEP 376 it should be possible to create a basic, but fully functional, version of a packaging tool in the stdlib that interoperates nicely with more advanced tools like pip and buildout. It would be very costly to freeze packaging innovation now. What kind of innovation do you forsee in the installation space that would conflict with adding a basic installer to the stdlib? In particular, when that basic installer would not be based on distutils, but possibly with a hook for running arbitrary build systems (possibly using a setup.cfg that contains an option that names a PyPI package that knows how to convert that sdist to a wheel archive). I can't forsee it, that's half the point. The other is that I just like pypi more than the stdlib which is one of the reasons why I'm working on packaging. http://qkme.me/3sy57m A basic installer that can install, uninstall and update a wheel (taking care of dependencies) and has a subcommand for listing installed packages should be stable enough, everything else (such as buildout functionality and other bits of pip) can stay outside of the stdlib. As long as it sucks, I'm OK with it. The it can only install from wheel restriction would be a clear way to distinguish it from its competitors. Assuming that distlib and the discussion about securing PyPI settles down before 3.4 I'd expect that most innovation related to packaging would happen on the build part (Improved tools for generating wheel archives from a source archive), and possibly advanced deployment tools (like buildouts features for generating a tree with not just python packages but also supporting software like web- and database servers). Neither of which have to live in the stdlib, while basic installation tool is a useful included battery for beginners as wel as advanced users. I'd like to see a version of pip that worked as a script without being importable by the current environment. The hardest part would be creating a generic interface for building wheel files that doesn't rely on distutils (but without excluding it). It would not be that difficult to write a pure-Python-only wheel builder that did not compile extensions, syntax-checked a hand-written PKG-INFO file (Metadata 1.3), and archived everything up nicely. I've looked at the spec and it should be easy enough to add a bdist_wheel command to distutils. I don't recall the consensus on distutils development right now, but if I recall correctly adding a new bdist subcommand would be fine, but I'm not sure if adding support for metadata version 1.3 would be fine as well. I've experimented a littlle with PEP 390 (static metadata) and that appears to work just fine. I've been using a generic setup.py file in some of my packages that dynamicly constructs a normal call to distribute.setup(), doing something simular in distutils itself should be doable as well although this should be done carefully to avoid unnecessary breakage in distribute/setuptools. The existing setuptools/distribute bdist_wheel plugin (setuptools supports plugins!) would be adaptable to distutils. Wheel does not actually require Metadata 1.3; 1.3 is only needed to express some popular packaging concepts (like dependencies and extras) that do not work/exist in distutils. Plenty of packages do not use those features. Wheel doesn't require PEP 390 either, but https://bitbucket.org/dholth/wheelhas its own similar idea of what to read out of setup.cfg for richer install requirements. Once you actually have the wheel everything is PEP-compliant. The point of wheel is that everything is very simple after you have one. A bdist_wheel command in distutils would be able to build extensions as well, even if the compiler support in distutils is not perfect (although I must admit that I've never run into serious issues beyond distutils tendency to recompile all C files in an extension when I change one of them). Anyways, not using pip doesn't mean having a hopelessly outdated build system :-) You could also use buildout 2.0 or Bento :-) Don't get me started about buildout, I've spent an afternoon gettting nowhere with a buildout script provided by a py2app/pyobjc user (and never getting to the point where I could debug the issue he was having). All tools have advantages and disadvantages, and for my way of working pip is at about neutral w.r.t. distribute. That doesn't mean pip and buildout are useless, they are just not useful enough for *me*. Ronald ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [DRAFT] Proposal for fixing PyPI/pip security
At least the papers are still online. My favorite was http://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Draft] Package signing and verification process
+1 on listening to the computer science professor. On Thu, Feb 7, 2013 at 9:06 AM, Justin Cappos jcap...@poly.edu wrote: There are a whole host of subtle problems that you can get into with security for package distribution. For some issues with handling metadata in the presence of a MITM that have been fixed in most of the popular Linux package managers: http://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf (extended version with more attacks / issues: http://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf ) Some of the difficulties with key distribution and revocation for package managers: http://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf We'd like to integrate TUF ( https://www.updateframework.com/ ) into PyPI to help out if it makes sense. In theory the integration should be straightforward. It's basically just importing a few libraries in the client tools and asking package publishers / PyPI to do an extra step to add signatures. We believe it should be incrementally deployable (i.e. work if not everyone is using TUF everywhere) without being a usability problem for anyone. We're looking into this now to see what sort of complications this may have. We do have some looming deadlines, but we'd like to get a demo together later this month. One issue I'm not sure I understand is whether or not PyPI is trusted to know which developer's key is supposed to be signing updates for a specific package. I assume this would be the case, because otherwise I don't understand how the user gets this information. If so, how often does this list get updated with new developers / key changes? (I'm trying to understand what sort of key storage is appropriate here...) Thanks, Justin On Thu, Feb 7, 2013 at 8:20 AM, Donald Stufft donald.stu...@gmail.comwrote: On Thursday, February 7, 2013 at 5:32 AM, Jesse Noller wrote: That tutorial would have to be amazingly easy, and GPG could never be a hard requirement. GPG is still annoying, clunky and painful enough that it would just become a nuisance and people would move elsewhere. So adding support? Ok; but it would have to be optional and not mandatory. I'd rather finish the ssl certs first, and get hashes upgraded from md5 to sha-256 and getting clients to enforce those just to start pip will support any of the guaranteed hashes. I added that in because I wanted sha256 on Crate.io. easy_install and Buildout probably need that still. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Draft] Package signing and verification process
Really enjoyed the (extended version with more attacks / issues: http://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf ) paper, especially how trust delegation is handled by having the repository track keys that are then used to delegate trust to individual developers, and how revocation is handled at the same speed as learning which keys are allowed rather than by CERT advisories. And how for example revoking a developer's right to publish apache wouldn't affect their ability to use the same key to publish some other software. I suppose developer-signed Python package metadata is a little different since it can change dynamically at runtime depending on code in setup.py... On Thu, Feb 7, 2013 at 9:06 AM, Justin Cappos jcap...@poly.edu wrote: There are a whole host of subtle problems that you can get into with security for package distribution. For some issues with handling metadata in the presence of a MITM that have been fixed in most of the popular Linux package managers: http://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf (extended version with more attacks / issues: http://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf ) Some of the difficulties with key distribution and revocation for package managers: http://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf We'd like to integrate TUF ( https://www.updateframework.com/ ) into PyPI to help out if it makes sense. In theory the integration should be straightforward. It's basically just importing a few libraries in the client tools and asking package publishers / PyPI to do an extra step to add signatures. We believe it should be incrementally deployable (i.e. work if not everyone is using TUF everywhere) without being a usability problem for anyone. We're looking into this now to see what sort of complications this may have. We do have some looming deadlines, but we'd like to get a demo together later this month. One issue I'm not sure I understand is whether or not PyPI is trusted to know which developer's key is supposed to be signing updates for a specific package. I assume this would be the case, because otherwise I don't understand how the user gets this information. If so, how often does this list get updated with new developers / key changes? (I'm trying to understand what sort of key storage is appropriate here...) Thanks, Justin On Thu, Feb 7, 2013 at 8:20 AM, Donald Stufft donald.stu...@gmail.comwrote: On Thursday, February 7, 2013 at 5:32 AM, Jesse Noller wrote: That tutorial would have to be amazingly easy, and GPG could never be a hard requirement. GPG is still annoying, clunky and painful enough that it would just become a nuisance and people would move elsewhere. So adding support? Ok; but it would have to be optional and not mandatory. I'd rather finish the ssl certs first, and get hashes upgraded from md5 to sha-256 and getting clients to enforce those just to start pip will support any of the guaranteed hashes. I added that in because I wanted sha256 on Crate.io. easy_install and Buildout probably need that still. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Draft] Package signing and verification process
On Wed, Feb 6, 2013 at 4:05 PM, Jesse Noller jnol...@gmail.com wrote: On Wednesday, February 6, 2013 at 4:02 PM, Donald Stufft wrote: On Wednesday, February 6, 2013 at 4:01 PM, Vinay Sajip wrote: M.-A. Lemburg mal at egenix.com (http://egenix.com) writes: Try gnupg-w32cli which is really easy to install and doesn't get in your way: http://lists.gnupg.org/pipermail/gnupg-announce/2012q1/000313.html Or, to fast-track to the binaries, look in here: ftp://ftp.gnupg.org/gcrypt/binary/ As MAL says, installation with these installers is fairly painless. Average end user: What's a GPG Or even those of us familiar and using it day to day Oh Jeez not again That is why the original wheel signing design uses no GPG, a system that has proven to be unused in practice. Hypothesis: something different cannot possibly be less successful. Instead, it uses raw public key signatures implemented with very concise Python code. It might even automatically generate one for you if you have none. Wheel's scheme would be perfect for Plone which distributes long lists of all its dependencies, as they would just add the publisher key as an argument to each dependency. A new maintainer might receive a copy of the private key as keys are meant to be plentiful and contain no extra information such as e-mail addresses. Using ssh-agent to produce signatures with the user's ssh keys is another option. There is a complete Python implementation of TLS out there. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Draft] Package signing and verification process
In this scheme Plone would publish all the public keys for all its dependencies as tested. They already pin pretty much all their dependencies. Each pinned version would have a key fingerprint added to that line in the file. Whether pgp or x509 or something else is used doesn't matter that much. The overall system design is more important. Detecting tampering is as interesting to me as absolute security. For example guardtime provides keyless signatures that assert a timestamp. On Feb 6, 2013 4:45 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Daniel Holth dholth at gmail.com writes: That is why the original wheel signing design uses no GPG, a system that has proven to be unused in practice. It's not like there's some other PKI system which is so much easier to use that it's a no-brainer, such that it has widespread adoption with the type of user that Donald was talking about. A lot of it is that people are very happy to trade security for convenience, and you can't really have additional security with *no* loss of convenience (though that loss may be small). Why, most of us can't even be bothered to read on-line license terms and conditions, preferring to click the I Agree button as soon as it appears! In the Windows world, people are used to being prompted to accept a program publisher's identity verified by a code-signing certificate, just like an SSL certificate. Of course, you can have signed malware, as is in the news this week. With Python packages, you can't easily just trust one publisher, because of all the recursive dependencies a package pulls in. It's mostly a blessing, but not in this regard. Regards, Vinay Sajip ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Use user-specific site-packages by default?
On Tue, Feb 5, 2013 at 9:28 AM, Donald Stufft donald.stu...@gmail.comwrote: On Tuesday, February 5, 2013 at 9:24 AM, Daniel Holth wrote: As long as you are trusting PyPI itself, a PyPI-hosted/signed/timestamped SHA2 hash of the file to be downloaded from an external host would be enough to detect tampering over time. You could do this, still lowers the overall availability of the system which kinda sucks, and to actually be sane and secure you'd still need to rework the current method of trolling for external urls. pip could come with a copy of PyPI's ssl certificate, verifying that it was identical to the expected cert rather than signed by one of 100s of trusted CAs. That loses the ability to change PyPI's SSL cert, basically forever and still doesn't protect MITM against someone logging into PyPI through a browser. Or it could just notify you whenever the SSL certificate changed. http://tack.io/ lets a site sign its SSL certificate with a key that doesn't change. Of course doing SSL at all is the priority. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Draft] Package signing and verification process
On Tue, Feb 5, 2013 at 2:21 PM, Christian Heimes christ...@python.orgwrote: Hello, I like to discuss my proposal for a package signing and verification process. It's just a brief draft and not a final document. (Credits to my friend Marcus Brinkmann for additional insights). Package maintainer registers PGP key Package owners and maintainer that like to sign their packages must register their PGP/GPG key in front. The key must be registered with a public key server (e.g. launchpad) and must contain an identity that corresponds with her email address. Also the key must follow certain standards (no insecure algorithms / key length) and be valid (not expired or revoked). A user can register multiple GPG keys. process: - User must provide the full fingerprint (not the short key id). - PyPI retrieves the key from a key server. - PyPI verifies the key's properties. - PyPI sends an encrypted mail to the user which contains an activation link for the key. - User decrypts the mails with her private key and actives the key with the link. result: PyPI has a verified GPG key of the package maintainer. Package maintainer signs and uploads a package --- The procedure doesn't change excepet that PyPI may revoke a signature (more on that later). The upload process must use HTTPS and the SSL server cert is validating against a CA cert bundle. result: uploader has uploaded her content and signature through a safe channel that protects against password sniffing and reply attacks PyPI accepts and validates upload - As first step PyPI validates the signature and the user's key: - Is the signature valid and matches the uploaded content? - Does the signing key match a registered GPG key of the user? - Is the user's key still valid (expiration, revocation) - Is the timestamp of the signature within a sensible range (plus minus a couple of hours?) result: PyPI has a validated signature that matches the user's settings. The time check adds an additional countermeasure against replay attacks, PyPI signs the signature Here comes the tricky part of the process. Bare with me! PyPI generates a metadata file that contains: - timestamp of the upload - metadata of the user (id, name, email ...) - metadata of the package (excerpt of PKG-INFO) - the user's signature of the uploaded content as ASCII armor Then PyPI signs the metadata files with its OWN key. It's crucial to acknowledge that PyPI does NOT sign the uploaded content! It just signs the user's signature and the package + user metadata. PyPI's signature does NOT state anything about the file's content or the correctness of the containing code. Why does PyPI sign the package then? PyPI is the only instance that can verify the relationship between an uploader and a package's content. PyPI's signature promises that PyPI trusts the user to upload and sign the package *at this very moment*. With this signature a downloader can verify that the uploader was a registered maintainer of the package at this very moment. Without the PyPI signature a downloader would have to trust a key for all available packages. result: The combined file (inner layer: metadata, user's signature, outer layer: PyPI signature) certifies that the uploader has a relationship to the project on PyPI. User installs package - process: - tool retrieves the package and the combined signature file (PyPI's signature, metadata file and embedded signature of the uploader) - tool optionally downloads missing GPG keys from PyPI - tool verifies PyPIs signature of the metadata file and then the uploader's signature of the content - on success tool install the package The verification process needs some interaction with the downloader. She must accept and establish a trust level with each key. This needs to be discussed in detail. Open points --- - Should we allow multiple users for a single GPG key (e.g .team keys)? - Should the tool chains use its own key rings for verification instead of the user's default keyring? A tool like http://man.he.net/man8/apt-key might be useful. - An uploader must be able to revoke her keys from PyPI without access to her private key. - When a package owner removes a user from the maintainer list of a package she must be able to remove all signatures of a user, too. - PyPI should have a hidden and well protected private key that is used to sign a transitional signing key. The signing key is used for a couple of months and then replaced by a new signing key (with grace periode). Questions? Christian ___ Catalog-SIG mailing list Catalog-SIG@python.org
Re: [Catalog-sig] [PSF-Members] Howto Guide for MITM attacks on PyPI
http://convergence.io/ is a useful system. It provides protection against MITM attacks by using network perspective: you ask notary servers located elsewhere on the Internet to verify the certificate of a site you visit. If the notary servers see the same certificate you do then you know the local network is not being attacked; the MITM would have to be on PyPI's side of the network. http://tack.io/ is another interesting system that allows a site to assert ownership of its own SSL certificate apart from the CA system. These systems are useful in a world where browsers trust hundreds of CAs to vouch for the identity of any site. Tack reminds me of the ssh security model in practice: in ssh, I usually trust keys the first time I see them, and SSH warns me when a host's key changes. This kind of security is very useful in practice; I would be more likely to accept a new SSH key when on my own network than at pycon and I might already have all the keys I need by the time I got there. On Mon, Feb 4, 2013 at 8:35 AM, Donald Stufft donald.stu...@gmail.comwrote: On Monday, February 4, 2013 at 8:31 AM, Giovanni Bajo wrote: Not that I'm against it doing it on the server side for now, anyway. It'll still be useful to users manually browsing to PyPI. This is where it's important. If you're capable of MITM'ing pip you're capable of MITM'ing a web browser. It would not be a fun day if a password (or session cookie) got stolen via a MITM because someone signed on in a coffee shop (or at Pycon etc). ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] getting the public key when --sign is used
Unfortunately the whole signed mirror system falls down because it relies on md5 hashes (http://www.kb.cert.org/vuls/id/836068) although the signing key seems to be long enough. What would it take to get SHA-2 (or 3) added? ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] getting the public key when --sign is used
On Nov 19, 2012, at 5:40 PM, mar...@v.loewis.de wrote: Zitat von Daniel Holth dho...@gmail.com: Unfortunately the whole signed mirror system falls down because it relies on md5 hashes (http://www.kb.cert.org/vuls/id/836068) although the signing key seems to be long enough. You are misinterpreting the vulnerability. It does not apply to the way in which md5 is used in PyPI. So in no way the system falls down. Regards, Martin I can't create two colliding uploads, uploading the first (harmless version) to pypi and then tricking someone into mirroring the second (harmful) version? The system is not designed to protect the uploaded contents at all? Perhaps it doesn't fall down for some reason, but the cert recommendation is: Do not use the MD5 algorithm Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use. So why not start using sha256? The site would appear more modern, and at the very least people like me would stop complaining about it.___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] getting the public key when --sign is used
On Nov 19, 2012, at 6:08 PM, mar...@v.loewis.de wrote: Zitat von Daniel Holth dho...@gmail.com: I can't create two colliding uploads, uploading the first (harmless version) to pypi and then tricking someone into mirroring the second (harmful) version? The system is not designed to protect the uploaded contents at all? It *is* designed to protect the uploaded contents, but not against the uploader. Instead, it protects against some mirror operator replacing a mirrored file, or some attacker taking over a mirror. If you assume that the package author is malicious, adding SHA hashes would not help at all. The package author can just upload a new version, and get it mirrored to all copies (including the master), and nothing in the mirroring protocol prevents that new version from containing a trojan horse. All hashes would be intact and fine, and the mirror be consistent with the master. So why not start using sha256? It's not that simple. Backwards compatibility needs to be considered. Feel free to write specifications and patches. And please stop making FUD claims. Regards, Martin Ok. We aren't protecting against the uploader. My real complaint is only that md5 hasn't been a recommended primitive since 1998. I will see about that patch. Pip at least understands #sha256=... ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Distutils] accept the wheel PEPs 425, 426, 427
On Fri, Nov 16, 2012 at 1:05 PM, Vinay Sajip vinay_sa...@yahoo.co.ukwrote: Daniel Holth dholth at gmail.com writes: The Bento author has his own informed opinions about the way packaging should work which do not necessarily include the packaging PEPs. That's all well and good, but there needs to be a common infrastructure for interoperability, which is what the PEPs are about. Bento has ploughed its own furrow because of the difficulty of extending distutils. But packaging seems to be an area when a particular approach can't succeed (other than in a niche) without some level of consensus; setuptools, it seems, managed it because it was number one in a field of one. I've seen you being complementary about Bento's beautiful design, but I haven't been able to find enough documentation about this design to allow me to make my own assessment. I've looked at the documentation linked to from the GitHub home of the project, which leads to http://bento.readthedocs.org - is that the most current documentation? I found myself generally in agreement with that documentation when it refers to the drawbacks of distutils and why Bento. However, details on the design itself seem a little too light to make an assessment about how Bento. For example, I get the sense that Bento's main focus is on building packages rather than installing them (which is fine, since that's the harder part, particularly when you are working with complex packages like numpy and scipy). However, I can't for example see how you would configure compiler options. Of course the source is available and I've cloned it to have a look, but those kind of things are in bento/private and bento/backends and it's not really clear what public APIs might look like. Of course one of the problems with distutils was under-documentation, leading to everything being regarded as public API, and we know where that's led. The heavy lifting in Bento seems to be in something called yaku, to which I see only passing references in the Bento documentation and not much apart a README on the yaku GitHub page. I'm probably being dense, so I'd be grateful if you'd share how you arrived at your very positive assessment of the quality of Bento's design: was it by grokking the source, or is there some documentation I've missed? Just to be clear: I've nothing at all against Bento, I'm just trying to understand how it's put together. He did say he will support the PEPs when they are done. IIUC David would prefer, for example, a more rpm-like design with an actual database of installed packages rather than files scattered everywhere. In the meantime it's fairly easy to support eggs and wininst and sdist and wheel. My informed opinion comes from writing a build_wheel command for Bento at https://github.com/dholth/Bento/commit/66c457685009de46f2d36a6e016e498ab783ceeb It was much easier than writing bdist_wheel for setuptools because the Bento code is much cleaner and the different phases of build / compile / install / etc. are nicely separated. The setuptools bdist_wheel has to grab the install command and overwrite all the install_* properties to get the paths right. It has to run in the same process. I should probably mention that all the inconvenience is due to the underlying distutils design; setuptools makes bdist_wheel possible because it has a plugin architecture. The Bento build_wheel declares a dependency between itself and the build command. When you run build_wheel the build command and all of its dependencies run, writing internal Bento metadata about the build to disk. After build has run, build_wheel does not have to touch the other commands. It just reads the internal metadata and creates the archive. yaku is one way Bento can build C extensions. Bento can also use waf or distutils' own compiler abstraction. One potential deal breaker: David uses \ in his code. You will have to get over it if you want to use Bento. :-) Daniel Holth ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs 425, 426, 427
On Nov 14, 2012, at 2:23 AM, Ronald Oussoren ronaldousso...@mac.com wrote: On 13 Nov, 2012, at 17:21, Antoine Pitrou solip...@pitrou.net wrote: Le Tue, 13 Nov 2012 16:10:30 +0100, Ronald Oussoren ronaldousso...@mac.com a écrit : On 13 Nov, 2012, at 16:00, Daniel Holth dho...@gmail.com wrote: I want to remove distutils from the standard library. Why? Distutils may not be perfect, but is usable for basic packages. It could even be enhanced to support these peps and be even more useable, although patches for that would run into the self-imposed freeze of distutils development. It wouldn't be totally unreasonable to start a project named distutils2 to build the next-generation distutils library. Oops :-) Or carefully enhance distutils itself. Rewriting distutils in one go seems to be too ambitious with the limited resources available to do so. That has been tried already (setuptools, distribute, distutils2). Instead, try bento (http://cournape.github.com/Bento/). Hilariously everyone I've showed it to is immediately put off by the indentation based syntax (who would use such a thing?) but the project has a few years of effort behind it and is well designed. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs 425, 426, 427
Well, you can build eggs with Bento, and I have a patch that allows it to build wheels, in both cases it will produce pip-compatible metadata. The Bento author has his own informed opinions about the way packaging should work which do not necessarily include the packaging PEPs. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs 425, 426, 427
On Tue, Nov 13, 2012 at 5:26 AM, M.-A. Lemburg m...@egenix.com wrote: On 13.11.2012 10:51, Martin v. Löwis wrote: Am 13.11.12 03:04, schrieb Nick Coghlan: On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth dho...@gmail.com mailto:dho...@gmail.com wrote: I think Metadata 1.3 is done. Who would like to czar? (Apologies for the belated reply, it's been a busy few weeks) I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated with some additional rationale based on Ronald's comments later in this thread, though. For the record, I'm still -1 on PEP 427, because of the signature issues. The FAQ in the PEP is incorrect in claiming PGP or X.509 cannot readily be used to verify the integrity of an archive - the whole point of these technologies is to do exactly that. The FAQ is entirely silent on why it is not using a more standard signature algorithm such as ECDSA. It explains why it uses Ed25519, but ignores that the very same rationale would apply to ECDSA as well; plus that would be one of the standard JWS algorithms. In addition, the FAQ claims that the format is designed to introduce cryptopgraphy that is actually used, yet leaves the issue of key distribution alone (except that pointing out that you can put them into requires.txt - a file that doesn't seem to be specified anywhere). I agree with Martin. If the point is to to protect against cryptography that is not used, then not using the de-facto standard in signing open source distribution files, which today is PGP/GPG, misses that point :-) Note that signing such distribution files can be handled outside of the wheel format PEP. It just way to complex and out of scope for the wheel format itself. Also note that PGP/GPG and the other signing tools work well on any distribution file. There's really no need to build these into the format itself. It's a good idea to check integrity, but that can be done using hashes. PGP-on-pypi is the very definition of cryptography that isn't used. I'm willing to go ahead and move any mention of signing algorithms into a separate PEP, leaving only the basic manifest hash vs. file contents verification under the auspices of this PEP. Is the rest of the wheel specification, explaining how packages are actually produced and installed, clear? I want to remove distutils from the standard library. If that happens then we might want a secure way to install it from pypi. One way would be to include the public key used to sign distutils in Python's own signature-verifying bootstrap wheel installer, never mind whether it used ECDSA or RSA or Ed25519. Do you have a better idea? TUF? https://www.updateframework.com/wiki/SecuringPythonPackageManagement ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Distutils] [Python-Dev] accept the wheel PEPs 425, 426, 427
On Tue, Nov 13, 2012 at 12:23 PM, Martin v. Löwis mar...@v.loewis.dewrote: I want to remove distutils from the standard library. If that happens then we might want a secure way to install it from pypi. One way would be to include the public key used to sign distutils in Python's own signature-verifying bootstrap wheel installer, never mind whether it used ECDSA or RSA or Ed25519. Do you have a better idea? TUF? https://www.updateframework.**com/wiki/**SecuringPythonPackageManagemen** t https://www.updateframework.com/wiki/SecuringPythonPackageManagement It depends on the threat model - whose definition is key to any security discussion. I'd say that providing the CA certificate of the CA, and to use https for downloading, should be enough. Alternatively, if the threat is that somebody may have hacked PyPI, then hard-code the hash (SHA-3 if you are paranoid) in the Python distribution, and rely on downloading a specific version from PyPI. OTOH, I'm -1 on removing the code from Python in a way that it may come back through downloading. Instead, it is much easier to keep it included. It is a long term goal. It would be more practical to discourage distutils and encourage users to look elsewhere (Bento) for a beautifully designed build system. The short term goal is just to standardize a way to install packages without having a build system, which is what wheel is for apart from the practical goal of simply installing lxml in a reasonable amount of time. I think Metadata 1.2 (PEP 426) is ready to be accepted. The compatibility tags (PEP 425) need some additional text in the discussion section, any contributors for https://bitbucket.org/dholth/pep425tags/ ? Wheel (PEP 427) might mention that version 1.0 of the spec is only concerned with losslessly representing existing (setuptools distutils) packages without trying to add too many new features apart from a standardized .egg substitute. distutils itself is not testable. Daniel Holth ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] [Python-Dev] accept the wheel PEPs 425, 426, 427
I think Metadata 1.3 is done. Who would like to czar? On Oct 22, 2012 12:53 PM, Daniel Holth dho...@gmail.com wrote: http://hg.python.org/peps/rev/50e8ea1a17a0 Based on the other required field's absence in the wild, only Metadata-Version, Name, Version, and Summary are required. Hopefully a clearer explanation of 0, 1, or many occurrences of each field. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
[Catalog-sig] what is _pypi_ordering?
In the JSON API to pypi, what is _pypi_ordering? Is this really the API documentation? http://wiki.python.org/moin/PyPiJson ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] lxml pip issue
I suppose you know about installing directly from a downloaded sdist using pip, the pip download cache, and find-links On Sep 8, 2012 8:08 AM, Daniele Procida dani...@vurt.org wrote: I am not able to install lxml using pip. Other packages seem to be OK. I had the same issue last week. Even wget from pypi produces errors: http://dpaste.com/796201/ With pip: http://dpaste.com/796198/ and with pip -v: http://paste.pound-python.org/show/25460/ Is this a pypi issue? Daniele ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Wheel format now supported
On Fri, Aug 17, 2012 at 8:45 AM, Martin v. Löwis mar...@v.loewis.de wrote: I just added support for the wheel format to the PyPI file upload interface. If this causes problems to existing tools, please submit a bug report. +1 ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Wheel format now supported
Uploading a wheel to the cheese shop: Install wheel (from pypi) Use setuptools in your setup.py 'python setup.py bdist_wheel upload' ? Profit! Thanks again for implementing this in pypi. Daniel ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Wheel format now supported
The pip developers are interesting in supporting wheel after their upcoming release. Wheel installations work as long as you are using distribute = 0.6.28. It works with virtualenv, but no one has tried to write what would surely be called zc.recipe.wheel for buildout. After you install a wheel, it is just a PEP-376 compatible distribution, so it stores its metadata in a .dist-info directory instead of in .egg-info. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] ANN: pythonpackages.com beta
On Wed, Aug 1, 2012 at 2:11 PM, Eric P. Mangold e...@teratorn.org wrote: Neat. I look forward to using this stuff... Try the demo. The format works well for the initial use case lxml takes too long to compile and can be used to build virtualenvs in record time. The digital signatures piece is not finished, and the installer does not currently check the compatibility tags (whether the wheel is expected to run on the installing Python), but pip install --find-links directory-of-cached-wheels somepackage works great (with the patched pip). I mention wheel in this forum because pypi doesn't accept them for upload yet, a feature which we will want after getting enough feedback on the basics of the format. For test.pypi? Daniel Holth ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] ANN: pythonpackages.com beta
Perhaps you would be interested in the Wheel package format's upcoming public key signature system (wheel.rtfd.orgl#signed-wheel-files). The (undocumented) plan will include per-buildserver, per-package and possibly per-package-version signing keys via a pluggable trust model, instead of the PGP model where a signing key is an e-mail address. About wheel A wheel is a ZIP-format archive with a specially formatted filename and the .whl extension. It is designed to contain all the files for a PEP 376 compatible install in a way that is very close to the on-disk format. A simple wheel for Package-1.0 would contain package.py Package-1.0.dist-info/METADATA (PEP-376, PEP-345 'Metadata 1.2') Package-1.0.dist-info/WHEEL (metadata for this build of the dist) Package-1.0.dist-info/RECORD (extended PEP-376) The bdist_wheel setuptools plugin and egg2wheel and wininst2wheel allow you to create wheel archives without having to modify source dists. ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] PyPI OAuth documentation
If you take a look at the convergence system and make sure different parts of the net see the same key, or just do what ssh does and assume the key won't change after the first time, those are good solutions. Of course it really should just have a ca signature too. Daniel Holth On Jul 27, 2012, at 2:36 AM, Richard Jones r1chardj0...@gmail.com wrote: I'm not sure we can securely distribute the PEM to all the potential users. A better solution is to have a Real SSL Certificate, but that effort keeps failing :-( On the other hand, Kenneth just released a new version of requests which removes the need to use my branch :-) Richard On 27 July 2012 11:45, Daniel Holth dho...@gmail.com wrote: You can also pass the expected ssl certificate to requests, but I'm not sure of the exact syntax (see the advanced use section of their docs). This is the most secure option if you know which cert the server should present. Daniel Holth On Jul 26, 2012, at 9:34 PM, Richard Jones r1chardj0...@gmail.com wrote: On 27 July 2012 11:17, Richard Jones r1chardj0...@gmail.com wrote: Note that you need to use my branch of requests for this to work (https://github.com/r1chardj0n3s/requests) and rauth currently needs to be modified to handle unverifiable SSL certificates. The author of rauth has shown me how to avoid the modification; the code on the wiki page now works with the current un-modified rauth release. Richard ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] PyPI OAuth documentation
You can also pass the expected ssl certificate to requests, but I'm not sure of the exact syntax (see the advanced use section of their docs). This is the most secure option if you know which cert the server should present. Daniel Holth On Jul 26, 2012, at 9:34 PM, Richard Jones r1chardj0...@gmail.com wrote: On 27 July 2012 11:17, Richard Jones r1chardj0...@gmail.com wrote: Note that you need to use my branch of requests for this to work (https://github.com/r1chardj0n3s/requests) and rauth currently needs to be modified to handle unverifiable SSL certificates. The author of rauth has shown me how to avoid the modification; the code on the wiki page now works with the current un-modified rauth release. Richard ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
