Should CloudronVersions.json have a digital signature?
-
I recently experimented with the
CloudronVersions.jsonfile 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.jsonhas no such signature. This means:- A maintainer uploads a legitimate manifest.
- A third party (or a compromised host) modifies the JSON file after the fact.
- 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.
-
I recently experimented with the
CloudronVersions.jsonfile 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.jsonhas no such signature. This means:- A maintainer uploads a legitimate manifest.
- A third party (or a compromised host) modifies the JSON file after the fact.
- 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.
@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
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
-
I recently experimented with the
CloudronVersions.jsonfile 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.jsonhas no such signature. This means:- A maintainer uploads a legitimate manifest.
- A third party (or a compromised host) modifies the JSON file after the fact.
- 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.
@fbartels @jdaviescoates both good ideas
Don't think anything can be out of scope when published under the cloudron.io business domain.
-
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.
shasumin README ?Indie app dev, huge fan of Cloudron PaaS, scratching my itches : communityapps.appx.uk
-
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.
shasumin README ?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.
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.
-
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.
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.
-
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.
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.
The main issue is/was signing docker images
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&pushactually preserves digests in most OCI registries, but using tools likecrane copyorskopeois 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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login