Live data from Hacker News

Lessons from the Debian/OpenSSL Fiasco (2008)

research.swtch.com

21–26 of 26 posts

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#21
post #16

> Try not to write clever code. Try to write well-organized code. Decades ago someone wrote an empty loop to do "something" and it looped for a fixed number of times. No one knew why. But seemed that loop depended upon the frequency of the CPU. It was kind of a sleep (I forgot most of the details) that was needed for some reason. When the system was upgraded, things stated breaking. That statement should be a tattoo…

Busy loops for delays used to be common. That is why some old PCs had a "turbo mode" switch. When on, the system ran at full speed. When off, it slowed down to match timing of old games etc.

On a DOS PC, a better way to delay would be to count timer interrupts.

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#22
post #13

Every time this gets brought up, people forget that the patch had been sent to the openssl mailing list and someone said that it looked fine. But here we have all the proponents of "distributions should never do any patch (and thus leave all the security issues open)". But they live in a fantasy world where all upstream authors reply within 3 minutes, fix issues within 30 minutes and of course backport the fix.

the doubly weird thing is that OpenSSL already had a ifdef-- -DPURIFY -- that did what the packager desired.

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#23
post #13

Every time this gets brought up, people forget that the patch had been sent to the openssl mailing list and someone said that it looked fine. But here we have all the proponents of "distributions should never do any patch (and thus leave all the security issues open)". But they live in a fantasy world where all upstream authors reply within 3 minutes, fix issues within 30 minutes and of course backport the fix.

Also, after it blew up people said "why did you mail to -dev? That's where users post to and nobody has time with that, we have a special wizards list where the devs hang out".

Which says a lot. With better communication, from everyone involved, this wouldn't have happened the way it did.

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#24
post #22
post #13

Every time this gets brought up, people forget that the patch had been sent to the openssl mailing list and someone said that it looked fine. But here we have all the proponents of "distributions should never do any patch (and thus leave all the security issues open)". But they live in a fantasy world where all upstream authors reply within 3 minutes, fix issues within 30 minutes and of course backport the fix.

the doubly weird thing is that OpenSSL already had a ifdef-- -DPURIFY -- that did what the packager desired.

Did it have the same security problem?

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#25
post #10

Wonder if any of the lessons got learned? We, as an industry, are absolutely terrible at this, but hope springs eternal...

No, generally there is no respect for the complexity of libraries. There is a reason why library authors themselves are reluctant to do many or broad changes. But first the sysadmin culture (which I generally like, but not in this aspect) taught us that anyone can modify anything to make it work for him. Now the equity culture teaches us that anyone is equal and has a right to do any modifications. Correctness does n…

Your tangent into right wing politics aside, everybody absolutely has a right to modify openssl and run it modified, it's in the license. Doesn't make every instance of it a good idea, but that right exists.

Re: Lessons from the Debian/OpenSSL Fiasco (2008)

#26
post #24
post #22

Earlier quoted context omitted.

the doubly weird thing is that OpenSSL already had a ifdef-- -DPURIFY -- that did what the packager desired.

Did it have the same security problem?

Nope, it is the thing the debian developer intended, without introducing any problems-- and was at the time. It's a bit opaquely named (it's named after an earlier tool, 'purify' that protested some of the same things valgrind did) which is presumably why the debian developer was unaware of it.

I believe most distros ship with it on these days because without it you can't really use valgrind on programs that use openssl. (Suppressions don't really work because the uninitialized data taints all downstream users of openssl randomness)

Post reply on HN