What’s also sad is people feel the need to add the mental qualifier. As if it was not a part of the regular health.

“Oh it’s just burnout? I thought you had cancer or something” is probably a concern for many.

Publicly speaking about mental health opens up you, and everyone who experiences directly or indirectly similar mental health issues, to support and personal and collective understanding of mental health issues, and normalisation of mental health issues in societies and communities.

The ‘attack vector’ of getting a society to suppress open communication around mental health issues is huge compared to any software attack vector - an adversary would drool over the net effect of getting a nation to steep in its own undiscussed, untreated mental health issues.

oh hey! that means I get to thank you for it. it was super useful!

Does no one know what the backdoor does yet? Apart from how it embeds itself ofc

Thanks for the great post.

interesting point:

The real issue with a lot of small, foundational OSS libraries is just that there isn’t enough to do. They were written decades ago by a single person — and beyond bugfixes, they are not really supposed to change much. You don’t do major facelifts of zlib or giflib every year; even if you wave some cash around, it’s hard to build a sustainable community around watching paint dry.

All signs are currently pointing to deliberately acting in bad faith, not the consequence of an account compromise. The bad actor is active on mailing lists and private correspondence trying to push adoption of the backdoored versions.

For one example a private correspondence: https://news.ycombinator.com/item?id=39866275

For those not familiar with Tukaani:

Tukaani project began as a Slackware based distribution. Nowadays the Tukaani distribution no longer exists, but the distro work gave birth to a few subprojects. The most important of these is XZ Utils data compression software, whose earlier versions carried the name LZMA Utils.

Source: https://web.archive.org/web/20110831133615/https://tukaani.org/

At the risk of being seen to carry water for a bad actor, I think it’s probably too soon to be assigning blame to an individual person/persona.

It’s right that we scrutinise their other activity, but I’ve already heard people accusing them of being all sorts of things when it wouldn’t be the first time that an attack was inserted via a credible member of a project.

accounts compromised

If so, their signing key too.

Why future? If this is nation state funded, it’s possible that this is only one of many sockpuppet accounts of a group and they have many different accounts playing long games.

Completely agree.

With that said, even if every megacorp suddenly took a wildly generous attitude toward the open source maintainers whose products they use, even if the amount of new funding was beyond the most optimistic predictions, it would not solve this problem.

Even with alert, well-paid maintainers, sophisticated long con attacks will still slip through. And even if you imagine all PRs being committed only by vetted, full time maintainers, attackers with this kind of drive will just become one of those maintainers over time.

Not a given - non printables are part of the terminal ‘machine’ instruction set. Hard to do blind of course, but there’s enough ‘arbitrary execution’ custom OSC etc. sequences to play in all the “modern” pig lipsticking going on. Even in the mundane set we recently we have this:

https://people.rit.edu/sjf5462/6831711781/wall_2_27_2024.txt

Shorter way to ask this question - when did this avenue of attack become available?

Looks like libsystemd was linked late 2015, hitting unstable after jessie and before stretch.. Jessie, released April 2015, is where systemd became the installer default. A quick scan of the systemd news file makes me think liblzma was already linked to libsystemd at that time, but I didn’t go digging deep to be certain.

One reason why people might want (what anyone actually wants always “depends on a lot”) a library is the same context where catz.md is “not quite perfect” - namely, when the O(100us or more w/dynamic linking) overhead of execve is large compared to decoding & other work done (and the time matters at all, of course). For compressors that is easy to map to a user-visible description of “many small files” (e.g. a man page file sub-tree). In such a scenario, a library solution can be O(100X) lower overhead and this might matter.. sometimes.

As an experiment, on my system I have about 20,000 man pages. Doing a ripgrep --pre=catz foobarbaz on those 20,000 files via 4 cpus which (predominantly bzip2-compressed) takes about 2.0seconds. Divide by 5,000 (4 cpus) and that’s 400 microseconds per file. My catz and bunzip2 are both statically linked and a single double-execve takes 200-250 us for a minimal file. So, roughly 50% “dispatch overhead”. 2s is pretty trivial even compared to the time to compose this post. So, shrinking 2s to 1s is maybe not worth it, but you know, some people care and others might have 2e6 small files. It’s just an example experiment. (At some cost of can-the-decoder-program-do-that?? generality, one might server-ize catz and send messages to start decodoing new files maintaining separate-program-hood, but the reality of these decoder programs is to mostly do one-file-at-a-time - so any such would probably really be linking against a forest of libs anyway, returning to the original thing.)

Anyway, if in this “extreme” example it’s only O(2X), I doubt systemd ever needed linking against the libraries vs. using the CLI tool as it deals with handfuls of files by comparison, but @ibookstein makes a solid sibling point that an MMU boundary is only part of a full security boundary given, e.g. ptrace(2). I was mostly trying to caution Re: “perfection” here. I think many regard systemd as an unnecessary complexity explosion on many fronts (and that may possibly relate to being done/pushed by a big company like RedHat/IBM justifying licensing/support fees). There’s been a lot of chatter about xz due to its intentionality / the game theory / intrigue of it all, but vulnerabilities from bugs from complexity will be the more common vector for the foreseeable future.

I guess the point is that separate processes can be sandboxed separately (and typically are in situations like this) à la qmail from 1997 and the standard privsep practice used on OpenBSD (and elsewhere) for decades now.

That’s a decent point, but we’re not in the land of classic Unix anymore. Russ Cox explains it

https://research.swtch.com/xz-script

The effect of the scripts is to arrange for the nefarious object file’s _get_cpuid function to be called as part of a GNU indirect function (ifunc) resolver. In general these resolvers can be called lazily at any time during program execution, but for security reasons it has become popular to call all of them during dynamic linking (very early in program startup) and then map the global offset table (GOT) and procedure linkage table (PLT) read-only, to keep buffer overflows and the like from being able to edit it. But a nefarious ifunc resolver would run early enough to be able to edit those tables, and that’s exactly what the backdoor introduced. The resolver then looked through the tables for RSA_public_decrypt and replaced it with a nefarious version that runs attacker code when the right SSH certificate is presented.

So my reading is that for this attack, it would be too late for another process to modify its address space after the fact.

In that case the GOT would be locked down.

Remember that there are already A LOT of security mitigations out there – Jia Tan had to disable the fuzzing service. Valgrind flagged it, etc.

This was likely one of the best ways the attack could be executed. So I can easily imagine the whole thing being thwarted by putting xz-utils in a separate address space.

It wouldn’t even have been interesting for an attacker. They wouldn’t have even bothered Lasse Collin if this stray dependency in sshd, which he had nothing to do with, weren’t there.

As far as I understand, assembly level “gadgets” that already exist in the address space are one of the main things that attackers look for. Less sophisticated approaches take 10x more effort for them, or are infeasible.

Also, as mentioned, you can drop privileges in the xz-utils process. You can’t do that with dynamic linking of course.

Sure, reducing the amount of programs that unnecessarily link liblzma reduces the attack surface, and prevents this particular backdoor from working, but as long as there is still at least one remaining where the output of xz is used to run something as root the possibility of a backdoor remains.

I don’t really disagree with anything here, I’d just say “defense in depth” is a good thing, and multi-process composition is almost certainly better for this case. (I haven’t heard any arguments otherwise)

while still being completely aware of socket metadata, unlike inetd

What socket metadata do you mean? A child of inetd can call getsockname or getpeername; what else is there?

notifications are to make scheduling services easier, e.g. something that depends on sshd (lets say, some cursed service that uses ssh to elevate privileges or something) can’t run just because sshd is running, it needs to wait until sshd is ready to receive connections.

Thanks, this makes sense

From the “new world” of dependencies. There is upstream support for Kerberos, PAM, other compression methods, X11. Its not exactly a safe world?

I’d again say “defense in depth” is a good thing. The existence of other avenues of attack does not justify leaving open this one

Also someone disputed Pottering’s assertion of this on Hacker News - https://news.ycombinator.com/item?id=39878181

The ease of being able to crash any *nix really makes this a silly statement. Just use a lot of resources really fast and that’s it. Which is most often what a runaway process will do. A fork-bomb will bring down an entire company of thin clients.

Resource exhaustion is VERY different than Remote Code execution.

Multi-process architecture helps with both.

cgroups work on processes and I believe they will easily solve the fork bomb problem. You can limit or disable forking processes after a certain point.

If you don’t have separate processes, than many Unix and Linux mechanisms are unavailable to you. You can’t drop privileges or use cgroups.

DJB’s response to RCE is “not on my machine” and then refuses to add any fixes so he can keep his security record squeaky clean. Not exactly a great source of security processes

That could be true, but we could also learn from DJB. It’s not mutually exclusive.

You can implement more features in untrusted processes, rather than trusted ones

And what of the other options? Why focus on the two projects that were chosen, instead of all projects that could have been chosen as targets? That would have been chosen if this dependency path wasn’t available? It’s not like they would have just given up if lzma got removed from sshd’s dependencies for unrelated reasons.

Uh I focus on these precisely because someone catastrophically attacked them :) The exploit was deployed; it wasn’t theoretical.

IMO the dependencies should definitely be removed. That’s the easiest way to solve the problem.

There are a bunch of proposed “solutions” to this problem:

• Make all open source maintainers register a real identity
• Make all open source maintainers log in with 2FA
• Make some kind of “big tech funded” security thing that throws money at open source projects. (already exists – Linux Foundation threw some money at bash in 2014, after ShellShock)

IMO there are upsides and downsides to all of them.

But there is zero downside to:

• sshd should not link libsystemd, as Pottering suggested. It should use the systemd protocol with 10 lines of C.
• systemd should probably not depend on xz-utils at all. Compression works perfectly over pipes.

The fact that there are other attack avenues don’t justify keeping this one open. It seems poorly implemented and designed to begin with

Hm I think this is just repeating the “all shell is just gobbledygook” line of thinking.

Which comes with “I’ll just do whatever it takes to make it work, without understanding what I’m writing, or understanding the language I’m writing in”.

So:

• If you didn’t notice that in thousands of lines of “line noise”, I don’t blame you.
• But if I focus you on xz -d | /bin/bash , and you still don’t know what’s wrong, or are not willing to spend some time to learn why there could be something wrong, then there is a problem.

I would go as far as say it’s laziness or carelessness in coding.

There shouldn’t be special, lax rules for the “crappy code” – when you write crappy languages, you actually need to take more care.

The care you put it in should depend on how critical the software’s function is, not really the language it’s written in. That seems to be lost on most people writing shell. (and yes some of those people were autoconf maintainers using it 20+ years ago)

Most shell is kinda copied and pasted, and it is “accepted” to have string injection bugs and the like. But we should change that.

Likewise, if I focus your attention on this line:

// Construct the command we want the $SHELL to execute
let command = format!("cd {:?}; /usr/bin/env -0;", dir);

You should know what’s wrong with this. Full stop. No excuses.

Is it OK for you to write SQL without knowing what an SQL injection is, how to prevent it, and how to look for it?

• Answer here, including why the wrong type of quoting is just as bad as no quoting - https://lobste.rs/s/hru0ib/how_lose_control_your_shell#c_jamktx
• more - https://lobste.rs/s/imfbha/strings_do_too_many_things#c_vcre5s

This is basically the point of https://www.oilshell.org/ - there’s no reason that shell shouldn’t be a “real” language, rather than a second class language.

• e.g. we fixed shell’s error handling - https://www.oilshell.org/release/0.21.0/doc/error-handling.html
• and the silly word splitting that trips everyone up - https://www.oilshell.org/release/0.21.0/doc/simple-word-eval.html

This has been done for 2-3 years now.

We need some more help from people who know how programming languages work - see #help-wanted on https://oilshell.zulipchat.com and almost every release announcement

• The last release had a big part about running autoconf scripts - https://lobste.rs/s/ivdeel/oils_0_21_0_flags_integers_starship_bug
  • https://www.oilshell.org/blog/2024/03/release-0.21.0.html

To the extent that you believed in RIIR (“Rewrite it in Rust”) for memory safety, you should also believe in RIIY (“rewrite it in YSH”) for string safety.

Shell is actually a fundamental language – it’s not going away – because it’s glue that joins others.

Every time someone makes a new programming language, I say: “OK that’s another reason you’re gonna need a shell script”. New programming languages create interoperability problems, and shell solves them.

How do a Rust program and a Zig program communicate? The lowest common denominator is likely a byte stream. What about a Mojo program and a Zig program?

I’m not saying that anyone “should” have noticed – Andres Freund was definitely a lucky break for us.

There’s a very long chain of obfuscations, and xz -d | bash isn’t in the repo literally.

But from reading this, I believe it is literally in the tarball, though the tarballs all seem to be gone, so I can’t really check:

https://www.openwall.com/lists/oss-security/2024/03/29/4

What I’m saying that if you managed to see xz -d | bash, which is relatively early in the chain, then it’s a sign to keep digging. It’s a sign that those compressed testdata files are bash code.

And there’s no reason for that in xz, or anywhere else. It’s suspicious.

There’s a lot of digging after that though, and we should be grateful that someone did it relatively quickly!

Sure, that’s true no matter what the language is. Most code isn’t looked at.

But I would say that shell is even worse than that. Shell is a language where people who don’t know it write it, and try to read it.

e.g. C programmers generally have to write it to package their software

And somehow they will accept flagrantly dangerous idioms in shell, when the equivalent in Python or C would be rejected.

This is basically the point of https://www.oilshell.org/ as I mentioned above. We want to disentangle two things

1. “string soup” – generating shell with shell, dangerous mixing of code and data
2. strings and byte streams as the lowest common denominator between parts of heterogeneous systems. e.g. my Zig + Mojo question above. The “narrow waist”

The second thing is a fundamental part of shell, but the first thing isn’t.

You still have that matrix with make-like systems. You just have it in an inscrutable form that is hard to debug (and easy to insert obfuscated backdoors in!). The Go tool has to solve all those same problems and it does it with a relatively well documented series of build tags, compiler flags, and dependency manifests. How does os.OpenFile work on WASM? Well, it’s right here: https://cs.opensource.google/go/go/+/refs/tags/go1.22.1:src/os/file_open_wasip1.go

Having conventions is not perfect, and there will always be some corner case that won’t work and need a custom build process, but it’s more than enough for 99% of software that just has simple needs, like a compression library that just needs to be able to read and write streams and files.

In Go, if I wanted to compile in some dependencies only conditionally, I would put them behind build tags. It’s a non-problem. OS and arch are just two particular kinds of build tags, but they can be arbitrarily anything. Go version is another build tag.

It’s rocket science in C because they made it rocket science because that was easier than solving the coordination problem. I’m not saying the coordination problem is easy to solve. It’s obviously not or else it would be solved. But it literally is just a coordination problem.

[Comment removed by author]

Can’t a git server serve different copies of the repo to certain IPs? Eg a build server?

At the point the only thing left would be commit checksum, but that’s similar to tarball checksum. :shrug:

yeah. if it’s any comfort I assumed that as well, at first…

NixOS is discussing this at https://discourse.nixos.org/t/reconsider-reusing-upstream-tarballs/42524.

“improve reproducibility” is a beautiful euphemism for “don’t rely on arbitrary ‘binary’ releases” (which release tarballs of source code might as well be!).

Speaking of Arch, here’s their update: The xz package has been backdoored

Users of Arch Linux packages don’t have to download neither git sources nor tarballs if they just want to install them.

Package maintainers or users that builds packages from PKGBUILD files can either re-use downloaded git clones, or spend a few extra seconds on downloading from source, in the name of transparency.

Does this cover giving away code for free on the internet? I suppose maybe the obfuscation would be an indication of malice but that kinda seems thin. You’re not exactly getting paid to deliver something here and then adding a back door.

That’s such a good example of Lennart’s gaslighting that I’m going to save it for the next time I have to explain why I don’t trust the guy.

I have been telling anyone who wanted to listen that if all you want is sd_notify() then don’t bother linking to libsystemd

while linking to a page that says

using this library should be preferred in order to avoid code duplication

[Comment removed by author]

Awesome!

I don’t think we have needed autoconf since the early 2000s at the latest.

Gone are the days that we worry about supporting HPUX, Solaris, OSF/1, etc. Anytime I see support for those OSes, or even endianness, I know there are expoitable bugs in there and I can’t even test them.

Autoconf is a symptom of a problem we no longer have. Next we need to phase out C and C++ and their accompanying broken non-existent module systems.

Also when I said “this doesn’t work in practice”, I meant “it doesn’t work in practice for portable C/C++ builds”

Not saying anything about Rust or Zig! The languages are used in different ways, e.g. embedded vendors fork C/C++ compilers and ship them with SDKs for their boards

Also, the situation with C/C++ is more similar to JavaScript than it is to Rust/Zig.

JavaScript is also standardized, and has multiple implementations.

How do you do feature detection in JavaScript? With eval() or hasProperty() etc.

eval() is the dynamic language equivalent of invoking the C++ compiler at configure time – it’s a fully general method to detect what’s there.

There is no pre-defined taxonomy of features. That doesn’t really scale

i.e. someone OUTSIDE the project can make something like - https://caniuse.com/wasm-reference-types,css-anchor-positioning

But it’s not part of the web platform itself, because it fundamentally can’t cover all possibilities. There can be obscure bugs that exist on only a single line of code in a particular compiler/runtime, and you might want to detect them. That’s pretty common in both JS and C++.

How do Rust and Zig deal with the fact that Android doesn’t have getpwent() ? It doesn’t have /etc/passwd, while every Unix system does.

i.e. Can you compile and run them on Android, and if so, what happens when you try to call the function?

That’s what we are detecting above: Oils 0.20.0 - Eggex, JSON, and Android

There are also a few compile time checks in the xz utils that do appear necessary. A few days ago, I was actually going to suggest that it doesn’t need configure at all, because compression is a “pure function” you can do in standard C.

https://salsa.debian.org/debian/xz-utils/-/tree/46cb28adbbfb8f50a10704c1b86f107d077878e6/m4

I’m not sure that’s true though – it would be nice to see some analysis of that. What’s actually needed for xz? Performance features like SIMD and detecting the number of cores are frequent reasons that “C is not standard”.

Also, for better or worse, Rust and Zig both have a single compiler implementation, with no separate standards committee. C and C++ are standards, which implies multiple implementations, which implies extensions and differences that may need to be probed at compile time.

Another issue is that C and C++ are defined mostly separately from the OS. e.g. ANSI C is a different thing than POSIX, where as in Rust/Zig those concepts are mixed together. I think that’s probably a good choice for them.

I think there is room for a larger set of standard functionality in C/C++, but someone would need to do that work …! And it’s hard.

I’m not really defending the C/C++ model, but I would say it is more “decentralized” and thus messier, while Rust and Zig are more centralized.

(BTW @Melkor333 implemented the Android check. We can also use help detecting glibc FNM_EXTMATCH – another thing Rust/Zig probably don’t deal with, naturally because they’re not C. glibc and musl libc implement different functionality. OS X libc is different too.

So if anyone wants to learn how to write plain shell scripts that enable your software to be run on many platforms, – including ones that don’t exist yet – and distributed widely, that could be a nice place to start - https://github.com/oilshell/oil/pull/1814/files )

Yeah. One of the problems with autoconf is its config.cache support is incomplete and buggy. It doesn’t properly separate platform feature tests from configuration options, so if you change the options you have to blow away the cache and redo all the platform tests. And it isn’t designed to allow different packages to reliably share the results of platform tests.

pkg_config is effectively pre-computed feature test results for working out what a library’s path names and linker options are. It’s better than autoconf but suffers from unix’s traditional yolo approach to quoting

Yeah, that’s bad. How do we fix it? I guess just by providing $CXX? If so, that’s easy

I did go through the GNU configure standards a bit when writing it, but we also prioritize what people actually want. If people want Android, then we have Android support. If they want cross compiling, then we should have that.

I never really cross compile anything, but I remember submitting patches to some of Landley’s projects, and this one implied that using QEMU is easier than cross compiling for full system builds - http://landley.net/aboriginal/

Basically so many build systems are broken with respect to cross compiling, that it’s easier to run a non-cross build in QEMU.

But I think it’s very easy for us to support, if people want it. Issues/patches appreciated!

I know this is not a popular opinion but: you make their companies liable for using hobby projects. That doesn’t mean not using xz at all. But either they do the maintenance themselves, or a sufficiently large number of companies that depend on XZ (that’s practically every tech company on Earth at this point, and a lot of non-tech companies) pool their resources to sponsor practical maintenance operations for XZ.

This is a model that already works well in virtually all engineering activity out there. The reason why most appliances in one’s home aren’t fire hazards, for example, is that, while many electrical engineers tinker with things and most of their contraptions are fire hazards, shipping a fire hazard commercially, or worse, shipping something without at least bothering to check if it’s a fire hazard, is so many layers of risky and illegal that most companies won’t go near it. Their executives would absolutely love to package these things, I mean, they’re basically already made, they’re free modulo marketing material, but they don’t want to risk it. Lots of successful products originated in hobby projects but they did not happen by literally replicating one without any checks.

The “convincing business owners” angle may be relevant for small companies but in general it’s just not how it works. There are so many technical details, spread among so many products and projects, that business owners rarely play a role in these decisions. You wouldn’t have to convince business owners to pay for what they can take for free, you’d have to convince their subordinates, many layers down the org chart, and across dozens of departments, to spend extra money on things they can’t explain up the management chain and which may backfire through entirely mundane channels like yearly evaluations.

Yes, culture happens top down – but whatever method you pick has to work for every company out there, from well-meaning tech companies to organic farms that employ exactly two people who care about computers, and are put in charge of their Instagram accounts and email lists. Anything that’s significantly harder than “is this thing FDA-approved?” is already dangerously complicated – very few people can make an informed decision about it and no commercial organisation out there grants that degree of autonomy so far down the org chart, on any subject, computer-related or not, to make it a viable option.

This whole situation is ridiculous. There’s a link up in the channel where several people with high-paying jobs are complaining about slow maintenance in XZ, a hobby project, because “the community” (i.e. their companies) needs it. Business owners and their subordinates already understand that maintenance is necessary, and they’re in the software industry, they know that money can get it, you don’t need to convince them of anything at this point. There’s nothing preventing them from paying for XZ maintenance right now.

The reason why they don’t do it isn’t that they don’t understand, it’s that charging for (access to services based on) repackaged hobby projects without being upfront about it and without disclosing the risks to their customers – risks which they aren’t even liable for in most cases – is a legal business option.

If they want the free version they don’t get to complain when it’s full of bugs, simple as that

It was in git, the code to inject the malware in the release tarball was commited to the repository.

I’m not sure I agree. The actual malicious code was well disguised as “autotools gunk” that makes my eyes glaze right over; with a semi-plausible commit message, I can’t imagine anyone catching it, short of someone specifically auditing for malicious code.

C isn’t a “fashionable-to-sneer-at language”?

I’m sorry, but the fashionable to sneer at languages are so much worse than this. It’s very common for JavaScript packages to download compiled binaries as part of the build or even at runtime and it’s very common for them to upload bundled and minified code to npm. The culture of “do whatever it takes to make it work with npm i ... without the user having to think about a thing” is very strong there. They use a thousand packaging tools with incompatible lock formats and a thousand ways to irreproducibly build the package source into an intermediate form that then gets uploaded to npm, so every npm i call is a YOLO x1000, for every one of the thousands of transitive dependencies a simple project typically has.

There’s no polite way to talk about their practices.

The causal chain is fraught. I believe the actor or actors behind this attack decided long ago that the link to libzma via libsystemd was a viable attack vector - one of possibly many. So the work was predicated on that, including targeting the repo, getting access etc. Then when the circumstances changed they had to rush to implement it.

It’s just like trying to launch a legit software product. You predict a market, try to craft a product to fit it. Sometimes the market doesn’t develop in the way you expect and your product fails.

Instrumental or not, the point is a (potentially well funded state?) threat actor would find some other vector if this particular vector hadn’t existed. So saying if not for systemd this attack would not have happened is speculation at best and ludicrous at worst.

Yes, while major vendors pay CNCF’s operating expenses which go to staff and conferences and evangelists, CNCF employs very few software engineers. It’s just too expensive given their limited sponsorship funds.

Seek to get more funding for FOSS.

I agree with this! We’re in a weird spot of where the world’s infrastructure is built on top of open-source projects with little time and funding.

we can assume that in the short to medium future faking your identity online, even via a video call, is as easy as doing it by email/text

Agreed! AI doesn’t exactly help here. It can be made harder (by requiring verification) but ultimately, it is a force multiplier.

why should FLOSS maintainers and project leads shoulder the responsibility to vet contributors for honesty and integrity?

They don’t have to, but I am assuming that some projects will have an interest in making sure their code is somewhat protected from such bad actors in the future. But you are right — FLOSS maintainers don’t have to do anything, the software is provided as-is, without warranty.

I don’t quite know how to make sense of the document you have linked. It seems to address some gripes that trans people have with legal names. It does not seem very relevant to my point, and does not dispute the existence of legal names (as is on your social security/birth certificate/driver’s license/passport, which are mentioned in the document, see page 135).

Whatever you call it, by Legal Name I am referring to the name that is on your identity documents. The US does have identity documents. It does not even have to be a name, you could substitute s/legal name/legal identifier/. Just something that uniquely identifies a person. It could be an Ed25519 key for all I care, as long as there is a regulated registry, such that submissions to open-source software is linked to a person rather than a pseudonym. I suppose in the US you could use a social security number for this purpose, though I don’t understand the identity-theft implications of that.

I’m also not saying that people cannot keep using nicknames or pseudonyms — they are useful in communication. Just that it seems quite risky to have an entire civilization build on top of software that is written by people anonymously, it seems like a big attack vector.