Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 29, 2013, at 10:41 PM, Antoine Pitrou solip...@pitrou.net wrote: Paul Moore p.f.moore at gmail.com writes: Personally, none of the changes have detrimentally affected me, so my opinion is largely theoretical. But even I am getting a little frustrated by the constant claims that what we have now is insecure and broken, and must be fixed ASAP. FWIW, +1. You may be paranoid, but not everyone has to be (or suffer the consequences of it). Security issues should be fixed without breaking things in a hassle (which is the policy we followed e.g. for the ssl module, or hash randomization). You missed a key word … when possible. If there is a problem we will fix it, when we can do that in a way that minimizes breakages we will do that. Its all just about cost-benefit, and when you are talking about executing code downloaded from the internet it becomes quite easy to see benefits outweighing costs even with pretty major UX changes. Not something we do lightly, but status quo does not win here, sorry. The whole python.org infrastructure is built on an OS kernel written by someone who thinks security issues are normal bugs. AFAIK there is no plan to switch to OpenBSD. This is news to me, we specifically run Ubuntu LTS because Canonical's security response team has a proven track record of handling issues. If you mean that Linus doesn't handle security issues well, then it is fortunate indeed that we don't actually use his software. --Noah signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 1:41 AM, Antoine Pitrou solip...@pitrou.net wrote: Paul Moore p.f.moore at gmail.com writes: Personally, none of the changes have detrimentally affected me, so my opinion is largely theoretical. But even I am getting a little frustrated by the constant claims that what we have now is insecure and broken, and must be fixed ASAP. FWIW, +1. You may be paranoid, but not everyone has to be (or suffer the consequences of it). Security issues should be fixed without breaking things in a hassle (which is the policy we followed e.g. for the ssl module, or hash randomization). People are generally not paranoid until they've been successfully attacked. I *will* advocate and push for breaking things where security is concerned because regardless of if you care or not, a lot of people *do* care and the nature of the beast is that you're only as strong as the weakest link. This particular change wasn't an immediate vulnerability that I felt was urgent, hence why I've backed off on it when people were concerned about the backwards compat implications. I will not back off when it comes to issues that *do* have an immediate or near term issue, regardless of if some people don't care or not. The whole python.org infrastructure is built on an OS kernel written by someone who thinks security issues are normal bugs. AFAIK there is no plan to switch to OpenBSD. So classifying bugs as security vs normal is supposed to make it easier on people. The thought is that creating new releases and applying updates is a time consuming process and often times requires things such as reboots or service restarts so by dividing issues up into security vs not security the amount of disruption can be minimized for only important updates. There's actually pretty strong evidence that shows the process of classifying bugs as security bugs is a harmful process and that all updates should be treated the same because it's often times not immediately obvious what the security implications are, even to security experts[1]. I'm sure your dig at the OS is supposed to be some sort of masterstroke about how we're not being as secure as possible anyways however I would contest that OpenBSD is actually more secure. It's major claim to fame is that they haven't had a vulnerably in the OpenBSD base system in a heck of a long time. The problem is the OpenBSD base system is terribly small and that claim cannot be made once you include their packages. Further more at the last I checked OpenBSD does not provide (although this may have changed) and abilities to do MAC which means you're relying entirely on an attackers ability to *not* get in versus providing fail safes to contain an attack once it's happened. Infrastructure is not using MAC currently but I would love to get us to that point as well. [1] citeseerx.ist.psu.edu/viewdoc/download;jsessionid=7B6E224144709E99B7FAEBFC497621A1?doi=10.1.1.148.9757rep=rep1type=pdf - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 2:02 AM, Noah Kantrowitz n...@coderanger.net wrote: On Jul 29, 2013, at 10:41 PM, Antoine Pitrou solip...@pitrou.net wrote: Paul Moore p.f.moore at gmail.com writes: Personally, none of the changes have detrimentally affected me, so my opinion is largely theoretical. But even I am getting a little frustrated by the constant claims that what we have now is insecure and broken, and must be fixed ASAP. FWIW, +1. You may be paranoid, but not everyone has to be (or suffer the consequences of it). Security issues should be fixed without breaking things in a hassle (which is the policy we followed e.g. for the ssl module, or hash randomization). You missed a key word … when possible. If there is a problem we will fix it, when we can do that in a way that minimizes breakages we will do that. Its all just about cost-benefit, and when you are talking about executing code downloaded from the internet it becomes quite easy to see benefits outweighing costs even with pretty major UX changes. Not something we do lightly, but status quo does not win here, sorry. Basically said it better than I could :) - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
Noah Kantrowitz noah at coderanger.net writes: The whole python.org infrastructure is built on an OS kernel written by someone who thinks security issues are normal bugs. AFAIK there is no plan to switch to OpenBSD. This is news to me, we specifically run Ubuntu LTS because Canonical's security response team has a proven track record of handling issues. If you mean that Linus doesn't handle security issues well, then it is fortunate indeed that we don't actually use his software. Did you already forget what the discussion is about? Security/bugfix Ubuntu LTS updates don't break compatibility for the sake of hardening things, which is the whole point. (As for the idea that using Canonical's kernel amounts to not using Linus' software, that's a rather unorthodox notion of authorship. It's very likely Canonical doesn't change more than 1% LOC in the kernel, so you're still bound to Linus' decisions for at least 99% of the code - and even probably for the remaining 1%, since Canonical's version won't be massively divergent.) Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 29, 2013, at 11:19 PM, Antoine Pitrou solip...@pitrou.net wrote: Noah Kantrowitz noah at coderanger.net writes: The whole python.org infrastructure is built on an OS kernel written by someone who thinks security issues are normal bugs. AFAIK there is no plan to switch to OpenBSD. This is news to me, we specifically run Ubuntu LTS because Canonical's security response team has a proven track record of handling issues. If you mean that Linus doesn't handle security issues well, then it is fortunate indeed that we don't actually use his software. Did you already forget what the discussion is about? Security/bugfix Ubuntu LTS updates don't break compatibility for the sake of hardening things, which is the whole point. Again, speaking as the guy that has to clean up the mess when they do break compat, I promise you they do. Same deal, they only break compat when keeping compat would present a threat to users, which is quite often the case with security bugs. They are fortunately a bit further ahead of us on the long tail of finding problems, so this is far less frequent than it was in years past. We will get there too, but like I said, status quo is not a defense here, just strap in and hang on. --Noah signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
Donald Stufft donald at stufft.io writes: I *will* advocate and push for breaking things where security is concerned because regardless of if you care or not, a lot of people *do* care and the nature of the beast is that you're only as strong as the weakest link. That's nice, but you're not alone here, so whatever you want to push for needn't always happen. There's actually pretty strong evidence that shows the process of classifying bugs as security bugs is a harmful process and that all updates should be treated the same because it's often times not immediately obvious what the security implications are, even to security experts[1]. Doesn't it contradict your own stance on the subject? (This shows a fundamental misunderstanding of how security issues present themselves. Of course things just work for people because security issues are not like regular bugs - which is a flawed argument btw. Many bugs have random or rare occurrences - not just security issues) I'm sure your dig at the OS is supposed to be some sort of masterstroke about how we're not being as secure as possible anyways however I would contest that OpenBSD is actually more secure. WTF are you talking about? No it's not. I'm simply pointing out that, for some strange reason, you decided to trust an OS whose author has very different views on how to fix security issues than you have. Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 2:19 AM, Antoine Pitrou solip...@pitrou.net wrote: Noah Kantrowitz noah at coderanger.net writes: The whole python.org infrastructure is built on an OS kernel written by someone who thinks security issues are normal bugs. AFAIK there is no plan to switch to OpenBSD. This is news to me, we specifically run Ubuntu LTS because Canonical's security response team has a proven track record of handling issues. If you mean that Linus doesn't handle security issues well, then it is fortunate indeed that we don't actually use his software. Did you already forget what the discussion is about? Security/bugfix Ubuntu LTS updates don't break compatibility for the sake of hardening things, which is the whole point. Well for one PyPI doesn't have releases so there is no LTS or not LTS, it's just what's being served so there's no simple place to break backwards compatibility. As far as forgetting what's being discussed here then it sounds like you've apparently missed the fact I already conceded the change to MD5 and further more this thread was explicitly split off from the MD5 request because, as far as I can tell, Holger wanted to discuss the broader topic of compatibility in general and not just specific to this particular issue. (As for the idea that using Canonical's kernel amounts to not using Linus' software, that's a rather unorthodox notion of authorship. It's very likely Canonical doesn't change more than 1% LOC in the kernel, so you're still bound to Linus' decisions for at least 99% of the code - and even probably for the remaining 1%, since Canonical's version won't be massively divergent.) Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
Donald Stufft donald at stufft.io writes: I have zero qualms about releasing a full disclosure along with working exploits into the wild for a security vulnerability that people block me on. If I'm unable to rectify the problem I will make sure that everyone *knows* about the problem. I don't know what I'm supposed to infer from such a statement, except that I probably don't want to trust you. You might think that publish[ing] working exploits into the wild is some kind of heroic, altruistic act, but I think few people would agree. Even a random occurrence will break for some percentage of people using the software some percentage of the time. If it didn't then it's unlikely anyone would notice it. Security vulnerabilities typically won't break until someone actively tries to break them. You're mistaken. Bugs can sometimes be fixed preemptively, even before they're noticed in the wild (by means of perusing the code and noticing an issue, for example). Which also includes, of course, security issues (which often get fixed before they ever get exploited). Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 12:01 AM, Antoine Pitrou solip...@pitrou.net wrote: Donald Stufft donald at stufft.io writes: I have zero qualms about releasing a full disclosure along with working exploits into the wild for a security vulnerability that people block me on. If I'm unable to rectify the problem I will make sure that everyone *knows* about the problem. I don't know what I'm supposed to infer from such a statement, except that I probably don't want to trust you. You might think that publish[ing] working exploits into the wild is some kind of heroic, altruistic act, but I think few people would agree. No, this is the standard for security researchers. If the vendor ignores the reported exploit for long enough, they go public and try to make sure users understand the risks and how to mitigate them in the time it takes the vendor to fix it. --Noah signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On 30 July 2013 17:33, Paul Moore p.f.mo...@gmail.com wrote: And in case it's not obvious, I think this is important. We need to have this sort of debate, certainly, but it won't happen without someone advocating (and implementing!) the changes, so many thanks for being that person and putting up with the flak. Part of the idea of having myself and Richard in the approval chain for packaging ecosystem and PyPI changes is to encourage people to get angry at *us* for saying Yes, let's do that when things break, rather than getting mad at the people actually volunteering to do the work needed to improve the Python community's software distribution infrastructure. That's the plan, anyway, even if it isn't always all that effective in practice :( Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 4:10 AM, Nick Coghlan ncogh...@gmail.com wrote: On 30 July 2013 17:33, Paul Moore p.f.mo...@gmail.com wrote: And in case it's not obvious, I think this is important. We need to have this sort of debate, certainly, but it won't happen without someone advocating (and implementing!) the changes, so many thanks for being that person and putting up with the flak. Part of the idea of having myself and Richard in the approval chain for packaging ecosystem and PyPI changes is to encourage people to get angry at *us* for saying Yes, let's do that when things break, rather than getting mad at the people actually volunteering to do the work needed to improve the Python community's software distribution infrastructure. That's the plan, anyway, even if it isn't always all that effective in practice :( Heh, I'm pretty good at getting yelled at :) - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Ubuntu says Virtualenv, Pip and Setuptools untrusted
On 27.07.2013, at 10:12, Erik Bernoth erik.bern...@gmail.com wrote: Hi everybody, did you know that Ubuntu 13.10 (or maybe Debian?) declares those packages as untrusted and asks you twice, if you really want to install them? Is there anything that can be done about that? Hi Erik, Many thanks for the report, would you be so kind and provide some details to the pypa-dev mailing list, which is more appropriate for dealing with pip and virtualenv development? https://groups.google.com/group/pypa-dev Jannis signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
Donald Stufft donald at stufft.io writes: On Jul 30, 2013, at 3:01 AM, Antoine Pitrou solipsis at pitrou.net wrote: I don't know what I'm supposed to infer from such a statement, except that Iprobably don't want to trust you. You might think that publish[ing] workingexploits into the wild is some kind of heroic, altruistic act, but I think fewpeople would agree. Full Disclosure is a common practice amongst security professionals whenthe upstream project is unwilling to rectify the problem. So yes I do think the practice of Full Disclosure is an altruistic act and often times the only thing that gets people who don't care to pull their head out of the sand and actually care. You don't happen to be a random security professional, you are actually part of that upstream project and you have access to non-public (possibly confidential) data about its infrastructure, which gives you responsibilities towards your peers. I don't think I would be the only one to be angry if an infrastructure member starting publishing working exploits for unfixed vulnerabilities in the pdo infrastructure. It is a completely irresponsible way to act when you are part of a project or community. Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Mon, Jul 29, 2013 at 8:17 PM, Donald Stufft don...@stufft.io wrote: - - Distribute / setuptools merge, e.g. cratering folks who use a distro-managed 'python-distribute' package. This is the biggest issue. I wasn't involved and it could have been handled better sure. I'm not convinced. The use-cases and ways these things can be installed in conjunction with things like system packages, virtualenv and buildout in various configurations and various python versions are mindboggling. Some of them were not initially tested, probably mostly because nobody realized the finer details of what would happen in these sometimes fairly obscure cases. The problems have, afaik, now been fixed, and this was done reasonably quickly IMO. OK, of course it *could* have been handled better, but I don't think it was handled badly. The current situation is a huge mess. Untangling it *will* be tricky. //Lennart ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 5:57 AM, Antoine Pitrou solip...@pitrou.net wrote: Donald Stufft donald at stufft.io writes: On Jul 30, 2013, at 3:01 AM, Antoine Pitrou solipsis at pitrou.net wrote: I don't know what I'm supposed to infer from such a statement, except that Iprobably don't want to trust you. You might think that publish[ing] workingexploits into the wild is some kind of heroic, altruistic act, but I think fewpeople would agree. Full Disclosure is a common practice amongst security professionals whenthe upstream project is unwilling to rectify the problem. So yes I do think the practice of Full Disclosure is an altruistic act and often times the only thing that gets people who don't care to pull their head out of the sand and actually care. You don't happen to be a random security professional, you are actually part of that upstream project and you have access to non-public (possibly confidential) data about its infrastructure, which gives you responsibilities towards your peers. I don't think I would be the only one to be angry if an infrastructure member starting publishing working exploits for unfixed vulnerabilities in the pdo infrastructure. It is a completely irresponsible way to act when you are part of a project or community. I don't really care if you'd be angry. The point of Full Disclosure (and it's cousin Responsible Disclosure) is to A) Inform everyone involved that they are taking a huge risk by using a particular thing and B) Provide incentive to people to fix their shit. If others are preventing fixes from landing then both reasons still apply wether the reporter is involved with the project or not. If I can find a vulnerability then so can someone else. Someone who won't inform people and will use it to maliciously attack people. If you feel I'd be overstepping my bounds then complain to my superiors, Richard/Nick on the packaging side of things and Noah on the Infrastructure team side of things. I'll continue to do what I feel best serves the community for as long as I have the ability to do so. Which I believe is work on improving these issues, fight and advocate for the important ones, accept defeat on less important ones, and, if necessary, issue a Full Disclosure. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
Donald Stufft donald at stufft.io writes: You don't happen to be a random security professional, you are actually part of that upstream project and you have access to non-public (possibly confidential) data about its infrastructure, which gives you responsibilities towards your peers. I don't think I would be the only one to be angry if an infrastructure member starting publishing working exploits for unfixed vulnerabilities in the pdo infrastructure. It is a completely irresponsible way to act when you are part of a project or community. I don't really care if you'd be angry. Great to hear. This mindset is typical of many security specialists: you're ready to tell everyone to go f*** themselves (I don't know how to voice this differently) if you think you have a higher mission to denounce some vulnerability. The point of Full Disclosure (and it's cousin Responsible Disclosure) is to A) Inform everyone involved that they are taking a huge risk by using a particular thing and B) Provide incentive to people to fix their shit. This does not necessarily involve publishing working exploits. By giving out code that can immediately attack and bring down the pdo infrastructure, you would be doing something else than merely informing the public. (neither Bruce Schneier nor Wikipedia states that Full Disclosure implies publishing working exploits, btw. I suppose it means there is at the minimum some contention, rather than consensus, over the issue.) If I can find a vulnerability then so can someone else. You may (and probably do) have domain knowledge and inside knowledge that others don't. If you feel I'd be overstepping my bounds then complain to my superiors, Richard/Nick on the packaging side of things and Noah on the Infrastructure team side of things. Superiors? Are you making things up, or do you have an org chart to back that up? :-) (regardless, I would be surprised if any of those ordered *you* to publish an exploit, rather than take the responsibility of doing it themselves - or, rather, not doing it at all) Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Tue, Jul 30, 2013 at 8:43 AM, Donald Stufft don...@stufft.io wrote: I have zero qualms about releasing a full disclosure along with working exploits into the wild for a security vulnerability that people block me on. This is a moot point, as nobody is going to block anyone. The discussion is silly. //Lennart ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 7:40 AM, Antoine Pitrou solip...@pitrou.net wrote: Donald Stufft donald at stufft.io writes: You don't happen to be a random security professional, you are actually part of that upstream project and you have access to non-public (possibly confidential) data about its infrastructure, which gives you responsibilities towards your peers. I don't think I would be the only one to be angry if an infrastructure member starting publishing working exploits for unfixed vulnerabilities in the pdo infrastructure. It is a completely irresponsible way to act when you are part of a project or community. I don't really care if you'd be angry. Great to hear. This mindset is typical of many security specialists: you're ready to tell everyone to go f*** themselves (I don't know how to voice this differently) if you think you have a higher mission to denounce some vulnerability. Keeping an issue secret doesn't make people more secure, it only prevents them from making an informed decision about the things they use. The point of Full Disclosure (and it's cousin Responsible Disclosure) is to A) Inform everyone involved that they are taking a huge risk by using a particular thing and B) Provide incentive to people to fix their shit. This does not necessarily involve publishing working exploits. By giving out code that can immediately attack and bring down the pdo infrastructure, you would be doing something else than merely informing the public. (neither Bruce Schneier nor Wikipedia states that Full Disclosure implies publishing working exploits, btw. I suppose it means there is at the minimum some contention, rather than consensus, over the issue.) Partial disclosure is typically publishing enough information to allow people to make an informed choice but (hopefully) not enough information to allow others to attack it. Full Disclosure implies laying out the full details of the vulnerability. It doesn't necessarily mean wrapping it up in ready to run code but they almost always provide enough information so that anyone with a cursory understanding of programming (or the area it affects depending on how hard it is to replicate) can implement the attack and reproduce it. The problem with Partial Disclosure is that often times vendors/upstream/whatever will simply call the problem theoretical and still attempt to not fix things. If I can find a vulnerability then so can someone else. You may (and probably do) have domain knowledge and inside knowledge that others don't. There's not really any inside knowledge. Everything is OSS. Domain knowledge? Sure, but I really hope we aren't relying on people not knowing enough about how the tooling works to exploit it. If you feel I'd be overstepping my bounds then complain to my superiors, Richard/Nick on the packaging side of things and Noah on the Infrastructure team side of things. Superiors? Are you making things up, or do you have an org chart to back that up? :-) (regardless, I would be surprised if any of those ordered *you* to publish an exploit, rather than take the responsibility of doing it themselves - or, rather, not doing it at all) Nick is the BDFL delegate for packaging tooling and Richard is the same for PyPI and I generally consider my involvement as a PyPI admin to be under him. Noah is in charge of the Infra team of which I am a member. Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 7:49 AM, Lennart Regebro rege...@gmail.com wrote: On Tue, Jul 30, 2013 at 8:43 AM, Donald Stufft don...@stufft.io wrote: I have zero qualms about releasing a full disclosure along with working exploits into the wild for a security vulnerability that people block me on. This is a moot point, as nobody is going to block anyone. The discussion is silly. //Lennart *Shrug* If someone says people who don't care shouldn't have to suffer the consequences i assume that means they are advocating for no breakages in API (else the hypothetical person would be suffering). If you can't break fundamentally insecure things then that's a blockade on fixing the system. If that's not what the comment was proposing then I have no idea what it means. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On 30 Jul 2013 21:41, Antoine Pitrou solip...@pitrou.net wrote: Donald Stufft donald at stufft.io writes: You don't happen to be a random security professional, you are actually part of that upstream project and you have access to non-public (possibly confidential) data about its infrastructure, which gives you responsibilities towards your peers. I don't think I would be the only one to be angry if an infrastructure member starting publishing working exploits for unfixed vulnerabilities in the pdo infrastructure. It is a completely irresponsible way to act when you are part of a project or community. I don't really care if you'd be angry. Great to hear. This mindset is typical of many security specialists: you're ready to tell everyone to go f*** themselves (I don't know how to voice this differently) if you think you have a higher mission to denounce some vulnerability. The point of Full Disclosure (and it's cousin Responsible Disclosure) is to A) Inform everyone involved that they are taking a huge risk by using a particular thing and B) Provide incentive to people to fix their shit. This does not necessarily involve publishing working exploits. By giving out code that can immediately attack and bring down the pdo infrastructure, you would be doing something else than merely informing the public. (neither Bruce Schneier nor Wikipedia states that Full Disclosure implies publishing working exploits, btw. I suppose it means there is at the minimum some contention, rather than consensus, over the issue.) If I can find a vulnerability then so can someone else. You may (and probably do) have domain knowledge and inside knowledge that others don't. If you feel I'd be overstepping my bounds then complain to my superiors, Richard/Nick on the packaging side of things and Noah on the Infrastructure team side of things. Superiors? Are you making things up, or do you have an org chart to back that up? :-) Effectively he does, yes. Richard is responsible for approving PyPI API changes (including PyPI specific PEPs), I'm BDFL delegate for other packaging PEPs and Noah has final say over the operation of the python.orginfrastructure. One or more of us are the ones that need to say yes on potentially controversial changes, so the responsibility for any mistakes ultimately lies with us, rather than Donald (and I'm greatly appreciative of the huge amount of work he is putting into improving the PyPI security story). (regardless, I would be surprised if any of those ordered *you* to publish an exploit, rather than take the responsibility of doing it themselves - or, rather, not doing it at all) If Donald informed us of a vulnerability and we refused to allow him (or anyone else) to take the necessary steps to close it, then he would be *completely* justified in publishing full details of the vulnerability, up to and including working exploit code. It won't come to that though, because we're taking this seriously and closing security holes as quickly as is feasible while still ensuring a reasonable level of backwards compatibility :) Cheers, Nick. Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 8:06 AM, Nick Coghlan ncogh...@gmail.com wrote: If Donald informed us of a vulnerability and we refused to allow him (or anyone else) to take the necessary steps to close it, then he would be *completely* justified in publishing full details of the vulnerability, up to and including working exploit code. It won't come to that though, because we're taking this seriously and closing security holes as quickly as is feasible while still ensuring a reasonable level of backwards compatibility :) This basically. Maybe I'm not being clear because I have a headache and I'm reading too much into things because I'm sensitive to being shutdown on efforts to fix these things*. I don't expect with Nick, Richard, and Noah to ever need to do a Full Disclosure. I was only trying to be clear about what I consider my escalation path to be if a current, or near future vulnerability is forced to remain open. * I started trying to push for this ~2 years ago and got repeatedly shut down, for one reason or another. Which lead to to create Crate.io. It's only been relatively recently that I've been given permission to actually fix things. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Tue, Jul 30, 2013 at 4:14 AM, Donald Stufft don...@stufft.io wrote: Heh, I'm pretty good at getting yelled at :) Nick is also pretty good at making people feel like he both knows and *cares* about their breakage, and isn't just dismissing their concerns as trivial or unimportant. Breakage isn't trivial or unimportant to the person who's yelling, so this is an important community-maintenance skill. It builds trust, and reduces the total amount of yelling. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 1:13 PM, PJ Eby p...@telecommunity.com wrote: On Tue, Jul 30, 2013 at 4:14 AM, Donald Stufft don...@stufft.io wrote: Heh, I'm pretty good at getting yelled at :) Nick is also pretty good at making people feel like he both knows and *cares* about their breakage, and isn't just dismissing their concerns as trivial or unimportant. Breakage isn't trivial or unimportant to the person who's yelling, so this is an important community-maintenance skill. It builds trust, and reduces the total amount of yelling. *shrug*, If I didn't care I would have made this change as soon as Nick said it was ok. Instead I declared I was going to and waited to make sure nobody else had any concerns. And once Holger said he did I said ok I won't do it. Maybe my mannerisms give the impression I don't but that's actually pretty far from the truth. For this particular change I originally created the pip commit that allowed it, and then again I created the setuptools commit, backporting hashlib into setuptools to support Python 2.4. I put a decent amount of effort into trying to make sure that nothing broke but in the end there were still concerns :) - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Tue, Jul 30, 2013 at 2:04 PM, Donald Stufft don...@stufft.io wrote: On Jul 30, 2013, at 1:13 PM, PJ Eby p...@telecommunity.com wrote: On Tue, Jul 30, 2013 at 4:14 AM, Donald Stufft don...@stufft.io wrote: Heh, I'm pretty good at getting yelled at :) Nick is also pretty good at making people feel like he both knows and *cares* about their breakage, and isn't just dismissing their concerns as trivial or unimportant. Breakage isn't trivial or unimportant to the person who's yelling, so this is an important community-maintenance skill. It builds trust, and reduces the total amount of yelling. *shrug*, If I didn't care I would have made this change as soon as Nick said it was ok. Instead I declared I was going to and waited to make sure nobody else had any concerns. And once Holger said he did I said ok I won't do it. Maybe my mannerisms give the impression I don't but that's actually pretty far from the truth. I did say feel like. ;-) Nick usually gives more of an impression that he's thought about concerns raised before rejecting them; your responses often sound like, Who cares about that? Asking for suggestions, for example, would be good. Nick also rarely seems irritated by people's concerns or problems, whereas you sometimes seem in a big hurry to fix something today or this week that's been broken for years, without giving folks a while to get used to the idea. Often your proposals seem less like proposals than, I've decided to do this, so deal with it. I'm not saying all this because I want to complain or yell at you; I'm saying it because I think you do care enough to know how you're coming across, at least to me. Our discussions have gotten heated in the past because my impression of your reaction to the concerns I raise often seems like, I don't care about supporting [group of people affected], so neither should you. Perhaps the issue is just one of confusion. When I raise an issue about, say, Python 2.3 users (who are still downloading setuptools 0.6 releases, and presumably also using them), it's not because I expect *you* to change your plans to support them, but because I need to know how *I* can, if the issue arises. So I don't actually expect you to care about Python 2.3 users (again, as an example), but I do expect you to care about *me* supporting them. In the most recent situation, you did in fact point me to your awesome hashlib port, so I do know you *do* care to at least that extent. But the rhetoric that you sent both before and after the helpful bit seemed on the inflammatory side, as though I were crazy to be thinking of Python 2.3. Whether or not this is true ;-) -- it's not especially *helpful* to the discussion. If I may offer a suggestion, asking questions in response to objections is generally more useful than immediately arguing the relevance of the objection. First, it tells the objector that you're interested in what they have to say, and second, it may well help the objector understand that there isn't actually any real problem, and gives them an easier path to backing down and/or compromising, whereas a frontal assault tends to focus people on responding to you instead of reconsidering their objection. On the hashlib issue, for example, it actually occurred to me later that it's completely a non-issue because the actual hash scenario I was most concerned about *can't actually happen*. (MD5 hashes in code or dependency_links, used e.g. by setuptools itself to secure its own downloads. Changing PyPI won't affect these, duh.) It might've occurred to me sooner, though, if you'd actually asked what scenario I was worried about, instead of arguing about the relevance. This isn't to say that you're responsible for what I do or don't figure out; my point is simply that asking questions and inviting suggestions in response to people's objections will generally get you more thoughtful responses and more trust, and resolve issues sooner, with less arguing. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 4:01 PM, PJ Eby p...@telecommunity.com wrote: On Tue, Jul 30, 2013 at 2:04 PM, Donald Stufft don...@stufft.io wrote: On Jul 30, 2013, at 1:13 PM, PJ Eby p...@telecommunity.com wrote: On Tue, Jul 30, 2013 at 4:14 AM, Donald Stufft don...@stufft.io wrote: Heh, I'm pretty good at getting yelled at :) Nick is also pretty good at making people feel like he both knows and *cares* about their breakage, and isn't just dismissing their concerns as trivial or unimportant. Breakage isn't trivial or unimportant to the person who's yelling, so this is an important community-maintenance skill. It builds trust, and reduces the total amount of yelling. *shrug*, If I didn't care I would have made this change as soon as Nick said it was ok. Instead I declared I was going to and waited to make sure nobody else had any concerns. And once Holger said he did I said ok I won't do it. Maybe my mannerisms give the impression I don't but that's actually pretty far from the truth. I did say feel like. ;-) Nick usually gives more of an impression that he's thought about concerns raised before rejecting them; your responses often sound like, Who cares about that? Asking for suggestions, for example, would be good. Nick also rarely seems irritated by people's concerns or problems, whereas you sometimes seem in a big hurry to fix something today or this week that's been broken for years, without giving folks a while to get used to the idea. Often your proposals seem less like proposals than, I've decided to do this, so deal with it. I'm not saying all this because I want to complain or yell at you; I'm saying it because I think you do care enough to know how you're coming across, at least to me. Our discussions have gotten heated in the past because my impression of your reaction to the concerns I raise often seems like, I don't care about supporting [group of people affected], so neither should you. Perhaps the issue is just one of confusion. When I raise an issue about, say, Python 2.3 users (who are still downloading setuptools 0.6 releases, and presumably also using them), it's not because I expect *you* to change your plans to support them, but because I need to know how *I* can, if the issue arises. So I don't actually expect you to care about Python 2.3 users (again, as an example), but I do expect you to care about *me* supporting them. In the most recent situation, you did in fact point me to your awesome hashlib port, so I do know you *do* care to at least that extent. But the rhetoric that you sent both before and after the helpful bit seemed on the inflammatory side, as though I were crazy to be thinking of Python 2.3. Whether or not this is true ;-) -- it's not especially *helpful* to the discussion. If I may offer a suggestion, asking questions in response to objections is generally more useful than immediately arguing the relevance of the objection. First, it tells the objector that you're interested in what they have to say, and second, it may well help the objector understand that there isn't actually any real problem, and gives them an easier path to backing down and/or compromising, whereas a frontal assault tends to focus people on responding to you instead of reconsidering their objection. On the hashlib issue, for example, it actually occurred to me later that it's completely a non-issue because the actual hash scenario I was most concerned about *can't actually happen*. (MD5 hashes in code or dependency_links, used e.g. by setuptools itself to secure its own downloads. Changing PyPI won't affect these, duh.) It might've occurred to me sooner, though, if you'd actually asked what scenario I was worried about, instead of arguing about the relevance. This isn't to say that you're responsible for what I do or don't figure out; my point is simply that asking questions and inviting suggestions in response to people's objections will generally get you more thoughtful responses and more trust, and resolve issues sooner, with less arguing. Hrm. So I hear what you're saying and part of the problem is likely due to the history of where I tried to get a change through and then felt like all I was getting was stop energy and people wanting to keep the status quo which ultimately ended up preventing changes has lead me to view distutils-sig in more of an adversarial light then is probably appropriate for the distutils-sig of 2013 (versus the distutils-sig of 2011/2012). This is probably reflected in my tone and likely has others, such as yourself, respond similarly, pushing us further down that path. My thought process has become Ok here's something that needs to happen, now how do I get distutils-sig not to prevent it from happening. This was again reflected in the Python 2.3 discussion because my immediate reaction and impression was that you were attempting to block the move from MD5 due to
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On 30 July 2013 21:58, Donald Stufft don...@stufft.io wrote: As far as how to fix it I don't have a particularly magic answer. I will try to be more mindful of my tone and that distutils-sig is likely not my adversary anymore as well as try to ask questions instead of arguing the relevance immediately. Thank you - both for the thoughtful response and the explanation of what is going on in your thinking. I certainly tend to think about possible issues rather than benefits, maybe more than I should as I don't personally have any particular problems with a rapid pace of change (except in some specific areas where I'm in so much of a minority that I don't expect my concerns to be a big driver in the grand scheme of things). I think I'm doing this to make sure people haven't missed potential issues I'm aware of, but I can easily imagine that this comes across as negative stop energy. I'll try to stick to issues where I have genuine concerns, and not theoretical ones in future. And yes, it does feel like distutils-sig of 2013 is a much nicer place than it used to be. Thanks to everyone for working to keep that the case. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
Donald Stufft donald at stufft.io writes: to PyPI. The snark in my statements primarily came from that feeling of someone was trying to shut down an enhancement. To be fair, the tone you've taken (which can rub people up the wrong way) hasn't just been over long-standing security issues. I've also felt uncomfortable with some of your responses relating to the PEP 426 discussion around the JSON schema for requirements, where there is not the same level of urgency, nor valid reason to believe that you're being thwarted somehow. If someone's approach comes off as unduly dismissive (even if not meant that way), it makes it harder to engage in constructive discussion. I recognise that it's hard communicating with people remotely, many of whom one might never have met. It's easy to miss nuance and misconstrue turns of phrase. It's best to tread gingerly, else too much time is spent smoothing ruffled feathers at the expense of getting real work done. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 5:17 PM, Paul Moore p.f.mo...@gmail.com wrote: On 30 July 2013 21:58, Donald Stufft don...@stufft.io wrote: As far as how to fix it I don't have a particularly magic answer. I will try to be more mindful of my tone and that distutils-sig is likely not my adversary anymore as well as try to ask questions instead of arguing the relevance immediately. Thank you - both for the thoughtful response and the explanation of what is going on in your thinking. I certainly tend to think about possible issues rather than benefits, maybe more than I should as I don't personally have any particular problems with a rapid pace of change (except in some specific areas where I'm in so much of a minority that I don't expect my concerns to be a big driver in the grand scheme of things). I think I'm doing this to make sure people haven't missed potential issues I'm aware of, but I can easily imagine that this comes across as negative stop energy. I'll try to stick to issues where I have genuine concerns, and not theoretical ones in future. I don't actually mind even theoretical problems nor do I want people to feel like they need to coddle me because of my history with distutils-sig. That history and how It affects me is *my* problem. I think as long as we, including myself, approach theoretical problems as Let's figure out if this theoretical problem is actually a problem, and if it is do we care about it and not here's a bunch of possible problems, we can't do this then there will be no issues. It's true that theoretical problems can make me feel more like someones applying stop energy than concrete problems, but that's not a problem of the person bringing up that problem and more just it triggering old feelings from a time where I couldn't even get a SSL certificate trusted by most major browsers by default deployed ;). Not allowing those feelings to poison current efforts is on me. And yes, it does feel like distutils-sig of 2013 is a much nicer place than it used to be. Thanks to everyone for working to keep that the case. Paul - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] PEP 426 installation hooks and conventions
I'm looking at PEP 426 specifications for installation hooks and wondering whether we need to tighten up the specification a little. My concern stems from the fact that hook code needs to be installed along with other code - at least, the code for preuninstall hooks needs to be in the installed code. As it's only hook code, the naming of modules which contain it may not be done as carefully as the substantive modules and packages in a distribution. However, if multiple distributions were to put their hooks in a hooks.py module, which might seem the simplest thing to do, that could lead to problems: if these hook modules get written to site- packages, the hooks.py from a later installed distribution would override that from an earlier installed distribution. Possible solutions: 1. Constrain the specification so that each distribution must put hook code in a subpackage of one of their main packages. This will affect any distribution that consists only of modules and which has no packages, as the authors will have to create a package just for the hook code. 2. Constrain the specification so that hook code is segregated to a single module, perhaps specified by a hook_module key in the install_hooks dict, which is written to the .dist-info directory. An installer could add the .dist-info to sys.path before resolving/importing. The code in the hooks module could invoke any code it needed from the main body of code in the distribution. Is my concern a valid one? If so, can I please have comments/suggestions about how to address it? Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Jul 30, 2013, at 6:19 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Donald Stufft donald at stufft.io writes: to PyPI. The snark in my statements primarily came from that feeling of someone was trying to shut down an enhancement. To be fair, the tone you've taken (which can rub people up the wrong way) hasn't just been over long-standing security issues. I've also felt uncomfortable with some of your responses relating to the PEP 426 discussion around the JSON schema for requirements, where there is not the same level of urgency, nor valid reason to believe that you're being thwarted somehow. I never meant to claim it was simply over security issues. I'm certainly more energetic about advocating for security issues and they frame the backdrop for a lot of my feelings with distutils-sig as an adversary rather than an ally . The simple fact is that every disagreement, or even simple suggestion, is framed against that feeling leading towards the Me vs Them tone. If someone's approach comes off as unduly dismissive (even if not meant that way), it makes it harder to engage in constructive discussion. I recognise that it's hard communicating with people remotely, many of whom one might never have met. It's easy to miss nuance and misconstrue turns of phrase. It's best to tread gingerly, else too much time is spent smoothing ruffled feathers at the expense of getting real work done. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426 installation hooks and conventions
On 31 Jul 2013 08:49, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: I'm looking at PEP 426 specifications for installation hooks and wondering whether we need to tighten up the specification a little. My concern stems from the fact that hook code needs to be installed along with other code - at least, the code for preuninstall hooks needs to be in the installed code. As it's only hook code, the naming of modules which contain it may not be done as carefully as the substantive modules and packages in a distribution. It's installed along with everything else, why would anyone assume they can ignore naming conflicts? If they do, then it's either a bug or a mutual incompatibility between affected distributions (just like other accidental name conflicts). However, if multiple distributions were to put their hooks in a hooks.py module, which might seem the simplest thing to do, that could lead to problems: if these hook modules get written to site- packages, the hooks.py from a later installed distribution would override that from an earlier installed distribution. Possible solutions: 1. Constrain the specification so that each distribution must put hook code in a subpackage of one of their main packages. This will affect any distribution that consists only of modules and which has no packages, as the authors will have to create a package just for the hook code. Why? If it's a single module that needs install hooks for some reason, the hook implementations can just go in there along with everything else (assuming they're not invoking a generic hook from a dependency). The names can be prefixed with an underscore to indicate they're not part of the regular API. 2. Constrain the specification so that hook code is segregated to a single module, perhaps specified by a hook_module key in the install_hooks dict, which is written to the .dist-info directory. An installer could add the .dist-info to sys.path before resolving/importing. The code in the hooks module could invoke any code it needed from the main body of code in the distribution. Is my concern a valid one? If so, can I please have comments/suggestions about how to address it? Hook code is just normal code in the installed distribution (or a dependency). That's why there are deliberately no preinstall or postuninstall hooks - I don't want to come up with a new scheme for running code that hasn't been installed. Cheers, Nick. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Warehouse Migration Plan
So, in the spirit of not treating distutils-sig like an adversary, here's the main thing I've been working on lately with regards to PyPI. None of this is set in stone but this is the general gist of the plan for moving things to be developed in a modern framework, as well as cleaning up the code and getting repeatable deployments. Warehouse Migration Plan Warehouse is currently primarily besides modeling for user accounts. It will be deployed alongside pypi-legacy at next.pypi.python.org in the near future. Initially it will have zero user facing value. As time goes on the database tables will be migrated from being owned by pypi-legacy to being owned by Warehouse. This primarily means that the schema definition and migration of those tables will be controlled by Warehouse. As tables are migrated to Warehouse ownership the PyPI code will be updated to reflect any changes in schema (without modification to what end users see). Once all tables that are going to be kept have been migrated, we will have a shared database that is accessible from both pypi-legacy and Warehouse. From this point Warehouse will begin evolving legacy views such as the simple and other pieces of API. The UX itself will continue to be ignored and focus will be on getting feature parity for automated tooling. Changes in behavior on these legacy views should be minimal and discussed on distutils-sig. Once the legacy views are finished people will be encouraged to test their real world workloads against those reimplemented legacy APIs. As changes in behaviors, missing functionality, or bugs are found they will be rectified or declared unsupported. During this time work on the UI of Warehouse will begin focusing on maintaing feature parity but with no promises of no changes to the url structure or UX. Once Warehouse gains feature parity with PyPI and has gotten enough testing against it's APIs then pypi-legacy will be retired and Warehouse will move from next.pypi.python.org to pypi.python.org. From there it will evolve on it's own without needing to keep pypi-legacy in sync. Specification Acceptance Testing I do not want a packaging index server to be specified by implementation, so as the legacy API is ported over to Warehouse a specification will be drafted. This spec will represent the promise that PyPI makes about the API it presents to be consumed by machines. During the migration any behavior not codified inside of the spec is considered implementation defined behavior and backwards compatibility for that behavior will not be promised. In addition to a defined specification A repository of acceptance tests will be developed. These tests will be part of the test framework for any future changes to Warehouse but will be maintained separately alongside the specification. They will also allow any alternative implementation (such as DevPI) to test themselves against the spec. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
