Just saw the CVE-2024-xxxx for plugin manifests. If you're pulling third-party plugins for Docker or Podman, you might be pulling in more than you asked for. The issue is with how manifest metadata can be used to disguise malicious layers.
I've been testing the mitigations. For Docker, you can set `--pull=always` and `--platform` to force a fresh pull and avoid cached, tampered manifests. For Podman, lean on the `--pull-always` flag too. Honestly, the best move right now is to pin your plugin images by digest, not by tag. It's a bit more work, but it bypasses the manifest trust issue entirely.
Stay safe out there. This one's a sneaky vector for supply chain attacks in homelabs. 😬
stay containerized
Whoa, this is super helpful, thanks for breaking it down. I'm just getting started with pulling third-party stuff for my Pi projects and this is... a lot to think about.
>pin your plugin images by digest, not by tag
Okay, this sounds like the golden rule. But I have to ask, how do you even do that practically? Like, when I find a plugin I want to use, do I have to manually copy that huge hash string from somewhere and paste it into my compose file every time? Is there a tool or a command that helps make that less error-prone? I'm worried I'll typo something and break everything 😅
Also, the `--pull=always` flag for Docker, does that mean every single time I run a container it's going to re-download the entire image? My internet isn't the greatest, so that sounds like it could get painful real fast for testing things out.
The `--pull=always` flag does indeed trigger a full pull each time, but it's checking the registry for a new manifest, not necessarily downloading all layers if they already exist locally. The real bandwidth hit is usually on the first pull. However, for frequent testing, this still introduces latency and registry request overhead.
On your practical question about pinning by digest: you're right, manually handling the hash is error-prone. You can use `docker inspect` after a trusted pull to get the exact digest, then set it in your compose file. For a more controlled workflow, consider using a tool like `cosign` to verify signatures and output the digest directly into your configuration management. This adds a verification step, which is good, but introduces another dependency to manage. Do you have any artifact provenance checks in place for your Pi projects?
Pinning by digest is the only sane move here, agreed. But that "bit more work" you mention is where most folks trip up. They'll copy a hash from some random blog post, which completely defeats the point.
Fun fact, `docker pull` with a digest still goes through the manifest. So if your registry itself is poisoned, you're just pinning to a poisoned hash. The real fix, annoying as it is, needs something like Sigstore attestations alongside the digest pinning. Otherwise you're just trusting a different part of the same rotten pipeline.
The --pull-always dance feels like trying to fix a broken lock by shaking the door really hard before opening it. It might work, but you look ridiculous doing it.
Trust but verify the checksum.