this post was submitted on 24 Feb 2026
100 points (81.2% liked)

Selfhosted

56867 readers
290 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.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

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

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

The Huntarr situation (score 200+ and climbing today) is getting discussed as a Huntarr problem. It's not. It's a structural problem with how we evaluate trust in self-hosted software.

Here's the actual issue:

Docker Hub tells you almost nothing useful about security.

The 'Verified Publisher' badge verifies that the namespace belongs to the organization. That's it. It says nothing about what's in the image, how it was built, or whether the code was reviewed by anyone who knows what a 403 response is.

Tags are mutable pointers. huntarr:latest today is not guaranteed to be huntarr:latest tomorrow. There's no notification when a tag gets repointed. If you're pulling by tag in production (or in your homelab), you're trusting a promise that can be silently broken.

The only actually trustworthy reference is a digest: sha256:.... Immutable, verifiable, auditable. Almost nobody uses them.

The Huntarr case specifically:

Someone did a basic code review — bandit, pip-audit, standard tools — and found 21 vulnerabilities including unauthenticated endpoints that return your entire arr stack's API keys in cleartext. The container runs as root. There's a Zip Slip. The maintainer's response was to ban the reporter.

None of this would have been caught by Docker Hub's trust signals, because Docker Hub's trust signals don't evaluate code. They evaluate namespace ownership.

What would actually help:

  • Pull by digest, not tag. Pin your compose files.
  • Check whether the image is built from a public, auditable Dockerfile. If the build process is opaque, that's a signal.
  • Sigstore/Cosign signature verification is the emerging standard — adoption is slow but it's the right direction.
  • Reproducible builds are the gold standard. Trust nothing, verify everything.

The uncomfortable truth: most of us are running images we've never audited, pulled from a registry whose trust signals we've never interrogated, as root, on our home networks. Huntarr made the news because someone did the work. Most of the time, nobody does.

you are viewing a single comment's thread
view the rest of the comments
[–] SirHaxalot@nord.pub 32 points 9 hours ago (2 children)

I'm like 90% sure that this post is AI Slop, and I just love the irony.

First of all, the writing style reads a lot like AI.. but that is not the biggest problem. None of the mitigations mentioned has anything to do with the Huntarr problem. Sure, they have their uses, but the problem with Huntarr was that it was a vibe coded piece of shit. Using immutable references, image signing or checking the Dockerfile would do fuck-all about the problem that the code itself was missing authentication on some important sensitive API Endpoints.

Also, Huntarr does not appear to be a Verified Publisher at all. Did their status get revoked, or was that a hallucination to begin with?

To be fair though the last paragraph does have a point,, but for a homelab I don't think it's feasible to fully review the source code of everything you install. It would rather come down to being careful with things that are new and doesn't have an established reputation, which is especially a problem in the era of AI coding. Like the rest of the *arr stack is probably much safer because it's open source projects that have been around for a long time and had had a lot of eyes on it.

[–] EncryptKeeper@lemmy.world 1 points 59 minutes ago

The account is 2 days old and this is its only post.

[–] aeluon@programming.dev 4 points 4 hours ago

the post is so obviously AI and OP has not responded to any comments. who is upvoting this?