Dockerfile signing

[jerry-bonner]

Hello,

As far as I can tell the official docker images are not signed. This means these images will fail to download in environments where docker content trust is configured. It would be nice if this was done.

# docker trust inspect pandoc/core
[]
no signatures or cannot access pandoc/core

Pulling docker image pandoc/extra ...
WARNING: Failed to pull image with policy "always": missing signature key
ERROR: Job failed: failed to pull image "pandoc/extra" with specified policies [always]: missing signature key

[daamien]

Hi @jerry-bonner

Can you provide more details about what you expect ? Especially who do you think should sign the pandoc images ?

• The pandoc project developpers ?
• The pandoc copyright holder ?
• The maintainers of this repo ?
• A third party company ?
• The docker.com platform ?

Currently the pandoc community is not represented by a legal entity. The maintainers of the docker images are acting on their own behalf. I'm unsure what meaning our signatures would have for you...

Furthermore like most docker images, the pandoc images aggregate a lot of open source components coming from a lot different sources. Although we're very careful of which components we include and which ones we don't, we provide these images WITHOUT ANY WARRANTY.

Again I'm not sure how our signatures would bring "more trust" about the content of these images. At most, our signatures would give you the certainty that we are not responsible for anything at all 😉

[alerque]

I don't think any of that touches on the main purpose of signing.

Signing generated artifacts makes a lot of sense in a FOSS project, and realistically the more volunteers have the keys to the cupboards the more sense it makes. Signed artifacts just give some level of guarantee that a trusted actor is actually the one building and publishing things, not a bad actor that has gained access through whatever combination of social engineering and hackery it took.

Generating a couple trusted keys and publicly identifying who holds them and who is expected to be able to sign images would greatly reduce the potential surface area for a supply chain attack involving the project. Not to zero of course, just reduced. The point is not to provide a warranty about the software provided, only about who generated the artifacts and some reasonable level of assures that it was an intentional act by that purpose, not some other actor or ever their own system being compromised.

The downside is secret key handling is a PITA. I do it for many purposes including holding authorized package signing keys for Arch Linux.

[daamien]

I understand the point of signing artefacts in general. I am involved in many context where this is done on a daily basis. But for this particular project I really don't think it provides that much trust....

Signing the image gives the guarantee that the images were built by a maintainer of the project. As far as I understand, this prevent an attacker who gained access to this repo from pushing compromised image.

But our attack surface is way larger than that.... Since we rely on multiple supply chains ( texlive, alpine, debian, pip, github, etc... ) , an easier and more pratical attack would be to submit a PR with a dependency to a compromised package from one of theses supply chains. In such case, it would be hard for us to detect it, and there's a risk we would just accept the PR , build the image and sign it.

Hence my question above : what is the user expectation and would be the meaning of our signature for him/her ?

• If that's just « We guarantee that the image was built by a maintainer of the project », I think it may give a false sense of security.

• If that's « We guarantee that that there's no compromised package in this image » , I think users must understand that it's pretty hard to do...

[tarleb]

Just to add my personal position on this: I don't have any interest in implementing this myself, but I don't mind if somebody else provides a PR and a step-by-step guide that let's us set this up in 5 minutes.

Frankly, this is one of those features that are most useful to company users, and I would expect companies to pay for that. So if someone wants to make a side-hustle out of this, please go for it.