[conspire] xz exploit and backdoor

[Rick Moen]

Quoting Ron / BCLUG (admin at bclug.ca):

> Ya got me wondering - after the ¿HeartBleed? ssh vulnerability a while
> back, there was talk of moving to something like LibreSSH from OpenBSD
> due to the convoluted codebase of OpenSSH.
> 
> That hasn't happened, that I'm aware.
> 
> Anyone know what happened - a major code refactor? A re-badging of
> LibreSSH?  A collective amnesia allowing us to continue on without
> awaking in the middle of the night, screaming in a cold sweat?

I'm going to have to frame this as a question, because I honestly don't
know:  Did LibreSSH ever even happen at all?  I find no traces of a
codebase, just people about a decade ago speaking of it in (perhaps)
theoretical terms.

A decade ago was about when the OpenBSD Foundation got so sick and tired
of OpenSSL problems that they created the pared-down LibreSSL fork,
which was a very good idea and is quite meritorious.  But LibreSSH?  I 
haven't found it actually having come about, or at least if it did it
seems to have vanished without a trace.

A propos of nothing, a long time ago, I maintained the canonical (well,
most comprehensive) catalogue of all known SSH implementations for all
platforms, but I haven't seriously maintained it for long years.
http://linuxmafia.com/ssh/ 

By contrast, I mention Dropbear and wolfSSH because they _arguably_ have
some of the traits I seek:  Both are spare in their feature sets, in
part because both have a niche in embedded use.  Both have a possibly
concerning drawback, of a thin maintainer base.  (See: xz-utils.)

Both are actively maintained -- but one must be careful to not
overinterpret last-released dates.  Sometimes, a codebase is so-called
"unmaintained" because nothing about it has needed maintenance in a long
time, the classic example being procmail, which from the cynic's
perspective is unmaintained and has no upstream.  From a non-cynical
perspective, though, it's finished and doesn't need work.

That happy state is more likely in a modestly scoped codebase than a
complex, featureful one, of course.
 
> I'm rather hesitant to install what I often call "boutique" software
> - something created, often from a fork of a larger project, to
> scratch some itch.

That can go either way.  It could be a one-off stunt that ends up having
no future, _or_ it could become a variant with many fans and enough good
maintainer because of the particular differences, a with LibreSSL in
relation to the unloved spaghetti-code OpenSSL codebase.

> Always wary that the maintainers can keep up to the security issues
> in a timely manner.

You bet.  With the complicating factor that, if the particular
difference is one of decomplication and risk-reduction, then
lackadaisical maintenance becomes much less of a problem because, 
with reasonable luck, problems will become less urgent and less
frequent.

A subcare of that is a persistent fork performed via a modest changeset, 
the example I have in mind being the ungoogled-chromium Web browser.
It's thinly maintained and not all that often re-released, but OTOH 
since it consists primarily of a set of patches to strip Google, Inc.
corporate crud from Chromium, and those patches finesse away a lot of
the problematic bits of Chromium, the urgency and frequency of needed
re-releases goes down.

Here's what I recently wrote about that on Mastodon:



@kurtsh (About
https://www.npr.org/2024/04/01/1242019127/google-incognito-mode-settlement-search-history:)
I've saying people for ages that Google Chrome being from a surveillance
capitalism firm is a red flag, but, as usual, some people are slow
learners.

Since 2015, pseudonymous developer "Eloston" and a small number of
others have removed the code for Google-specific Web services from
Chrome's open-source base browser Chromium, replaced Google's binary
BLOBs, added configuration flags missing from Chrome, and in general
applied a patchset to remove corporate embuggerment -- as persistent
fork "ungoogled-chromium".

It's the lightest-weight, most privacy-preserving, Web browser based on
the underlying Chromium (V8, Blink) browser on all OS platforms.  On the
minus side, ungoogled-chromium developer support is concerningly thin
(and pseudonymous), a risk factor your colleague Andres Freund
(@AndresFreundTec), the hero of the year, recently reminded us of.  

Details for the curious:  

https://en.wikipedia.org/wiki/Ungoogled-chromium
https://www.youtube.com/watch?v=sTLRLawI3s