implement gpg/signapi verification

[cgwalters]

An important part of doing this is retaining support for GPG signing.

I think the best way might be for the API to accept something that looks like an ostree remote config, except minus url.

Also we need to enhance the core ostree C API to support verifying a commit in memory. It looks like right now we'd need to add a temporary repo as a remote, and pull the commit to that to verify...eww.

[cgwalters]

This will depend on ostreedev/ostree#2340

[cgwalters]

This is needed to fix coreos/fedora-coreos-tracker#909

[cgwalters]

@lucab is arguing that we should convert commitmeta into a new layer instead of modifying the first layer.

[cgwalters]

Actually this is about both halves; we need to support injecting it, and we need to verify it if configured.

Let's actually focus on the injection half first.

Also re container images and signing, https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md

[lucab]

From an out-of-band chat: I know ostree has much flexibility and my understanding/knowledge is likely a bit blurry.
What I'd advocate for is not using all its flexibility upfront, especially around the "importing signatures before transporting" part.

As a developer, I'd prefer a model where signatures are transported in a detached way, and only re-glued together at the consuming/importing side (after verification).
In the container world, that would possibly mean having a pristine content layer without any kind of signatures, and a separate metadata layer (or entry in an parent manifest).

All of this from a very high-level point of view, where I don't know if there are technical issue making this a bad idea.

[cgwalters]

Previous to a team discussion I'd been envisioning this converting this tarball stream:

[commit object][metadata and content objects]

to:

[commit object][commit metadata file][metadata and content objects]

i.e. we mutate the tarball stream. This would be quite natural for us to parse and handle. It's also mean that the commit object appears in the tar stream and can at least be inspected via e.g. podman run .... (Hmm, ideally e.g. ostree show Just Works inside this container image, which mayh not be the case today)

In the container world, that would possibly mean having a pristine content layer without any kind of signatures, and a separate metadata layer (or entry in an parent manifest).

So...yes, this is possible. And I do see an advantage here in not modifying the layer tarball.

However, a problem then becomes how much we try to align with e.g. https://github.com/containers/image/blob/a5061e5a5f00333ea3a92e7103effd11c6e2f51d/docs/containers-signature.5.md#json-data-format
On one hand, it's confusing to do so because this is not a signature of the layer, just of a subset of it. On the other as you say it is more "container like" to do so.