One downside is that the cached file is not independently archived so it could be tampered with. Thanks for the idea.
You could have multiple researchers archive it and store copies independently. Then tampering would show up accross copies.
Unfortunately, central hosting doesn’t guarantee that it is tamper free. The host could be hacked, or could be malicious. Archive.is was caught tampering with their archived pages:
https://en.wikipedia.org/wiki/Wikipedia:Archive.today_guidance
Debian stable, Red Hat, and Ubuntu LTS were not affected. They also happen to be popular on servers, because of things like this.
Debian only updates packages on a new distro release, every 4 years. Red Hat does so every 13 years. There is a huge difference between a 6+ year window to detect packages, and a less than a week’s notice because you are keeping up with the latest from upstream.
I will address this one at the end, since it’s a longer point.
Okay. And? We are talking about supply chain security here.
There is a huge difference between vetting packages once every 6 years, and the continuous, ongoing, toilsome process that you are made to in order to maintain systems like cargo’s build system.
The XZ utils backdoor could have easily effected any distro that uses xz for any form of root/system level service. The backdoor makers decision to not do this doesn’t actually make Arch or other distros that did this more secure. Debian stable did not receive vulnerable code in the first place. Big difference.
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.
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.
The Java ecosystem, and it’s various language specific package managers have lots of problems. But I am specifically talking about the Java ecosystem available from stable Linux distros, like Red Hat or Debian.
So. Why would I want a stable distro? Why would I want “old” packages? The reason is very simple: The absolute guarantee of compatibility between the security updates, of the programs themselves, and dynamically linked libraries.
If I make, say, a Java program, and tie it to Java packages available from the stable distro, when programs in that
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. This results in them shipping code with CVE’s to their users, even though the CVE has already been fixed in an upstream version.
I like to run cargo-audit, or the go equivalents on the open source projects I look at, and I almost always find vulnerabilities of varying degrees of criticallity. Here is cargo-audit ran against radicle-tui: https://gist.github.com/moonpiedumplings/7e71121b76c58ecaba4176be9bb827c4
With a mere 5 months of not being touched, there are now present CVE’s that are critical on the scoring system (radicles top repo had none yippee! and their second to top repo had a few mediums). It irritates me to see them in software that interacts with networked systems.
I only very rarely find programs that are empty of CVE’s. Usually only the most well resourced, active projects are able to keep their audit clean. It’s a lot of work —
Work that a stable distro automates. With a stable Linux distribution like Debian, 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.
Look, you don’t have to use a stable distro on your own personal Linux desktop. I use Arch on my laptop. But for servers, not using pinned dependencies, and instead linking against libraries provided by distros means saving thousands of hours of toil doing basic cleanup of updating libraries and figuring out what the newer version of libraries broke. With a stable distro, you just do that once every six years.