Re: xz exploit and backdoor
Rick Moen <[email protected]>
| Newsgroups | gmane.org.user-groups.linux.cabal |
|---|---|
| Organization | If you lived here, you'd be $HOME already. |
| Message-ID | <[email protected]> |
Quoting Ron / BCLUG ([email protected]): > 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 _______________________________________________ conspire mailing list [email protected] http://linuxmafia.com/mailman/listinfo/conspire