5 ms·

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

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_keys_(Debian-specific) https://en.wikipedia.org/wiki/OpenSSL#Predictable_private_ke...

guappa 1y ago
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 1y ago
  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.
  - aragilar 1y ago
    If you go to https://tracker.debian.org/ https://tracker.debian.org/ for any package, it lists patches that need to be sent upstream.
    - lifthrasiir 1y ago
      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.
      - guappa 1y ago
        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.
      - bayindirh 1y ago
        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".
  - pabs3 1y ago
    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.
- lmm 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        I agree, but it's not clear that there aren't worse design issues in the alternatives.
  - SAI_Peregrinus 1y ago
    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 1y ago
      > 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.
aragilar 1y ago
https://research.swtch.com/openssl 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 1y ago
  > It's not clear why openssl never adopted the patch OpenSSL already had an option to safely disable the bad behavior, -DPURIFY.
  - aragilar 1y ago
    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...
upofadown 1y ago
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-19 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/patches/freepg/0003-gpg-allow-import-of-previously-known-keys-even-witho.patch/ 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 1y ago
  > 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).
master_crab 1y ago
If it involves OpenSSL, I will give the benefit of the doubt to everyone else first over OpenSSL. Why? Heartbleed.
- LtWorf 1y ago
  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 1y ago
What would that have to do with phoning home?
t312227 1y ago
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/ 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 1y ago
  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.

guappa 1y ago

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 1y ago
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.
- aragilar 1y ago
  If you go to https://tracker.debian.org/ https://tracker.debian.org/ for any package, it lists patches that need to be sent upstream.
  - lifthrasiir 1y ago
    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.
    - guappa 1y ago
      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.
    - bayindirh 1y ago
      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".
- pabs3 1y ago
  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.
lmm 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      I agree, but it's not clear that there aren't worse design issues in the alternatives.
- SAI_Peregrinus 1y ago
  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 1y ago
    > 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.

aragilar 1y ago

https://research.swtch.com/openssl 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 1y ago
> It's not clear why openssl never adopted the patch OpenSSL already had an option to safely disable the bad behavior, -DPURIFY.
- aragilar 1y ago
  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...

upofadown 1y ago

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-19 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/patches/freepg/0003-gpg-allow-import-of-previously-known-keys-even-witho.patch/ 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 1y ago
> 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).

master_crab 1y ago

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

LtWorf 1y ago
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 1y ago

What would that have to do with phoning home?

t312227 1y ago

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/ 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 1y ago
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.