Release announcements with SHA-IDs?

[Jörg Sommer]

Hi,

would it be possible to include in the next announcement e-mail the SHA IDs
of the git tag and the container?

And would it be possible sometime to sign the announcements with PGP or
S/MIME?

Regards, Jörg

--
Navimatix GmbH T: 03641 - 327 99 0
Tatzendpromenade 2 F: 03641 - 526 306
07745 Jena www.navimatix.de

Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480

[Jan Kiszka]

On 14.05.24 12:32, 'Jörg Sommer' via kas-devel wrote:
> Hi,
>
> would it be possible to include in the next announcement e-mail the SHA IDs
> of the git tag and the container?
>
> And would it be possible sometime to sign the announcements with PGP or
> S/MIME?

I'll look into that. I was already considering to include the container
SHAs as well, just laziness prevented that so far.

Note, though, that the release tags are already signed.

Jan

--
Siemens AG, Technology
Linux Expert Center

[Jörg Sommer]

Jan Kiszka schrieb am Di 14. Mai, 15:29 (+0200):

> On 14.05.24 12:32, 'Jörg Sommer' via kas-devel wrote:
> > Hi,
> >
> > would it be possible to include in the next announcement e-mail the SHA IDs
> > of the git tag and the container?
> >
> > And would it be possible sometime to sign the announcements with PGP or
> > S/MIME?
>
> I'll look into that. I was already considering to include the container
> SHAs as well, just laziness prevented that so far.
>
> Note, though, that the release tags are already signed.

Where can I find this key? Would it be possible to publish it via WKD?

```
% gpg --auto-key-locate wkd,dane,cert,pka,keyserver --locate-keys jan.k...@siemens.com
gpg: error retrieving 'jan.k...@siemens.com' via WKD: No data
gpg: error retrieving 'jan.k...@siemens.com' via DANE: No name
gpg: error retrieving 'jan.k...@siemens.com' via DNS CERT: No name
gpg: error retrieving 'jan.k...@siemens.com' via PKA: No name
gpg: error retrieving 'jan.k...@siemens.com' via keyserver: No data
```

[Jan Kiszka]

I published that key long ago, didn't remember on which servers back
than. It's on my to-do list anyway to refresh this key (will do before
the next release). But the old one should nevertheless be retrievable now.

[Jörg Sommer]

Jan Kiszka schrieb am Fr 17. Mai, 11:26 (+0200):

It works:

```
% gpg --auto-key-locate wkd,dane,cert,pka,keyserver --locate-keys jan.k...@siemens.com

gpg: WARNING: unacceptable HTTP redirect from server was cleaned up

gpg: error retrieving 'jan.k...@siemens.com' via WKD: No data
gpg: error retrieving 'jan.k...@siemens.com' via DANE: No name
gpg: error retrieving 'jan.k...@siemens.com' via DNS CERT: No name
gpg: error retrieving 'jan.k...@siemens.com' via PKA: No name

gpg: key 8AD4AC6F7AE5E714: public key "Jan Kiszka <jan.k...@web.de>" imported
gpg: Total number processed: 1
gpg: imported: 1
pub dsa1024 2009-09-19 [SCA]
CA5F8C00F5FBC85466016C808AD4AC6F7AE5E714
uid [ unknown] Jan Kiszka <jan.k...@web.de>
uid [ unknown] Jan Kiszka <jan.k...@siemens.com>
sub elg2048 2009-09-19 [E]
% g verify-tag 4.3.2
gpg: Signature made Di 09 Apr 2024 19:25:46 CEST
gpg: using DSA key CA5F8C00F5FBC85466016C808AD4AC6F7AE5E714
gpg: issuer "jan.k...@siemens.com"
gpg: Good signature from "Jan Kiszka <jan.k...@web.de>" [unknown]
gpg: aka "Jan Kiszka <jan.k...@siemens.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: CA5F 8C00 F5FB C854 6601 6C80 8AD4 AC6F 7AE5 E714
```

[MOESSBAUER, Felix]

As we are at it: With the recent additions to our CI build, we now also
provide signed attestations for the container images (using the
sigstore bundle format [1], OIDC workflow against GH as identity
provider). These attest the container digests and can currently be
verified with the gh CLI tool or in the GH web-ui [2]. Unfortunately
you cannot verify with cosign, as this tool does not yet support the
bundle spec.

Further, the containers can be reproduced by either:

- forking kas and executing the GH actions CI on the fork (this
reproduces everything, including the exact index manifest)
- running the scripts/reproduce-container.sh script. This reproduces
the sum of all layers (image id), which is everything except for the
container metadata. If you don't trust the github actions CI runners,
this is the check to perform.

*** Stop reading here, if you don't want to go down the container repro
rabbit hole.***

The digest of a container tag is determined by the checksum of the
manifest the tag points to. When fetching a container, docker (or
podman) stores the digest along with the image id (basically everything
except for the metadata), but the tool does NOT store the manifest
itself. When now rebuilding the image locally, you recreate the same
image id (all layers are bit-identical). When now running a docker
image ls there are two cases:

1. You already downloaded the upstream kas container: Docker now checks
the image id and as this matches the id of the upstream digest (a local
table lookup), it also associates it with that digest. In this case, it
"looks like" you fully reproduced everything including the metadata,
while you actually only reproduced the image id (content).

2. No local upstream image: In this case, docker creates a manifest for
the locally build image. As this misses some metadata, it also results
in a different digest. When now fetching the upstream kas container,
you will see two different digests (the downloaded and the locally
rebuilt), but both have the same image id.

[1] https://github.com/sigstore/cosign/blob/main/specs/BUNDLE_SPEC.md
[2] https://github.com/siemens/kas/attestations/855553

Felix