Rust-Based Coreutils 0.0.26 Increases Compatibility With GNU Coreutils

[jacob]

Every project should develop their own libraries for absolute everything. That will improve security for sure. Including the standard library. We can not trust into someone else standard, can we? No, we can't. Neither should we trust the compiler, who knows what that thing generates? Home baked compilers everyone. And why would we trust in the operating system? Did we develop it ourselves? Excepting Linus Torvalds, we didn't! Not Invented Here(c) is the new/old paradigm.

I definitely don't trust the CPU manufacturer, for sure the microcode contains malware (jokes aside, with Intel, AMD and ARM at least, it actually officially does).

[darkonix]

I definitely don't trust the CPU manufacturer, for sure the microcode contains malware (jokes aside, with Intel, AMD and ARM at least, it actually officially does).

OMG who knows what those transistors are doing inside the chips? Nope, we need our own CPUs made with kitchen appliances to be sure.

[Quackdoc]

OMG who knows what those transistors are doing inside the chips? Nope, we need our own CPUs made with kitchen appliances to be sure.

This is actually a very valid criticism which is why nearly every major countries governement is trying to do chip development inhouse, or at least supporting allies that do.

[jacob]

The whole point with XZ was that "Jia Tan" built trust and got the malicious update shipped in many distros as a normal update. Checksums prevent MitM attacks, they mean nothing if you intentionally update to a new release that later turns out to be malicious. The Cargo ecosystem is absolutely vulnerable to an XZ-style attack, same as any package-based ecosystem where you might have packages maintained by a single person that doesn't get much scrutiny.

What you say is true for any dependency of any kind, not just for package-based ecosystems. The XZ attack doesn't actually involve any package ecosystem, it's literally "here's the source tarball of the XZ lib, download it and compile it yourself". It would apply even to any project open to external contributions, to the compiler used to build the software, to the kernel it runs on etc. It would, of course, be the same with Cargo.

However Cargo, without being immune, is still less open to attacks than projects without dependency managers (or than something like pip or npm). With Cargo, you at least have the assurance that you are building against the same actual code as the upstream project. It's not a reproducible build, but it goes let's say half way there. In other words, if your upstream promises that they actually do their homework that they review and vet what they actually use, and if you trust them for that, then you're safe. With C/C++, or npm, pip etc., you don't even have that. In fact you can't even be sure that some reverse proxy along the way hadn't been compromised to serve you a malware-enabled version of a C library you are trying to download.

Also Cargo has a "cargo audit" utility, which checks the versions of crates that you are really using against known security vulnerabilities. It's certainly not foolproof in that it wouldn't have stopped the XZ attack until it was discovered and reported (in the hypothetical example in which systemd and XZ were written in Rust), but again, it's more than most if not all common ecosystems have to offer.

[ZeroPointEnergy]

Every project should develop their own libraries for absolute everything.

Or we can just stop only arguing with extremes and recognize that there is clearly a scale between how granular split up the shared libraries are and that there is a trade-off here about how that spreads the eyes on a particular repository of those components.

Clearly this is a development that weakens the trust you can put in such a piece of software, simply because it reaches a count that is far beyond what anyone can keep track of even if they are diligent about their dependencies.

[darkonix]

Or we can just stop only arguing with extremes and recognize that there is clearly a scale between how granular split up the shared libraries are and that there is a trade-off here about how that spreads the eyes on a particular repository of those components.

Clearly this is a development that weakens the trust you can put in such a piece of software, simply because it reaches a count that is far beyond what anyone can keep track of even if they are diligent about their dependencies.

It seems that your conclusion is a bit extreme to me.

[ZeroPointEnergy]

It seems that your conclusion is a bit extreme to me.

What is extreme about recognizing that there is clearly a trade-off for how splintered your dependencies are?

[darkonix]

What is extreme about recognizing that there is clearly a trade-off for how splintered your dependencies are?

I don't disagree with that analysis but with the conclusion: "...weakens the trust you can put in such a piece of software, simply because it reaches a count that is far beyond what anyone can keep track of..."

C/C++ were created well before the concept of dependency repositories was commonplace, and never developed a standard. Most modern languages reuse libraries easily: Python, Java, JavaScript (ugh), Go, Rust. That's the standard today. People need to adapt and find ways to ensure security in other ways than just avoiding reuse.

[ZeroPointEnergy]

Most modern languages reuse libraries easily: Python, Java, JavaScript (ugh), Go, Rust. That's the standard today. People need to adapt and find ways to ensure security in other ways than just avoiding reuse.

The same problem exists for all of them to different degrees. "This is the new thing, get used to it, lol" isn't really a way to address the concern, it's just handwaving it away.

If this issue is not obvious to you, then feel free to use system tools that build from 300 dependencies, play the canary in the coal mine and find out.

[darkonix]

Sure, why not?
Don't Linux packages have lots of dependencies with each package system too? Those are in the system rather than language packaging system. Don't you worry about those too?