> That also means that unless you build a project on two identical hosts then it is unlikely you will get the same SBOMs.
I don't understand why the author thinks this is such an insurmountable issue.
Reproducible builds are possible with a little care: large parts of Debian are built reproducible. There are tools from https://reproducible-builds.org/
Bazel and similar build systems support reproducible builds, and thus identical SBOMs.
I was referring to things like Maven, WebPack and NPM. I should have made that clearer. What I have seen is in general supply chain in more mature tech and certainly OS tool chains doesn't have that issue or is certainly more aware of it and Bazel is great and all that but dev teams building business apps that are all Devopsy use plug and play and any friction to the velocity is rarely a trade off they even discuss.
Java serialization is passe largely because it has huge gaping holes in how one can abuse the serialization loaders to perform very unsafe security holes. And it's incredibly slow, and tied to JVMs, but sadly only really tied to JVM that have the exact same version and serialized objects, etc.. did I mention java serialization sucks? (Spoken by a true java lover that that subjected himself to serialization way more than he wanted to)
Yeah, kind is a good compromise. It's more than I want and it does take some time to startup, but it's pretty lightweight and very accurate. Because everything is running locally you can use tools like `perf` to keep an eye on things you're running on k8s, right from your usual workstation. I like it a lot.
The CRI plugin sounds like probably the right thing to do. Everything is real up until actually running stuff.
I'm the author of the article. We never suggest turning off GPG and checksum verification.
The bugs may be in APT, but they allow several attack vectors against APT, as explained throughout. Let me know if you have any specific questions and I'd be happy to help clear things up!
Additionally the article appears to intentionally conflate "issues" such as "if you turn security off" or "if the repository isn't signed" to make their list of possible issues look bigger. None of these are "Attacks against GPG signed APT repositories".
APT will not reject it on replay if the 'Valid-Until' date has not been met yet.
Imagine a version of, say, libEXAMPLE has a vulnerability allowing remote code execution. The `Valid-Until` date is some time in the future, maybe a few days from now. The authors release a new version of libEXAMPLE to patch the vulnerability and the APT repository metadata is updated.
However, a malicious actor performing a MitM against your machine has saved the metadata with the vulnerable version. The malicious actor replays that metadata to your system, preventing your system from seeing the newly patched libEXAMPLE. This gives the attacker up until the `Valid-Until` date to attempt to launch an attack against you.
That's an orthogonal feature, it writes output after each line as opposed to every 4096 bytes, when the output is a pipe instead of a terminal. Useful when the other end of the pipe still goes to the terminal and you want to see it immediately. If `some-util-with-output` echoes stdin then without the option the following would not show you the latest grepped lines until the 4096 buffer fills.
tail -F output.log | grep --line-buffered TEXT | some-util-with-output
apt-mark is nothing like masking from gentoo. A-M is just for making modifications to the database that remembers whether a package was intentionally installed or was automatically pulled in as part of a dependency. This database is how apt generates the list of "packages that were automatically installed and no longer needed." The closest thing that I can think of to masking in Debi an is pulling in a package from experimental or a PPA that you added. There are no packages in the repo (stable, testing, unstable) you are using that require anything other than "apt-get install package" to install them.
A-M is the recommended way to hold a package, previously you would use `dpkg --get-selections`. All apt/dpkg commands will abide by what you set with A-M.
I think the car issue is caused by rise of emissions controls. Efficiency and emissions control have been improved by computerizing the car - thats what puts car maintenance out of reach. Its hard for the average person to understand/fix things that we cannot see or touch.
I strongly suspect it's due to more than a single dimension. To name a few:
Emission controls, increased features (e.g. GPS, Seat warmers, lane assist), reduced fuel consumption, increased power, increased safety features, miniaturisation/lightening of components, reduced tolerances, materials specialization.
There are also more contentious but likely contributors, such as vendor lock-in (if you have to come to my dealer network form maintenance, I'm gonna make more money) or planned obsolescence (if you need a new car every X years, I'm gonna make more money).
I don't understand why the author thinks this is such an insurmountable issue.
Reproducible builds are possible with a little care: large parts of Debian are built reproducible. There are tools from https://reproducible-builds.org/
Bazel and similar build systems support reproducible builds, and thus identical SBOMs.