On Thu, Apr 11, 2013 at 09:55:31PM -0400, Michael Gilbert wrote: > Anyway, it is a pretty small and clear patch, so I've gone ahead and > uploaded an nmu to delayed/5. Please let me know if I should delay > longer, or if you want to do the upload yourself.
Since you've pushed this out already, you can undelay it too if you like. As I said previously, I'm not seeing a compelling reason for this to delay the release, so I likewise don't see a good reason to delay things with extra theatre or to delay getting it actually tested by a few people now. I'm sure if the untested patch does break something that you'll fix it :) > If there are other issues that you're aware of that have a security > implications, please discuss that on oss-sec so that they can also be > properly studied, identified, and addressed: > http://www.openwall.com/lists/oss-security The git repo is publicly available, and the commits having similar or greater repercussions to this one are fairly self-evident. I didn't see a lot of proper analysis of this one outside the upstream discussions to date. Not even an indication that any application is vulnerable to it. I think it will be a much better use of our time to just get the release out quickly so we can push out all of the fixes and let people who want them pull backports. That's what the people who've spoken to me about using this for their own projects are already doing. Opening a new half-baked list of 'release-blockers' to cherry-pick doesn't really seem helpful for either of those goals at this stage of the freeze. If there were proven vectors for any of these things, including this one, we'd have rushed out urgent fixes last year, when they were patched. Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
