but it didn’t seem useful to them.

Did you expect him to just outright admit that you paid for granite and got Swiss cheese 🙂 👋

Nice(!) to see so many people who don't know anything about programming get successfully propagandized into going against something they know nothing about.

Below is a list of CVE's published against original sudo, all within the last 5 years. You may not heard of them, because CVE's against non-Rust projects are not news 🫣

sudo CVE's from within the last 5 years

(severity scores are not available/assigned always)

CVE-2021-3156 (Severity: High)

Sudo before 1.9.5p2 contains an off-by-one error that can result in a heap-based buffer overflow, which allows privilege escalation to root via "sudoedit -s" and a command-line argument that ends with a single backslash character.

CVE-2021-23239

The sudoedit personality of Sudo before 1.9.5 may allow a local unprivileged user to perform arbitrary directory-existence tests by winning a sudo_edit.c race condition in replacing a user-controlled directory by a symlink to an arbitrary path.

CVE-2021-23240

selinux_edit_copy_tfiles in sudoedit in Sudo before 1.9.5 allows a local unprivileged user to gain file ownership and escalate privileges by replacing a temporary file with a symlink to an arbitrary file target. This affects SELinux RBAC support in permissive mode. Machines without SELinux are not vulnerable.

CVE-2022-43995 (Severity: High)

Sudo 1.8.0 through 1.9.12, with the crypt() password backend, contains a plugins/sudoers/auth/passwd.c array-out-of-bounds error that can result in a heap-based buffer over-read.

CVE-2023-7090 (Severity: Medium)

A flaw was found in sudo in the handling of ipa_hostname, where ipa_hostname from /etc/sssd/sssd.conf was not propagated in sudo. Therefore, it leads to privilege mismanagement vulnerability in applications, where client hosts retain privileges even after retracting them.

CVE-2023-22809 (Severity: High)

In Sudo before 1.9.12p2, the sudoedit (aka -e) feature mishandles extra arguments passed in the user-provided environment variables (SUDO_EDITOR, VISUAL, and EDITOR), allowing a local attacker to append arbitrary entries to the list of files to process. This can lead to privilege escalation.

CVE-2023-27320 (Severity: High)

Sudo before 1.9.13p2 has a double free in the per-command chroot feature.

CVE-2023-28486

Sudo before 1.9.13 does not escape control characters in log messages.

CVE-2023-28487

Sudo before 1.9.13 does not escape control characters in sudoreplay output.

CVE-2023-42465

Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.

CVE-2025-32462 (Severity: Low)

Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines.

CVE-2025-32463 (Severity: Critical)

Sudo before 1.9.17p1 allows local users to obtain root access because /etc/nsswitch.conf from a user-controlled directory is used with the --chroot option.

The special comment from @[email protected] in this thread deserves some focus:

The Rust hype is funny because it is completely based on the fact that a leading cause of security vulnerabilities for all of these mature and secure projects is memory bugs, which is very true, but it completely fails to see that this is the leading cause because these are really mature projects that have highly skilled developers fixing so much shit.

So you get these new Rust projects that are sometimes made by people that don’t have the same experience as these C/C++ devs, and they are so confident in the memory safety that they forget about the much simpler security issues.

This has all the classics from the collectively manic discourse that has been spreading lately

mature projects

highly skilled developers

Rust projects that are sometimes made by people that don’t have the same experience as these C/C++ devs

C/C++ devs (deserves a separate entry)

they forget about the much simpler security issues.

The only classic missing is "battle tested" which is a crowd favorite these days.

But of course the internet gantry's knowledge about CVE's reported against non-Rust projects, is as good as their understanding of the Rust language itself.

Someone bothering to be minimally informed, even when lacking the technical knowledge to maximize their understanding of the information, would have known that the original "mature" sudo has CVE's published against it all the time. A CRITICAL one was rather recent even. And as it just happens, the ones not (directly) related to memory safety did outnumber the ones that did recently (5 year span). Which ones had higher severity is left as homework for the internet gantry.

The discourse centered around memory safety is itself lacks the knowledge to realize that the overall value proposition of Rust is much bigger than this single aspect, although the breadth of sub-aspects that cover memory safety offered by Rust is itself also under-grasped.

The internet gantry's susceptibility to propaganda and good old FUD done by ignorant and drama mongering "influencers" and "e-celebs" would have been almost concerning, that is if their transient feelings mattered in any way, in the grand scheme of things.

Needless to say, but this is comment is not meant to be disparaging towards Todd C. Miller or any other sudo developer/maintainer. He has a good relationship with sudo-rs developers anyway, not that the internet gantry would know.

Linux 7.1: Kicinski Called It ‘LLM-pocalypse.’ Then Deleted 138,000 Lines.

---

The Linux networking maintainer wrote about an ‘LLM-pocalypse’ in the same pull request that deleted 138,000 lines from the kernel.

---

One hundred thirty-eight thousand lines. One pull request.

“If we want to have a fighting chance of surviving the LLM-pocalypse, this code needs to find a dedicated owner or get deleted.”

Jakub Kicinski, Linux networking maintainer, wrote that in his pull request message. Then he deleted it. All of it. Six entire subsystems. 138,000 lines of networking code that the world switched off years ago but the kernel kept compiling anyway.

On April 26, 2026, Linus Torvalds merged that pull request into Linux 7.1-rc1.

The first time in Linux history that AI-generated bug reports forced the removal of working software. Kicinski made it happen, and Linus approved for rc1 release; it ships to every server, phone, and embedded device running Linux within months. These protocols are permanently removed from the kernel.

What Kicinski Actually Deleted

Over 138,000 lines were erased in a merge window that also brought 12,996 changesets from 2,011 developers, 342 of them first-timers. The explicit motivation for the deletions: AI-generated security bug reports are flooding maintainers with work on code that has no real users left.

The networking subsystem removed ATM (Asynchronous Transfer Mode), AX.25, amateur radio networking, ISDN (Integrated Services Digital Network), Bluetooth CMTP (the bridge protocol between Bluetooth and ISDN), CAIF (Communication CPU to Application CPU Interface), and dozens of old ISA, PCMCIA, and PCI networking drivers.

ATM was already a relic when I was debugging VLAN (Virtual LAN) tagging issues in 2008 at a telecommunications company during my internship. ISDN was the protocol our office PBX (Private Branch Exchange) used before I ripped it out and replaced it with SIP (Session Initiation Protocol) trunks. These protocols didn’t matter anymore, but a decade ago. The code stayed because every maintainer feared breaking a setup they could not see.

CC @[email protected]

Is my name on the list?
Yes Sir
Sh...
Oh, but it actually has a different surname
Phew

You see, surnames are important. With them, you get a working fedilink, instead of a broken one.

(I don't care about the drama. I just saw users getting caught by this bug.)

Pull requests were designed for open source contributions from untrusted strangers. Applying them to trusted teams is a category error.

wrong
didn't bother reading further

Super-human claims require evidence. And asking for that evidence is not an insult.

How many layers should I go through?

Here is a few:

• PR's replaced patch sets. Patch sets have nothing to do with "strangers". Both are the medium where review for a logical grouping of code changes takes place. There is no separate categories here.
• In most open-source projects, everyone involved is a "stranger" to others anyway, including co-developers if any.
• PR's/patchsets are orthogonal to T*D/Trunk-Based/Team-focused development. How can this be missed is hard to imagine. I would have assumed everyone is aware of draft/wip/rfc PR's, or dev/trunk branches. And tests need development alongside functional modifications anyway.

using Tor for universal, straightforward seeding of git repos.

That doesn't sound right. Maybe design/implementation details would make it less nonsensical.

C implementation of radicle

Now this just sounds like a bad joke. Especially with the tor project itself spending all this effort to give us arti as a readily usable embeddable rust crate.

Rust has features that are not directly related to memory safety, but introduce paradigmatic and ergonomic improvements that help writing correct logic more often. Features like sum types (powerful enums) and type classes (traits, how generics are implemented) quickly come to mind. Hygienic macros and procedural macros are also very powerful features.

Sometimes the two aspects (language feature and memory safety) come together. For example, the Send and Sync traits is the part of the type system that contributes to implementing thread safety.

So it's not all just about (im)mutability, lifetimes, and the borrow checker, the directly relevant safety features.

Also, the tooling and the ecosystem are factors the value of which can not be understated.

Yeah. The ArchLinux corporation must be losing money left and right because of this.

Are they stupid?!

The real news is that iroh hit v1.0.0.

noq is a fork of crate that implements QUIC which iroh uses. In other words, it's a minute implementation detail not immediately relevant at all to people who don't even know what iroh is (yet).

How did we get here? OP text is copied verbatim from the README, with the presumption that it's relevant, but it isn't.

How did that happen? I would assume no human was directly involved in doing that, which would be par for the course with that shit-reposting account.

A long time ago, there was this misconception that "linux" was terminal-only. You know, like the interface sysadmins and Hollywood hackers use.

A small long-defunct non-tech forum I used to be a member of had a tech sub-forum, and in that sub-forum there was a new post one day introducing "linux" and covering some basics. It was full of DE screenshots (GNOME 2 and KDE 3) specifically to dispel the "terminal-only" misconception.

That was almost ~20 years ago. And the rest is history. I never liked Windows or M$ anyway for both technical and non-technical reasons. So it wasn't that hard to convince me.

I almost exclusively use the terminal for everything except web browsing now, and don't use a DE. So you could say that I myself ironically became a perpetuator of the misconception 😉

A reminder that Bjarne doesn't actually code. He is a bureaucrat.

LPE is in the title. And you sound like someone who doesn't know what that stands for.

This also comes with a good public write-up on github (not some monetized fancy domain), with an explanation why it went public early, which wasn't their fault.

There is a lot of intelligence insulting going on in the security theater industry, which is something I talked about here more than once, despite not being exactly a prolific commentator. But unfortunately for you, this particular case is one of the least offensive.

reflector uses https://archlinux.org/mirrors/status/json/ to get mirror status info, and caches it under ~/.cache/Reflector/. So as long as that end-point works, reflector should work.

I just grabbed a copy and pasted it at http://0x0.st/Ki3Y.json.

Anyone can grab that JSON data and use file:// URLs so they are never out. e.g.

curl -L https://archlinux.org/mirrors/status/json/ > /tmp/mirror_status.json
# or if down, use pasted json
curl -L http://0x0.st/Ki3Y.json > /tmp/mirror_status.json
# and then
reflector --url file:///tmp/mirror_status.json ...

But, as you noted, this has been mostly a nothing-burger from a user perspective anyway. Other than the homepage being unavailable on occasion, everything else has been mostly available just fine as you can see from https://status.archlinux.org/.

I didn't notice https://gitlab.archlinux.org/ going down either.

BTW, and as a general rule of thumb, NEVER take specific technical advice from these editors. They don't actually know much, and this is me trying to be nice.

Take for example:

For AUR disruptions, it's a bit of a pain if you're not a regular git user, but you cloned packages directly from the GitHub Arch Linux mirror. To do this, use the command:

See that link ;) At least he got the command below it correctly, somehow.

So I gave the actual code a one minute look (literally).

Picked src/radicle/util.c, since that was the last file touched.

The level of defensive programming doesn't look that good (and I'm trying to be nice here).

Here is an example, and note that I didn't do C in a while:

#include <stdio.h>
#include <string.h>

void rad_rstrip_nl(char* str) {
    int len_str = strlen(str);
    if (str[len_str-1]=='\n') {
      str[len_str-1] = 0;
    }
}

bool rad_get_input (char* str, size_t bufsiz) {
    if (!fgets(str,bufsiz,stdin)) return false;
    rad_rstrip_nl(str);
    return true;
}

int main() {
  char a[] = {0,0,0,0};
  bool i = rad_get_input(a, 4);
  printf("%lu\n", strlen(a));
  rad_rstrip_nl(a);
  return i;
}

The two functions above main() are copy-pasted from that file.

Let's zoom in:

int len_str = strlen(str);
if (str[len_str-1]=='\n') {

Here we're accessing str[len_str-1] without checking len_str first.

But you might be thinking, maybe len_str can't be zero!

Let's compile first with the AddressSanitizer enabled:

# compile
% gcc -Wall -fsanitize=address t.c -o t

Now let's see how easily we can have fun:

 % echo -n '\0' | ./t
=================================================================
==2949689==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7ba827af001f at pc 0x56032434d259 bp 0x7fff1d199010 sp 0x7fff1d199000
READ of size 1 at 0x7ba827af001f thread T0
    #0 0x56032434d258 in rad_rstrip_nl (/tmp/t+0x1258) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51)
    #1 0x56032434d311 in rad_get_input (/tmp/t+0x1311) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51)
    #2 0x56032434d3e4 in main (/tmp/t+0x13e4) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51)
    #3 0x7fa82a227740  (/usr/lib/libc.so.6+0x27740) (BuildId: 020d6f7c33b2413f4fe10814c4729dce1387f049)
    #4 0x7fa82a227878 in __libc_start_main (/usr/lib/libc.so.6+0x27878) (BuildId: 020d6f7c33b2413f4fe10814c4729dce1387f049)
    #5 0x56032434d124 in _start (/tmp/t+0x1124) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51)

(The rest of AddressSanitizer output omitted.)

Another function from the same file:

char* rad_strcpy (char* out, const char* inp, int from, int len) {
    const char* inp_shifted = inp+from;
    int len_inp_shifted = strlen(inp_shifted);
    if (len <= len_inp_shifted) {
	memcpy(out,inp,len);
	out[len] = 0;
    }
    else {
	memcpy(out,inp,len_inp_shifted);
	out[len_inp_shifted] = 0;
    }
    return out;
}

Here, inp is shifted before inp length is checked, which doesn't look safe. But my one minute is up, so I didn't dive into the function callers.

Pretending C is a good choice in 2026, then not being extra vigilant with defensive programming, is not a good look. I remember myself being more vigilant in my wrappers even when I was a beginner.

This is made worse by the developer repeating literal memes like:

One issue I have with rust is that it adds another layer of trusting the compiler isn't backdoored. All UNIX/Linux systems use the gcc toolchain

Maybe such an enlightened developer should know that you can bootstrap rustc from mrustc using GCC.

Or to avoid ad hominem accusations:
No code. Don't Care.

And no benchmarks either. That intro about stack vs. heap also reads like someone who never went further than sophomore-level knowledge, or someone explaining things to kids.

We Ran Our Own Infrastructure

Another revisionist myth. SourceForge (the first forge!) wasn't "our own", nor was BitBucket (mentioned by author), or Gitorious (which was famously archived btw). or sourceware, or ...

I guess we can call ftp servers like the gnu ones "ours". But that's about it as far as where congregations of relevant projects lived.

Did some projects self-host with trac, cgit, mailman, ...etc? Yes, of course. Just like how some projects self-host today with gitea/gitlab/...etc.

Anyone who's actually relevant is already aware of the technical details. Anyone with a non-gossipy interest in the topic has already watched the talk (which is available), or will watch it before opening their mouth.

What remains is the internet gantry, which is irrelevant.

“free” vpns and privacy are basically contradictory.

While this has been swallowed as a fact for a few years, it happens to be both not intrinsically true, and can be potentially very dangerous.

It assumes that non-profits and collaborative endeavors don't exist, where there is no "product". And it's like saying networks like TOR are unsafe because they are free.

Someone else already covered the danger of the reverse assumption that "paid" equates "safer", regardless of what service we are referring to.

People will look for and use "free" VPNs no matter what, unfortunately. So while we can't guarantee safety for anyone, the least dangerous course of action is to guide people to the least suspect options. e.g. using Proton's free tier, or Bitmask (Riseup, Calyx) via known open-source clients with known permissions/modes of operation.

As is often the case, clever-sounding generalizations usually end up being shit for advice.