Gustavo Narea writes: > Well, that's a long shot. I doubt the people/organizations affected are > all aware.
That's really not Python's responsibility. That's theirs. Caveats: Python should have a single place where security patches are announced *first*, before developer blogs and the like. Python's documentation should make it clear at the most important entry points that the appropriate place to report possible security issues is secur...@python.org, not the tracker. In particular, the tracker's top page (the one you get from http://bugs.python.org/) should make that clear. Ironically, Brian's blog entry outlines a plausible security policy, but a quick Google didn't find it elsewhere on site:python.org. Oops, a different search did find it -- under News/Security Advisories. The tracker suggestion submitted as http://psf.upfronthosting.co.za/roundup/meta/issue393. > And I doubt they are all capable of patching their system or > getting a patched Python from a trusted party. Then they shouldn't be running Python in a security context, should they? Seriously, if they want somebody else to take care of their security issues for them, they should pay for it. As in almost areas of life, security is at best worth what you pay for it. > Three weeks after this security vulnerability was *publicly* reported on > bugs.python.org, Again, that's an issue with the reporter not knowing the policy, not the policy itself, which is to report to secur...@python.org, cf. Brian's post and the Security Advisory page. The caveats above apply, though. > and two days after it was semi-officially announced, > I'm still waiting for security updates for my Ubuntu and Debian systems! Yeah, well, so much for depending on Ubuntu and Debian. There are reasons why people pay for RHEL. > I reckon if this had been handled differently (i.e., making new releases > and communicating it via the relevant channels [1]), we wouldn't have > the situation we have right now. Of course not. So what? The question is "what is the best way to reduce risks?" *It is not possible to reduce all risks simultaneously.* What you are saying is "please keep things obscure until I'm up to date." It seems to be a consensus in the security community that most security holes *are* sufficiently obscure that announcing the problem before announcing a fix is likely to increase the likelihood of black hats finding exploits and successfully executing them more than it increases the likelihood that (3rd party) white hats will find and contribute a fix. So the question is whether to rely on obscurity after the fix is devised. Now, once there is a fix, there's always hysteresis in implementation, as you note with respect to Ubuntu and Debian. If you don't announce the fix once available, you are increasing risk to conscientious, patch-capable admins dramatically compared to the case where you give them the patch. I don't see why your Ubuntu/Debian systems should take precedence over systems of those who prefer to rely on self- built-and-maintained systems. (In fact, since I generally fall into the latter category, may I suggest it should be the other way around? <wink />) > May I suggest that you adopt a policy for handling security issues like > Django's? > http://docs.djangoproject.com/en/1.3/internals/contributing/#reporting-security-issues I'm -1 on that, except to the extent that it corresponds to existing policy. Eg, This will probably mean a new release of Django, but in some cases it may simply be patches against current releases. seems to apply to the current case. I really don't think the policy Django claims is appropriate for Python for the following reasons, among others: Halt all other development as long as is needed to develop a fix, including patches against the current and two previous releases. is nonsense. Perhaps what this means is that the "long-time, highly trusted Django developers" on the security@django list *volunteer* to put other Django work aside until the security hole is patched. But certainly the "hundreds of contributors around the world" won't stop their work -- they won't know about the moratorium since they're not on the security list. In the case of Python, it's not even possible to stop commits without closing the repo, as not all committers are on the security list. Even for the security crew, in many cases of security problems, it's something simple and readily fixed like a buffer overflow or an URL traversal issue that just needs a simple filter on input before executing a risky procedure. So who does the fixing, reviewing, etc should be decided on a case-by-case basis based on the problem itself and available expertise IMO. And this Pre-notify everyone we know to be running the affected version(s) of Django. seems positively counter-productive if they're serious about "everyone". Surely the black hats are running the affected versions of Django to test their exploits! So they get to find out they're running out of time to execute while the people running affected versions remain vulnerable until the release. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
