What does HackerNews think of 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

I 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. ;)

It'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

Regarding 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

Not 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 desire 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.