Sign the docker images

[EmanuelLoos]

Your docker images are currently distributed via Docker Hub and you intend to switch to ghcr.io. Neither of these platforms are operated by you. Typically, when software is distributed by third parties or through an insecure channel, it is signed by the developers and the integrity of the software is checked against a widely known public key obtained directly from the developers via a different, secure channel. Being familiar with Debian-based GNU-Linux systems and their package management where software is always signed and the signatures are always checked by default, I was actually quite shocked when docker trust inspect nextcloud/all-in-one returned no signatures or cannot access nextcloud/all-in-one. I was seriously considering filing this as a security vulnerability. Yes, I know that Debian packages are distributed by mirrors and mostly over http while Docker Hub and ghcr.io are big operators with a ton of servers in many different locations and they are of course only using HTTPS but that is not nearly enough to blindly trust them. These servers are a central point of failure. If one of them has a security vulnerability this can be exploited to compromise many Nextcloud installations across the globe. Also, a secret service could just order these huge providers to distribute compromised versions of the software to specific targets without anyone noticing at all. If Nextclud seeks to strengthen the "digital sovereignty" of its users, the development and software distribution procedures should become more digitally sovereign first, because they are the foundation.

[szaimen]

Hi, this indeed should have been reported to https://hackerone.com/nextcloud.

Actually, you are the first one that reports this issue. This is why we don't have them signed yet.

As you said, it will get better with moving the containers to ghcr.io which I will work on next week.
I will then also look into signing the docker images.
Inspiration: docjyJ/aio-helloworld@b435f58

[szaimen]

@docjyJ would you be able to help with this task? :)

[docjyJ]

The docker trust command has been removed in recent versions of Docker, so I do not have access to this command.
See: https://www.docker.com/blog/retiring-docker-content-trust/

If you have an older version, could you test the command docker trust inspect ghcr.io/docjyj/aio-helloworld?

However, it appears that actions/attest-build-provenance resolves the issue and seems to work on Docker Hub as well.

I may be able to look at it tomorrow and do a PR.

[szaimen]

I see. Thanks for the reply! So I guess we should not start implementing a deprecated technology. I suppose as recommended in the blog posty we should either use https://www.sigstore.dev/ or https://github.com/notaryproject/notation#readme going forward...

[szaimen]

So if I read this correctly to verify the integrity of the image you've signed, you need to have the tools (cosign or notation) also locally installed which makes this very cumbersoms to use at it does not simply work with any docker installation out of the box...

• https://docs.sigstore.dev/cosign/signing/signing_with_containers/
• https://notaryproject.dev/docs/quickstart-guides/quickstart-sign-image-artifact/#verify-the-container-image

[docjyJ]

I see. Thanks for the reply! So I guess we should not start implementing a deprecated technology. I suppose as recommended in the blog posty we should either use https://www.sigstore.dev/ or https://github.com/notaryproject/notation#readme going forward...

actions/attest-build-provenance is not deprecated, it uses Sigstore.

So if I read this correctly to verify the integrity of the image you've signed, you need to have the tools (cosign or notation) also locally installed which makes this very cumbersoms to use at it does not simply work with any docker installation out of the box...

That's what I understand.