Debian, OpenSSL, and a lack of cooperation

Debian, OpenSSL, and a lack of cooperation

Posted May 18, 2008 2:39 UTC (Sun) by giraffedata (subscriber, #1954)
In reply to: Debian, OpenSSL, and a lack of cooperation by jimparis
Parent article: Debian, OpenSSL, and a lack of cooperation

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.

---

(Log in to post comments)

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.