BB_C

• Unused deps: cfg-if, mime_guess, sysinfo

• Unused dep openssl. There are mentions of it being used for "remote compilation". I have no idea what that means, or how it would work by adding a dependency like this. Not only openssl is not referenced anywhere in code, but it's not even a build/dev dependency, and there is no build.rs file.

• Depends on ffmpeg-sidecar which apparently downloads ffmpeg binaries from weird places if ffmpeg is not in $PATH, a crate apparently "inspired" by webshits, and based on a GitHub action (which clearly has a very different threat model compared to executing those binaries on end-user machines).

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 🙂.

Weird how this random thread came back to life, just to rehash some talking points.

See my comments here and here.

In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

If you followed the link, you would have seen that nothing actually fishy was found, unlike the implication.

Cargo and crates are basically just as bad as npm, just less popular, which is why they haven’t been hit yet… And it’s currently very difficult to build rust programs without cargo.

The number of actual supply chain attacks actually effecting anybody in the crates.io ecosystem is ZERO. In npm, it's a weekly occurrence.

less popular

Rust cleared the critical mass and critical relevance milestone years ago. Most people can run desktops without npm or local js code. This is increasingly unfeasible for rust components. And yet, nothing happened. And that's not a coincidence (read linked threads). That doesn't mean nothing will ever happen. Nothing is fully fail-safe. But the talking points themselves are completely false.

Also, I would like to see you explain how cargo itself is a problem. It's a build tool that is not tied to crates.io. You can use different registries, repos, and even full vendoring with it (which you can switch to with one command, and it will just work). But I can't wait to hear your explanation 🙂. Examples of tools that do it better, with an explanation why would also be appreciated 🙂.

Stable linux distributions have extremely strong supply chain security in comparison to language specific package managers.

This myth is discussed extensively in the linked threads at the start of this comment, especially the second one.

Debian, for example, was not affected by the xz utils backdoor, due to it’s policy of only doing cherry picked security patches, and ignoring feature or bugfixes for the most part.

Also covered in the linked threads. But let's address specifics.

• Debian unstable/sid (the rolling branch) was affected. Debian is not special.
• Debian stable was unaffected because it runs multi-year old packages. This specific attack was discovered early, so they were spared. Other upstream-controlled attacks could target projected-to-be-stable upstream versions, and remove the compromised part later, reversing that effect (depending on who would discover the malicious code, and what are they testing looking at).
• The stable distro model is broken. Distro developers are not better than upstreams at judging upstream code. Many non-security tagged bugs can become security ones. And out-of-date(ness) itself can have adverse affects in other ways. This was always been known/realized by people who know the reality of the situation. But nowadays, "AI" security scanners had a complete mockery of the stable distro model "security" claims.
• Debian's willy-nilly "security" patching in particular, lead to multiple scandals in the past. This is not all theoretical. One day half the internet had to re-issue SSL certs/keys because of the mythical Debian super security. And on that subject, do you know what distro wasn't affected by the specific xz attack, despite actually shipping the compromised xz version? It's Arch. Why? Because they didn't patch systemd with xz support thinking they can outsmart an upstream.
• Distros pull from upstreams anyway (code has to exist somewhere), crates.io included. So they inherently can't have better supply chain security than upstreams at the code level, unless you're also a believer in the popular myth "they review and vet everything ". Some distros may have good/better build security practices. But that's about it.

I would prefer Java if you cared strongly about supply chain security

What makes you think JAVA or its ecosystem(s) are unique or immune from any of this?

The project description reminded me of a project I saw years ago. I looked it up, and I'm pretty sure it was oxen, which is surprisingly still going, although their hub looks half-dead.

zlib-rs => crate replacing non-rust zlib
firefox => where the replacement is happening
trifecta => the foundation sponsored to develop the replacements

Maybe I'm influenced by the fact that I pre-knew all of the above. But as I wrote, it's quite ironic choosing this perfect title in particular to complain about 😉.

On the topic of low(ish) level dependencies getting incrementally replaced with Rust rewrites, a Google employee did a presentation on the same topic recently.

People usually like at least some minimal context attached, in case they are not familiar with the topic at hand.

But as it happens, the title of this specific post is rather self-documenting. So I'm not sure what's "non-descriptive" about it.

Or perhaps we have automated complaining now, pushing against automated low quality (re-)posting. And we got caught in the middle as remnants of the genuine human interaction that used to take place online 🙂.

still weaker than Debian

There is a lot of myths that surround what distros actually do, can do, and have the resources to do. We had this discussion in one of the two threads I linked.

That's a failed analogy. The AUR is an end-user build-script repo, not a source/binary/source+binary repo for both devs and sometimes users.

If you e.g. install a CLI tool via cargo, there is at least an implicit tree of trust, with each dependant in a dependency tree doing at least some minimal vetting of dependencies. And the source is all there anyway (barring exceptions like build.rs pulling code, or the indirection of proc macros).

The same applies to npm and pypi, although there is no distinction between "code" and "binary", given the scripting nature of the languages. But some pypi packages do actually distribute binaries (e.g. C/C++ compiled libraries). Don't know about npm.

But, if I'm not mistaken, the py/js tooling wasn't always there for stuff like full pinning of dep versions like cargo, and that's a very important technical detail.

With the AUR, there is no trust tree. And often no fixed code (or binaries) to look at (e.g. *-git packages). So the feasibility of doing any sort of global in-tree checking/vetting is not there. On the other hand, source repos are responsible for removing, or at least flagging, malware or otherwise harmful packages once that becomes known.

Incidentally, I commented on both AUR security and cargo trust here and here. So, I will stop blabbing.

If it's Tex, it's not modern.
It's like:
"We have Swiss cheese with no holes."
Swiss cheese, or no holes? Pick one!

Another hit-and-run Rust thread!

I advise against any more activity here, until, or rather, unless OP appears again.

    "-C", "link-arg=-lstdc++",
    "-C", "link-arg=-lsupc++",
    "-C", "link-arg=-lgcc_s"

Now, that's just funny. But hey, you're using -Os to keep that binary size low 😇

And what's with the global allocator being initialized in a module? (didn't/don't know if that even works)

If you want to do things really minimally, check out the rustix crate which wraps syscalls directly.

Otherwise, and if loading huge shared libraries is fine, then you might as well not go nostd at all, since you can just pass -C prefer-dynamic for that elusive magically-small std-using binary 🙄

Get well brother.

As a son of a specialist physician, I know full well how hard it can be to connect the dots between random symptoms and a problem that's actually in the brain. It's not rare for such confirmed diagnoses to become case presentations (which is how I know 😉).