jnxx

> Why would they even do that

More layers of obfuscation. For example in order to be able to attribute the backdoor to a different party.

It is of course also possible that Lasse Collins is a nice real person who just has not been able to review this. Maybe he is too ill,or has to care for an ill spouse, or perhaps he is not even alive any more. Who knows him as a person (not just an account name) and knows how he is doing?

The thing is there are two possibilities:

1. An important project has an overburdened / burnt out maintainer, and that project is taken over by a persona who appears to help kindly, but is part of a campaign of a state actor.

2. A state actor is involved in setting up such a project from the start.

The first possibility is not only being an asshole to the original maintainer, but it is also more risky - that original maintainer surely feels responsible for his creation and could ring alarm bells. This is not unlikely because he knows the code. And alarm bells is something that state actors do not like.

The second possibility has the risk of the project not being successful, which would mean a serious investment in resources to fail. But that could be countered by having competent people working on that. And in that case, you don't have any real persons,just account names.

What happened here? I don't know.

If a project targets a high-profile, very security sensitive project like the linux kernel from the start, as the archived tukaani web site linked above shows, it is justified to ask questions.

Also, the exploit shows a high effort, and a high level of competence, and a very obvious willingness to play a long game. These are not circumstances for applying Hanlon's razor.

It is not just systemd which uses xz. For example, Debian's dpkg links xz-utils.

One scenario for malicious code in embedded devices would be a kind of killswitch which listens to a specific byte sequence and crashes when encountering it. For a state actor, having such an exploit would be gold.

If this is a conspiracy or a state-sponsored attack, they might have gone specifically for embedded devices and the linux kernel. Here archived from tukaani.org:

https://web.archive.org/web/20110831134700/http://tukaani.or...

> XZ Embedded is a relatively small decompressor for the XZ format. It was developed with the Linux kernel in mind, but is easily usable in other projects too.

> *Features*

> * Compiled code 8-20 KiB

> [...]

> * All the required memory is allocated at initialization time.

This is targeted at embedded and real-time stuff. Could even be part of boot loaders in things like buildroot or RTEMS. And this means potentially millions of devices, from smart toasters or toothbrushes to satellites and missiles which most can't be updated with security fixes.

The web of trust is a really nice idea, but it works badly against that kind of attacks. Just consider that in the real world, most living people (all eight billions) are linked by only six degrees of separation. It really works, for code and for trusted social relations (like "I lend you 100 bucks and you pay me them back when you get your salary") mostly when you know the code author in person.

This is also not a new insight. In the beginning of the naughties, there was a web site named kuro5hin.org, which experiemented with user ratings and trust networks. It turned out impossible to prevent take-overs.

And, Joey Hess has counted at least 750 commits to xz from that handle.

https://hachyderm.io/@joeyh/112180715824680521

This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.

There is also a variety of new, parallelized implementations of compression algorithms which would be good to have a close look at. Bugs causing undefined behaviour in parallel code are notoriously hard to see, and the parallel versions (which are actually much faster) could be take the place of well-established programs which have earned a lot of trust.

The time stamp of a git commit depends on the system clock of the computer the commit was checked in. This cannot be checked by github & co (except that they could reject commits which have time stamps in the future).

> They want to attack this company or this group of individuals. But someone who backdoors such a core piece of open source infrastructure wants to cast a wide net to attack as many as possible.

The stuxnet malware, which compromised Siemens industrial controls to attack specific centrifuges in uranium enrichment plants in Iran, is a counterexample to that.

I am thinking more in so-called rubberhose cryptoanalysis.

https://xkcd.com/538/

> And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code.

Build systems can even have undefined behaviour in the C++ sense. For example Conan 2 has a whole page on that.

> What is "capabilities" supposed to mean?

"Is this app allowed to read your contacts?"

What could be a different case is Clojure. But I am not sure, and the performance characteristics of Clojure make it well-suited for server-style concurrency, but not so much for high-performance parallelism.

> COBOL

> MATLAB

> MUMPS

One of each uglier than the one before. But:

Is there something we can learn from these examples? Are there good reasons for these languages being adopted? And are the Racket designers with their approach of "a language to define interoperable DSLs" up to something?

Isn't Rust really well suited as the main extension language of functional-preferring, strongly-dynamically-typed, interactive languages, such as Racket, Guile, OCaml, or F#?

I am thinking more and more it would be a pretty good idea to keep the place habitable where we are now. Besides other things, it is quite beautiful here.

> most definitions of life require that it be made of cells

Is there a deeper reason for that?

How we would call such depends how you define and understand life. If one defines it very widely as a dynamic dissipative process in an open thermodynamic system which organizes matter and energy, reacts to its surroundings, can reproduce itself, may have some symbolic representation of its surroundings, and possibly even care for its reproductions, intelligent life on a star is entirely possible, even if it would be very, very different from us.

If you on the other hand, define it as a set of dissipative structures which are based on organic carbon chemistry and which is able to exist somewhere between -30 and 40 degrees centigrade, replicates itself, use Deoxyribonucleic acid to store generational information, nourish their young by mammary glands, and walk on two legs, we are probably pretty alone in the universe.

Another things to think about, all life forms on our planet are relatives in the sense that we have common ancestors and shared DNA, even such "alien" creatures like tarantulas or centipedes. Given that, I am not entirely sure that it would be pleasant for us to meet technologically superior aliens. We would have to pray that they have much more empathy with other living things than we primates ourselves can usually muster.

Maybe it would have a heartbeat period of 11 years?

> The main reason I use Linux is because it's the only platform that actually respects me as user.

Exactly this. And one things proprietary software nowadays sucks big is being economical with my attention and not wasting it. Imagine this: One day, I arrived at work, logged in to the Windows box, opened the web browser to read new mail messages about the thing we were furiously and deeply working and, and what I got next was some in-browser news advertisements from MSN about sexually abused teenagers. You can imagine how hard I cursed. Try to place your boss some yellow press front page over the keyboard while he/she is having their morning coffee, and see what happens.

> While some Linux purists dislike containerized application installation programs such as Flatpak, Snap, and AppImage, developers love them. Why? They make it simple to write applications for Linux that don't need to be tuned just right for all the numerous Linux distributions.

The good thing is that for end users, Guix and Nix (as package managers) do cover exactly the same set of features - but both are much friendlier to developers than containerized apps. And of course they are truly FLOSS and "open source" in that stuff is built from source and that sources are readily available to the users. This matters, since this makes the software more friendly: It is user-friendly because it is written by the users, in difference to a party which has other things as their top priority.

I think it is always wise to constrain unneeded dependencies. And this counts even more in embedded systems.

But on the other hand, programming artefacts, languages and their library systems compete in terms of features, which will usually lead to an ever growing number of dependencies. At least this is what we observe. Even if not all of this is really necessary, this would probably be hard to reverse in general.

> Genuinely interested: what do people think of their tons of third-party dependencies in Rust?

Here are three things I think, and they have in fact nothing to do with Rust:

1. The easier it is to add dependencies, the more dependencies will be added on average - unless you work purposefully against that.

2. The effect of a rising average number of dependencies in libraries is that their number of dependencies grows as well, and the number of their dependencies' dependencies... up to dependency graphs of several hundred nodes size. Like in exponential growth. An example would be the dependency graph of jquery.

3. I observe this "exponential" growth can have chain-reaction-like effects, like if you have a mass of U235 that achieves critical mass. Below that critical value, some neutrons flying around might trigger a few fissions, but these die out. Above that value, neutrons lead to fissions which lead to more neutrons and so on. The same can happen with complexity in multi-component software. At some point, complexity goes through the roof.

And the latter is especially true if backwards compatibility is not strictly observed, since backwards-incompatible changes tend to be infectuous in that they often make their client components (parents in the dependency graph) backwards-incompatible as well, in other words, there is breakage that propagates up the dependency graph. That breakage might die out and be able to be contained by local fixes, or it might propagate. And once your dependency graph becomes large enough, it is almost guaranteed, that you have breakage.

All these things together is why I believe that systems like NixOS or Guix are the future (but of course there might be other developments in that space).

Now, make it to generate a really good, comprehensive, concise book on how to write complex CMake configurations and you will be a hero ;-)

> Which tbh is a bad thing. Just because change a doesn't textually touch change b doesn't mean they don't interact.

A good example for this is code which grabs several locks and different functions have to do that in the same order, or a deadlock will result. A lot of interaction, even if changes might happen in completely different lines.

And I think that's generally true for complex software. Of course it is great if the compiler can prove that there are no data race conditions, but there will always be abstract invariants which have to be met by the changed code. In very complex code, it is essential to be able to do bisecting, and I think that works only if you have a defined linear order of changes in your artefact. Looking at the graphs of changes can only help to understand why some breakage happened, it cannot prevent it.

> It's an administrative problem: someone has to decide whose code is the right one to use.

Or maybe an architectural one.

> When the contents are identical, but the order of commits is different, git will conflict and require manual resolution.

But why would this normally happen? Different developers working on the same files which by chance make the same changes? Isn't that unlikely?

> 1) git will not accept the push because it's not on top of current master branch, person B needs to fetch and merge/rebase before pushing again.

But is this not the right thing to do? A kernel is a complex piece of software. Changes in one place can have very non-obvious consequences in other places (think of changes that cause deadlock because locks are applied in the wrong order). Of course, it is theoretically nice if I know that a change to e.g. documentation or fixing a typo in a comment is not affecting the Ethernet driver or the virtual file system layer, but this is down to the architecture of the project - this is not something that a version control system can prove.

Given that, it seems desirable to me that the source tree has as few different variations, permutations how to get there, and so on, as possible, since this makes testing and things like bisecting for something like a broken lock or another invariant much easier.