Collecting downvotes since before forums even had thank you's.
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.iois 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
.sohas 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(orcargo update <only_audit_mentioned_packages>if you want to be more precise.cargo updateonly 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.ioecosystem 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
cargoitself is a problem. It's a build tool that is not tied tocrates.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.ioincluded. 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.
It's officially centrally hosting the non-pre-moderated non-official user contributed build-scripts, where "user" means literally anyone.
I'm not sure what argument you're trying to "win", and to what end. Or why do you think anyone would care about the manufactured confusion you're trying to concoct.
All community projects are open contribution. Most non-community ones too. You know, almost the whole point of open-source!
But that's not the same as "user repo", which is a wild west concept on purpose.
zlib-rs=> crate replacing non-rust zlibfirefox=> where the replacement is happeningtrifecta=> the foundation sponsored to develop the replacementsMaybe 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 🙂.
Unless every single dependency is version locked
Which is the case with
Cargo.lock. You can even lock the toolchain itself withrust-toolchain.toml. There a reason whyuvdevelopers knew what good practices to implement in their quest to fix python tooling 😉.one update or maintainer change can silently compromise the whole chain.
That's another failed analogy. There is no orphaning and total randos taking over in crates.io (same for npm/pypi I would assume). The owner himself must hand over or give permissions to a specific person/account. That's another implicit chain of trust that doesn't exist in AUR.
Nothing is fail-proof of course, as the
xzincident showed.I don't follow npm incidents closely, but the cases I saw involved the legit owners/maintainers themselves, who were either compromised, or genuinely doing the compromising themselves 🤣.
Arch is a single rolling release
This is largely irrelevant to the discussion.
hit Rust and PyPi in a similar way.
It won't be similar for the all the reasons stated.
And a strict “version locking” ethos can lead to security problems down the line, too.
That's where language implementation compat guarantees, audit tooling (
cargo auditet al) and good tooling in general, together with a good semver story in the ecosystem itself, ALL come together to make this largely not a problem.This works well enough in the
crates.ioecosystem.From what I hear,
npmhas the audit tooling part covered. But it's failure in all the other aspects that's making the situation unattainable.As with
pypi, there is the pain point of python minor release updates breaking shit all the time. But beyond that, I don't know enough to give an informed take (other than thatuvis a blessing for those who don't want to get their hands really dirty in that ecosystem).And again, these details and differences are very relevant.
It’s easy to sneak some malware downloader into a long Rust dependency chain, even if it’s technically all open code.
As of now, the number of successful supply chain attacks (where a chain of real dependants exists) in the
crates.iosystem is ZERO.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.rspulling 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
-Osto 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
rustixcrate which wraps syscalls directly.Otherwise, and if loading huge shared libraries is fine, then you might as well not go
nostdat all, since you can just pass-C prefer-dynamicfor 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 😉).
no allocation churn under heavy alt-screen TUI workloads (vt100 0.16 leaks tens of GB under multi-hour
claude-style streams; this does not).Interesting stress test you got there.
OH NO, they must be devastated!
- Jump
wild v0.9 released (wild is a super-fast linker with the end goal of supporting incremental linking)
It's on the title, you don't even need to read the excerpt👆.
But more seriously, the excerpt is from the release/tag notes, but what's quoted above is from the README.
- Jump
wild v0.9 released (wild is a super-fast linker with the end goal of supporting incremental linking)
While eventually implementing incremental linking was the inspiration, as already pointed out. It's actually already faster than mold (see benchmarks).
Thank you for continued work on this.
cfg-if,mime_guess,sysinfoopensslis not referenced anywhere in code, but it's not even a build/dev dependency, and there is nobuild.rsfile.ffmpeg-sidecarwhich apparently downloadsffmpegbinaries from weird places ifffmpegis 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).