Programming

There is a huge difference between vetting packages once every 6 years,

And here the myth shows its head. No one is actually "vetting" 10s of thousand of packages, to a meaningful degree.

And all distros have rolling channels and testing channels, so the every X years part is mythical itself.

In the case of Debian, when is the mythical vetting taking place exactly? Whenever a Debian unstable/sid package gets updated? That's a rolling repo.
Or is it when world is frozen, and the unvetted packages which lived happily in "unstable" and "testing" will now magically get vetted on their way to "stable", in a few months (not six years as you imagined).

You clearly lack basic knowledge about what actually goes on in a distro release cycle.

This is because rust and crates makes it impossible to do any form of dynamic linking. Which is why some people have gripes with rust and avoid it.

You missed the point. crates.io is a source registry. Debian ships binary packages (yes, including rust ones).

Where do you think Debian gets source packages for C or C++ from? Did you think they get them in the (physical) mailbox? 🎅

As for dynamic linking, the "security" argument for it has been discussed and debunked. You can search the web for discussions regarding that. Most arguments for .so has been debunked, in fact.

But for C, Java, and other languages, it is possible for distros to ship and manage libraries, which has the benefit that the various libraries can have their security issues fixed automatically.

Nothing is "automatic" when it comes to distro maintenance. Much more so when an upstream doesn't give a f*** about helping you patch your X years old version. If Red Hat, Canonical, ...etc wasn't actively paying developers to do maintenance, Debian wouldn't exist as it is. But even then, that only covers a very small fraction of core packages.

The model of vendoring dependencies, breaks this. With Cargo (or uv or etc), the programs move very fast, and updates break things. In order to prevent their program from breaking, developers pin packages. And then, they don’t update them.

Pinning and vendoring are orthogonal.

The original talking points were about source supply chains. But people like you seem to confuse concerns across multiple chains from the individual upstream dev to the binary distro repo mirror.

Pinning is actually the only way to actually (almost*) guarantee that built code would work correctly. What distros sell you is "should work" and "API looks compatible" and "this patch hopefully doesn't break the interface".

And more ironically, why distros do is global pinning, so the problem is apparently not pinning itself, but upstreams choosing the pinning themselves, right? right?

"But they don't fully pin.. security updates smth smth"

Good. Let's continue..

Here is cargo-audit ran against radicle-tui

Good.

The next best thing to pinning is semver-compatible updates.

Now you have an example where you will see that to "fix all CVEs", you need to run the total of TWO whopping commands.

You ran the first command already. The second is cargo update (or cargo update <only_audit_mentioned_packages> if you want to be more precise.

cargo update only does semver-compatible updates, as released, authorized, and supported by the upstreams, whose knowledge of the code and its interfaces infinitely trumps your random distro maintainer doing raw patching. This is how a coherent competent ecosystem operates.

Some of what the distros do is actually not far away from this. If you looked close enough, you will find that it's not rare for a stated "frozen" version to be a complete lie, with distro patches effectively updating the distro source package to a later patch, or sometimes even minor version, without changing the version number.

But of course, they wouldn't tell you about any of that, because the myths must live on 😉.

I can be confident that if I make a program tied to libraries or programs that the distro provides, this stuff will automatically be patched and handled for me.

While not completely misplaced, your confidence is inspiring 🙂.