RSrs_rs_rs_rs_rs·May 14, 2025
> Debian stable users missed heartbleed entirely
Missed it? Not at all, Debian pioneered that style of bugs years before!
https://github.com/g0tmi1k/debian-ssh
In Multiple security issues in GNU Screeng0tmi1k
debian-ssh
Shell2017–2025
g0tmi1k / debian-ssh
debian-ssh
Debian OpenSSL Predictable PRNG (CVE-2008-0166)
8Distinct people
9Mentions
0Explicit recommenders
409GitHub stars
What to know before exploring
What it is
Debian OpenSSL Predictable PRNG (CVE-2008-0166)
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year9 dated mentions
Observed mentions: 2017-08-02 11:59:57 UTC to 2025-05-14 09:49:45 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
9 sourcesOuch, that one's bad: https://github.com/g0tmi1k/debian-ssh#the-bug
>These lines were removed because they caused the Valgrind and Purify tools to produce warnings about the use of uninitialized data in any code that was linked to OpenSSL. Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG. Instead of mixing in random data for the initial seed, the only "random" value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.
In CVE-2024-6409: OpenSSH: Possible remote code execution in privsep childCVE-2008-0166
It was really bad.
https://github.com/g0tmi1k/debian-ssh
In Debian on xz-utils: revert to version that does not contain changes by bad actorThere's mainly three kinds of patches:
* make the software behave like Debian needs it (configuration is stored somewhere in /etc/, no additional downloads at runtime, use the system libraries instead of vendored ones)
* security backports. Debian freezes the functionality at release and only provides security updates. Many software nowadays just includes security fixes in new releases bundled with new functionality.
In combination these two kinds of patches lead to growing differences between a Debian released version 1.2 and the "real" 1.2, making it harder to handle bug reports (e.g. you get a bug report for version 1.2-Debian, but only support the "real" version 1.4 with a whole set of updated libraries).
The third kind of patch has mostly gone out of style; it's when Debian thinks they can improve the software. That lead to things li
Read the rest
ke removing randomness from SSH keys: https://github.com/g0tmi1k/debian-ssh
On the flip side, Debian doesn't upgrade to a new version when a vulnerability is found in the shipped version. Instead, they try to backport just the fix.
If Debian shipped version n and the upstream fixes the vulnerability in version n+5 (not unusual, as debian stable is routinely out of date for 2-4 years depending on the length of the testing freeze and the point in time of the stable lifecycle), this can range from trivial to near impossible in a timely manner.
They also tend to be opinionated about the software they ship and do include many Debian-specific patches. Most of them are harmless or just small changes to make the software work better with the Debian way of configuring things; sometimes much more catastrophic: https://github.com/g0tmi1k/debian-ssh
In Debian is at the heart of the most successful Linux distrosI would have thought https://github.com/g0tmi1k/debian-ssh would be the most famous issue in many people's memories of poor (read: absent) PRNG use. ;)
In An Almost-Secret Algorithm Researchers Used to Break Thousands of RSA KeysIt's definitely not so cut and dry - maintainers have actually managed to introduce vulnerabilities into software too. The famous Debian SSH key generation issue comes to mind.
https://github.com/g0tmi1k/debian-ssh
In Flatpak 1.0 Released, Ready for Prime TimeRegarding 1., not just ugly workarounds, remember how Debian broke their OpenSSL PRNG for several years to silence warnings for analysis tools [1] – read the impact section and shiver if you had not heard of this one before. There are real world risks associated with spurious warnings.
[1]: https://github.com/g0tmi1k/debian-ssh
In Lessons from Building Static Analysis Tools at GoogleNot even the maintainers really understand what they are doing :
https://github.com/g0tmi1k/debian-ssh
> There was an #ifndef PURIFY there for a reason. It's because the openssl authors knew that line would cause trouble in a memory debuger like Purify or Valgrind.
Where a debian maintainer screwed the RNG of OpenSSL to make valgrind happy. This made any key generated on a debian or ubuntu system from 2006 to 2008 very easily breakable.
Downstream should never touch packages beyond backporting fixes made by upstream.
Here's another example of upstream vs downstream conflict in debian :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477454
Or PHP developers being fed up with both RedHat and Debian messing with their runtime on whims :
https://derickrethans.nl/distributions-please-dont-cripple-p...
This is why I heavily support the desir
Read the rest
e for a new packaging system targeted at developers: snaps, flatpak. The downside of having multiple copies of the same libraries pale in comparison to giving back power to upstream. Distro maintainers are routinely modifying codebases they don't understand. Allow us to have a standard installation process that can install packages.. made by the developers themselves, upstream. Just like all other operating systems do.
And Debian, unlike RHEL/CentOS, packages a lot more than they can even reasonably maintain. The vast majority of packages in a Debian stable are insecure, the security team simply cannot handle the large amount of software outside of the truly core stuff (kernel, web servers) :
https://statuscode.ch/2016/02/distribution-packages-consider...
If you aren't supposed to use the packaged wordpress, phpmyadmin or node, why is debian distributing those packages? Debian by distributing these things in their repo encourages the naive first time linux user to install them through their facilities.