<![CDATA[Should CloudronVersions.json have a digital signature?]]>I recently experimented with the CloudronVersions.json file and the community app store. It's quite convenient: add the URL to the JSON file at installation, and the app gets the same automatic backups and updates as official apps.

To be clear — these are third-party apps, use at your own risk, and anyone installing one should review it beforehand (I know most won't in practice).

That said, there's a security gap worth discussing:

Package repositories typically sign their manifests to prevent tampering — if someone modifies a package after the maintainer publishes it, the signature breaks and clients refuse to install it.

CloudronVersions.json has no such signature. This means:

  1. A maintainer uploads a legitimate manifest.
  2. A third party (or a compromised host) modifies the JSON file after the fact.
  3. Users downloading the app get a potentially compromised version — with no warning.

Automatic updates make this worse: once you trust a URL, every future update is pulled from that same unverified source.

I already raised this with the Cloudron team directly. Their position is that since this is a third-party feature, adding signatures is out of scope for them. I understand the reasoning, but I wanted to bring it to the community to get a sense of whether others share this concern.

]]>https://forum.cloudron.io/topic/15763/should-cloudronversions.json-have-a-digital-signatureRSS for NodeMon, 24 Aug 2026 03:34:49 GMTFri, 31 Jul 2026 16:08:50 GMT60<![CDATA[Reply to Should CloudronVersions.json have a digital signature? on Wed, 05 Aug 2026 14:02:05 GMT]]>@fbartels I think the idea of moving more towards security is good. There is still much more to discover and implement there. 🙂

]]>https://forum.cloudron.io/post/127758https://forum.cloudron.io/post/127758Wed, 05 Aug 2026 14:02:05 GMT<![CDATA[Reply to Should CloudronVersions.json have a digital signature? on Sat, 01 Aug 2026 10:55:45 GMT]]>

@girish said:

The main issue is/was signing docker images

@girish

True, tags are mutable, so pulling by tag alone leaves you vulnerable if a registry is compromised.

Container signing verifies provenance (who built it), while referencing an image by digest (image@sha256:...) guarantees integrity (that it hasn't been altered). If the Cloudron app manifest explicitly pins container digests, you effectively get both: Cloudron verifies the authenticity of the app manifest, and the digest ensures the container pulled from the registry hasn't been tampered with.

As a quick note on mirroring: docker tag & push actually preserves digests in most OCI registries, but using tools like crane copy or skopeo is definitely the right approach since they transfer images directly between registries without local daemon overhead or pulling down heavy layers.

Regarding experience with container signing: the modern standard is Cosign (part of Sigstore). Because Cosign stores signatures as standard OCI artifacts inside the registry, it works out-of-the-box with almost every modern registry today (Docker Hub, GHCR, Harbor, AWS ECR, etc.) without requiring special server-side setup.

]]>https://forum.cloudron.io/post/127582https://forum.cloudron.io/post/127582Sat, 01 Aug 2026 10:55:45 GMT<![CDATA[Reply to Should CloudronVersions.json have a digital signature? on Sat, 01 Aug 2026 10:00:54 GMT]]>Thanks for bringing this up here @fbartels (and also for the other security issues you reported in private!).

Just some technical notes here, since I researched this after @fbartels sent us the initial report.

@robi said:

Do official packages have checks?

We don't have signing for App store packages, instead we rely on the fact that only we (Cloudron team) have access to the app store and the docker hub. For Cloudron platform releases, we use PGP and the server will only accept releases that was signed with the release key.

The main issue is/was signing docker images. Even if the manifest (or the versions) file were signed, the registry that holds the images can be compromised. Docker registry being external is a bigger security concern (add to it that tags are mutable in docker images usually). Unfortunately, docker has deprecated DCT but there is an alternative called code sign. Does anyone have experience with this? https://octopus.com/blog/securing-containers-oidc has a tutorial. I have no idea in which registries that tool works.

]]>https://forum.cloudron.io/post/127579https://forum.cloudron.io/post/127579Sat, 01 Aug 2026 10:00:54 GMT<![CDATA[Reply to Should CloudronVersions.json have a digital signature? on Sat, 01 Aug 2026 08:26:23 GMT]]>

@timconsidine said:

Reputation of packager and security of a particular CloudronVersions.json are different issues.

Yes, exactly this. Since everything is isolated on cloudron the damage is mostly in the compromised app itself. But it is a valid scenario.

@robi said:

Does it need solving? Or is the stepping stone from CA to Official App enough?

Not all custom apps may want to be listed in the official store. I do see the possibility of private app stores with pay walled apps. @luckow posted such a store a while ago.

]]>https://forum.cloudron.io/post/127577https://forum.cloudron.io/post/127577Sat, 01 Aug 2026 08:26:23 GMT<![CDATA[Reply to Should CloudronVersions.json have a digital signature? on Sat, 01 Aug 2026 03:53:37 GMT]]>Does it need solving? Or is the stepping stone from CA to Official App enough?

Do official packages have checks? Or is an external scanner enough to check if file provenance changed from the initial versions and alert?

]]>https://forum.cloudron.io/post/127570https://forum.cloudron.io/post/127570Sat, 01 Aug 2026 03:53:37 GMT<![CDATA[Reply to Should CloudronVersions.json have a digital signature? on Fri, 31 Jul 2026 23:09:12 GMT]]>Reputation of packager and security of a particular CloudronVersions.json are different issues.
Especially when the packager has good reputation and track-record like @fbartels. Maybe even makes his packages more of a target.
If one of his CloudronVersions.json was somehow tampered with, regular Cloudron users could be tricked into installing some deficient or malware app.

So, yes, there is a gap. Small maybe, but not something to take risks over in this day & age.

How we solve this, I'm not sure.
shasum in README ?

]]>https://forum.cloudron.io/post/127569https://forum.cloudron.io/post/127569Fri, 31 Jul 2026 23:09:12 GMT<![CDATA[Reply to Should CloudronVersions.json have a digital signature? on Fri, 31 Jul 2026 22:56:01 GMT]]>@fbartels @jdaviescoates both good ideas 👍

Don't think anything can be out of scope when published under the cloudron.io business domain.

]]>https://forum.cloudron.io/post/127568https://forum.cloudron.io/post/127568Fri, 31 Jul 2026 22:56:01 GMT<![CDATA[Reply to Should CloudronVersions.json have a digital signature? on Fri, 31 Jul 2026 22:02:46 GMT]]>@fbartels I think the more that can be done to help users do a bit of due diligence on community apps the better, hence why I'd at least like links to the packagers profile on here, see https://forum.cloudron.io/post/126905

I like your suggestions, and really I'd like all/most of the stats shown on profile pages on here to be pulled through to the community app store

db3f385b-d1dd-443a-9219-6a392e4d11e2-image.jpeg

From that I can see you've been using Cloudron for years, have packaged official Cloudron apps etc. Such things would make me much more likely to trust community app packaged by you 🙂

]]>https://forum.cloudron.io/post/127567https://forum.cloudron.io/post/127567Fri, 31 Jul 2026 22:02:46 GMT