this post was submitted on 22 Nov 2025
496 points (99.4% liked)

Selfhosted

53155 readers
234 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

Hi guys, I've been working on a self-hostable web analytics platform since the start of this year after being frustrated with Google Analytics and Plausible.

I've packed a bunch of cool web analytics features into Rybbit, but I've tried very hard to keep the interface simple to use,

https://github.com/rybbit-io/rybbit

Check it out!

you are viewing a single comment's thread
view the rest of the comments
[–] partofthevoice@lemmy.zip 1 points 3 days ago (1 children)

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 1 points 3 days ago* (last edited 3 days ago) (2 children)

What you just described cannot be done. You can't verify it, because its not signed.

[–] partofthevoice@lemmy.zip 1 points 3 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: https://github.com/sigstore/cosign

Today, cosign has been tested and works against […] Docker Hub

[–] partofthevoice@lemmy.zip 1 points 3 days ago* (last edited 3 days ago) (1 children)

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 pull is 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.

[–] quick_snail@feddit.nl 1 points 3 days ago (1 children)

Dude, just search the github for "docker content trust" and you can read all the issues. I'm not making big claims that aren't known already by the devs

[–] partofthevoice@lemmy.zip 1 points 3 days ago* (last edited 3 days ago)

Again we’re talking past each other. I’m sure those results are available and I’m aware docker doesn’t verify signatures automatically, but I’m asking how that necessarily makes docker insecure in spite of best practices being implemented. It’s about pinning yourself to trusted digests and having a verification process (like time) before updates. Why would you need authorship verification in that case? If there’s a good answer to that, I’d consider alternatives too. I’m just saying I don’t think it’s inherently insecure over this, and at face value It boils back down to the classic: don’t download untrusted software.