[lifthrasiir]

The counterpoint would be the Debian-specific loss of private key entropy [1] back in 2008. While this is now a very ancient bug, the obvious follow-up question would be: how does Debian prevent or mitigate such incidents today? Was there any later (non-security, of course) incident of similar nature?

[1] https://en.wikipedia.org/wiki/OpenSSL#Predictable_private_ke...

[upofadown]

Debian does a lot of patching that is not strictly required for distribution reasons. Here are the GnuPG patches for example:

* https://udd.debian.org/patches.cgi?src=gnupg2&version=2.4.7-...

There is a lot of political stuff in there related to standards. For a specific example see:

* https://sources.debian.org/src/gnupg2/2.4.7-19/debian/patche...

The upstream GnuPG project (and the standards faction they belong to) specifically opposes the use of keys without user IDs as it is a potential security issue. It is also specifically disallowed by the RFC4880 OpenPGP standard. By working through the Debian process, the proponents of such keys are bypassing the position of the upstream project and the standard.

[RetroTechie]

> There is a lot of political stuff in there related to standards.

To be fair, in Debian's case politics come with the territory. Debian is a vision of what an OS should be like. With policies, standards & guidelines aimed at that, treating the OS as a whole.

That goes well beyond "gather packages, glue together & upload".

Same goes for other distributions I suppose (some more, some less).

[guappa]

Do you have any statistics that show that Debian patches introduce more CVE worthy bugs than the software already contains? OpenSSL doesn't really have a pristine history.

Let's not forget that the patch had been posted on the OpenSSL mailing list and had received a go ahead comment before that.

Having said that, if you're asking if there's a penetration test team that reviews all the patches. No there isn't. Like there isn't any such thing on 99.999999999% of all software that exists.

[lifthrasiir]

That was the kind of answer I wanted to hear, thanks. (Of course I don't think Debian should be blamed for incidents.) Does Debian send other patches as well? For example, I didn't know that Debian also often creates a man page by its own.

[pabs3]

Debian definitely aims to contribute upstream, but that doesn't always happen, due to upstream CLAs, because most Debian packagers are volunteers, many Debian contributors are busy, many upstreams are inactive and other reasons.

[aragilar]

If you go to https://tracker.debian.org/ for any package, it lists patches that need to be sent upstream.

[lifthrasiir]

Ah, I meant more about policies and guidelines. I'm not well-versed in Debian processes so I can for example imagine that only some patches get sent to the upstream only at the maintainers' discretion. It seems that Debian at least has a policy to maintain patches separate from the upstream source though.

[bayindirh]

Debian uses Quilt system for per-package patch maintenance. While packaging a software you get the original source (i.e. orig.tar.gz), and add patches on top of it with Quilt, and build it that way.

Then you run the tests, and if they pass, you package and upload it.

This allows a patch(set) can be sent to the upstream as a package saying "we did this, and if you want to include them, this apply cleanly to version x.y.z, any feedback is welcome".

[guappa]

In theory you want all patches sent to upstream, but if they're for some specific debian reason then you can not send them.

Patches are maintained separately because debian doesn't normally repack the .tar.gz (or whatever) that the projects publish, as to not invalidate signatures and let people check that the file is in fact the same. An exception is done when the project publishes a file that contains files that cannot legally be redistributed.

[lmm]

The patch was posted on the wrong OpenSSL mailing list, and frankly that particular Debian bug was worse than anything else we've seen even from OpenSSL.

Last I knew Debian didn't do dedicated security review of patches to security-critical software, which is normal practice for other distributions.

[kragen]

It was plausibly the worst computer security bug in human history, but by the same token, it's hard to see it as indicating a systemic problem with either Debian or OpenSSL. When we're dealing with a once-in-history event like that, where it happens is pretty random. It's the problem of inference from a small sample.

[ak217]

I think it's important to learn from incidents. It's clear there were design issues on both projects' sides that allowed that bug to happen, and in fact several of them were fixed in subsequent years (though not quickly, and not until major corporate sponsors got concerned about OpenSSL's maintenance).

[kragen]

I agree, but it's not clear that there aren't worse design issues in the alternatives.

[SAI_Peregrinus]

On the other hand it exposed that OpenSSL was depending on Undefined Behavior always working predictably. Something as simple as a GCC update could have had the same effect across far more systems than just Debian, with no patch to OpenSSL itself.

[lmm]

> On the other hand it exposed that OpenSSL was depending on Undefined Behavior always working predictably. Something as simple as a GCC update could have had the same effect across far more systems than just Debian, with no patch to OpenSSL itself.

No it wasn't. It was reading (and xoring into the randomness that would become the key being generated) uninitialised char values from an array whose address was taken, that results in unspecified values not undefined behaviour.

[SAI_Peregrinus]

I see you're correct, I misremembered. That isn't really much better, since there's no requirement that unspecified values ever actually change. Compiler developers are free to always return `0x00` when reading any unspecified `char` value, which wouldn't provide any entropy. XORing it in guaranteed that it couldn't subtract entropy, but if there were no other entropy sources they failed to return an error. OpenSSL being able to generate 0 entropy and not return an error in its RNG was still an important bug to fix.

[lmm]

> XORing it in guaranteed that it couldn't subtract entropy, but if there were no other entropy sources they failed to return an error.

No, they XORed data from a bunch of entropy sources into an intermediate buffer (that was never initialised, because the whole point of it was to be random) and then XORed that into a buffer from which the key was made. Debian's patch removed that final XOR. It wasn't a bug in the original code (other than being hard to understand).

[LtWorf]

Current kernels zero pages. The code was buggy to begin with.

[lmm]

No, there was no bug. The code used an uninitialised array as a place to XOR randomness from various sources into. It didn't initialise the array since there was no value in doing so, because the whole point is to be random anyway.

[nullc]

The crazy thing is that after this incident they restored the uninitialized usage and retained it there for the next half decade. It wasn't as mild as being a risk of future compilers destroying the universe: it made valgrind much less useful on essentially all users of OpenSSL, exactly what you want for security critical software.

(meanwhile, long before this incident fedora just compiled openssl with -DPURIFY which disabled the bad behavior in a safe and correct way).

[aragilar]

https://research.swtch.com/openssl provides more context: openssl was asked about the change, and seemingly approved it (whether everyone understood what was being approved is a different question). It's not clear why openssl never adopted the patch (was everyone else just lucky?), but I wonder what the reaction would have been if the patch had been applied (or the lines hidden away by a build switch).

[nullc]

> It's not clear why openssl never adopted the patch

OpenSSL already had an option to safely disable the bad behavior, -DPURIFY.

[aragilar]

In one of two cases I believe? I wonder what would have happened if both calls ended up being wrapped, if the bug would have taken even longer than it did to be found...

[t312227]

hello,

as always: imho (!)

i remember this incident - if my memory doesn't trick me:

it was openssl which accessed memory it didn't allocated to collect randomness / entropy for key-generation.

and valgrind complained about a possible memory-leak - its a profiling-tool with the focus on detecting memory-mgmt problems.

* https://valgrind.org/

instead of taking a closer look / trying to understand what exactly went on there / causes the problem, the maintainer simply commented out / disabled those accesses...

mistakes happen, but the debian-community handled this problem very well - as in my impression they always do and did.

idk ... i prefere the open and community-driven approach from debian anytime over distributions which are associated to companies.

last but not least, the have a social contract.

long story short: at least for me this was an argument for the debian gnu/linux distribution, not against :))

just my 0.02€

[hedora]

But why patch it in debian, and not file an upstream bug?

It’s doubly important to upstream issues for security libraries: There are numerous examples of bad actors intentionally sabotaging crypto implementations. They always make it look like an honest mistake.

For all we know, prior or future debian maintainers of that package are working for some three letter agency. Such changes should be against debian policy.

[master_crab]

If it involves OpenSSL, I will give the benefit of the doubt to everyone else first over OpenSSL.

Why? Heartbleed.

[LtWorf]

As some other comments say, the patch was posted to OpenSSL and someone said it was fine. They later said it wasn't a proper review.

[jbverschoor]

What would that have to do with phoning home?