Identify fingerprint of, and sign, key used to sign packages

[codyshepherd]

It's possible I've missed it somewhere, but I cannot find where you've identified the key used to sign your release tarballs. gpg identifies the signature as having been made by key 1D2D410A741137EBC544826F4A92FA17B6619297, but aside from that key sharing a name with this project, I have no way of knowing whether I should trust it.

Describe the solution you'd like
Identify the key fingerprint in your readme. Better yet, sign/trust your signing key with Orhun's key, 165E0FF7C48C226E1EC363A7F83424824B3E4B90, which is identified on their github profile.

Additional context
Having signatures for your Docker images would be nice as well.

Apologies if you've already put this somewhere and I've missed it!

[orhun]

Hello!

It's possible I've missed it somewhere, but I cannot find where you've identified the key used to sign your release tarballs. gpg identifies the signature as having been made by key 1D2D410A741137EBC544826F4A92FA17B6619297, but aside from that key sharing a name with this project, I have no way of knowing whether I should trust it.

It is actually mentioned in the release script.

Identify the key fingerprint in your readme.

9022af5

Better yet, sign/trust your signing key with Orhun's key, 165E0FF7C48C226E1EC363A7F83424824B3E4B90, which is identified on their github profile.

It is signed with both of my PGP keys that I use for signing commits:

(screenshot from gpg-tui)

Having signatures for your Docker images would be nice as well.

Hmm, can you give me a hand about that? Seeing some examples would really help.

Apologies if you've already put this somewhere and I've missed it!

No worries!

[codyshepherd]

It is actually mentioned in the release script.

Ah, so it is. Thanks for pointing that out.

9022af5

👍 Thanks!

It is signed with both of my PGP keys that I use for signing commits:

Yes it is, sorry for the trouble.

Having signatures for your Docker images would be nice as well.

Hmm, can you give me a hand about that? Seeing some examples would really help.

Creating a detached signature (gpg --armor --detached-sign <tar file>) for the output of docker save ghcr.io/orhun/git-cliff/git-cliff > git-cliff.tarand serving it with your other Release files would allow me todocker pullyour image, thendocker saveit as above, then dogpg --verify `. This is likely the simplest option for enabling verification of the docker image, as I'm not certain if GitHub container registry currently supports Docker Content Trust.

Thanks for your response!

[orhun]

Creating a detached signature (gpg --armor --detached-sign <tar file>) for the output of docker save ghcr.io/orhun/git-cliff/git-cliff > git-cliff.tarand serving it with your other Release files would allow me todocker pullyour image, thendocker saveit as above, then dogpg --verify `. This is likely the simplest option for enabling verification of the docker image, as I'm not certain if GitHub container registry currently supports Docker Content Trust.

I recently switched to build-push-action for building/pushing Docker images (for CI) and realized GHCR shows SHA checksums for the images. e.g:

• https://github.com/orhun/git-cliff/pkgs/container/git-cliff%2Fgit-cliff/8228133?tag=latest

Isn't that enough for verifying the images that have been built in an automated environment?

Either way, I think I can update the CD workflow in the future to upload the "Docker signatures". (Feel free to do it if you're interested 🙂)