| |||||||||||||
Debian, OpenSSL, and a lack of cooperationDebian, OpenSSL, and a lack of cooperationPosted May 16, 2008 0:55 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: Debian, OpenSSL, and a lack of cooperation by incase Parent article: Debian, OpenSSL, and a lack of cooperation But Laurie does later say that the Openssl team needs to make it easier for people to communicate things like this to it (I would think that includes publishing an email address where someone is likely to look for it that reaches people in a position to fix upstream Openssl), and that it probably isn't possibly due to lack of resources. The fundamental problem being pointed out here might be with distribution of resources. Debian apparently has the resources to maintain a private fork of Openssl, but not to maintain the trunk, whereas the trunk seems to be the more effective place to apply resources in a case like this.
(Log in to post comments)
Debian, OpenSSL, and a lack of cooperation Posted May 17, 2008 20:14 UTC (Sat) by jimparis (subscriber, #38647) [Link] > But Laurie does later say that the Openssl team needs to make it easier for > people to communicate things like this to it To communicate things like _what_? Security holes? That's not the issue here -- nobody knew it was as security hole back in 2006 when it was first discussed. It just seemed like some valgrind nonsense and the Debian developer didn't know better (which is why he publically asked for input). Personally I'm surprised with Laurie's response -- I didn't previously know that the Debian developer had discussed this on openssl-dev and gotten a "go-ahead" from an openssl developer!
Debian, OpenSSL, and a lack of cooperation Posted May 18, 2008 2:39 UTC (Sun) by giraffedata (subscriber, #1954) [Link] To communicate things like _what_? That there was a maintainability problem (unclean Valgrind report) that might be worth fixing in the base, and that Debian intended to ship to the world a variation of Openssl with that line removed. But "communicate things like this to [the Openssl team]" is my wording, and doesn't fairly represent Laurie's statement, which was about bidirectional communication. Bear in mind that Laurie claims the apparent "go-ahead" from an Openssl developer was a communication gap -- that 1) he meant go ahead and do it in a debugging run, not in production; and 2) his advice was not the official, considered advice of the Openssl team, which was never contacted. I know these conclusions are extremely weak, but they are his position nonetheless. I have on many occasions asked on a mailing list if a certain patch would be OK, been told by someone yes, and then upon submitting the patch, had it rejected. The explanation is always, "you misunderstood; I just said the general principle was OK, as far as I could see without actually looking." You get a whole different kind of review when it comes down to actually merging code.
Debian, OpenSSL, and a lack of cooperation Posted May 18, 2008 18:32 UTC (Sun) by mmarsh (subscriber, #17029) [Link] The "maintainability" problem is unlikely to be changed anytime soon, from what I gather. Since I started using OpenSSL in '01 (and likely for a number of years before that), there's always been a -DPURIFY compile option to disable the one line that remained commented out after the Debian package was fixed. The docs specifically say that the use of an uninitialized buffer is intended to increase entropy, and that you should disable it at build time if you need a purify- or valgrind-friendly version. It might be better for distros to use existing flags like these rather than diverging from the upstream release, at least when such flags are available. The hassle of a makefile mod vs. the hassle of patching the source again with each new release seems comparable, if not weighted in favor of the former.
|
|||||||||||||