Comment on Rybbit - Open source Google Analytics replacement
partofthevoice@lemmy.zip 2 days agoWhat are you talking about, “yeah that’s the insecurity I’m talking about.”
I didn’t mention an insecurity and neither have you. Would you mind being a little more clear than “Docker pull is insecure?”
Frankly, I was expressing confidence in dockers security. It goes without saying though, any user can do insecure things like download from untrusted sources. That’s not dockers problem though, it’s the users.
quick_snail@feddit.nl 2 days ago
Checksums are not for security. You need signatures. I’m not making claims that aren’t clearly documented.
partofthevoice@lemmy.zip 2 days ago
You’re talking about authorship. Sure. But if you verify the container yourself as secure and pin the digest, what’s the issue?
quick_snail@feddit.nl 2 days ago
What you just described cannot be done.
partofthevoice@lemmy.zip 2 days ago
I was curious and, yeah, it seems like docker hub not requiring signature means many popular publishers don’t bother to sign. But that’s not to say it can’t be done. For example: github.com/sigstore/cosign
partofthevoice@lemmy.zip 2 days ago
You’re making big claims on security here, like “cannot be done,” and each time you do I feel like we’re talking past each other a bit. I never claimed you can verify that the person who pushed the container had access to a private key file. I claimed you can verify the security of a container, specifically by auditing it and reviewing the publisher’s online presence. Best practices. Don’t upgrade right away, and pin digests to those which can be trusted.
When you pin a digest, you’re not going to get a container some malicious agent force pushed after the fact. You pinned the download to an immutable digest, so hot-swapping the container is out the window. What, as I understand, you’re concerned with is the scenario that a malicious actor (1) compromised the registry login beforehand, (2) you pinned the digest after hand, and (3) the attack is unnoticed by you and everyone else.
I’m trying to figure out under what conditions this would actually occur, and thus justifies the claim that
docker pullis insecure. In a work setting, I only see this being an issue if the process to test/upgrade existing ones is already an insecure process.Can you help me understand why I should believe that, even with best practices in place, Dockers own insecurities are unacceptable? Docker is used everywhere and I’m reluctant to believe everyone just doesn’t care about an unmanageable attack vector.