Caddy: Tag v2.2.1 is not signed

[ArisuOngaku]

Tag v2.2.1 is signed with 4AEE18F83AFDEB23 (github's key) while all previous release tags were signed with 2A349DD577D586A5 (Matthew Holt's).

This is a problem for the AUR package caddy2 because we only trust Matthew Holt's key.

However if you believe we can trust updates signed with github's key, we should be able to add it to the trusted keys of this package (less ideal solution).

[francislavoie]

I think that just depends on how the last commit was made on the master branch. If it was a PR that was merged, it would be signed by github, but if it was direct commit by Matt, then it would use his key. For example:

So I would say that yes, that github key is fine to use.

I'm not sure why this came up now though, because many of the previous tagged commits for releases used that key.

[ArisuOngaku]

@francislavoie from what I understand, signed commits are independent of signed tags. Maybe when a tag isn't specifically signed, it falls back to the commit it's attached to? All previous tags are signed with Matthew Holt's key (even when the commit they are attached to are signed by github).

Anyway, doing git tag -v v2.2.1 returns an error, I think it's because the tag itself isn't signed:

error: v2.2.1: cannot verify a non-tag object of type commit.

i.e. git tag -v v2.2.0 works fine:

object f197cec7f3a599ca18807e7b7719ef7666cfdb70
type commit
tag v2.2.0
tagger Matthew Holt <[email protected]> 1600962946 -0600

gpg: Signature made Thu 24 Sep 2020 05:55:46 PM CEST
gpg:                using RSA key 29D0817A67156E4F25DC24782A349DD577D586A5
gpg:                issuer "[email protected]"
gpg: Good signature from "Matthew Holt <[email protected]>" [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: 29D0 817A 6715 6E4F 25DC  2478 2A34 9DD5 77D5 86A5

EDIT: by the way, I double checked that I had the v2.2.1 tag locally and it does appear in git tag --list

[francislavoie]

The difference is probably that @mholt made the tag from GitHub's interface this time rather than doing it from his personal machine.

Only people with the appropriate permissions on the repo can make releases, so I think it's probably fine to trust the GitHub key as well, but I'll let @mholt chime in.

[mholt]

So... we're talking about this, and none of us really know what's going on. I've never seen GitHub-signed commits or tags until today, and it seems a bit presumptuous for GitHub to be signing my commits/tags. I am surprised I did not have to give it explicit permission to sign things... in any case, please do not trust GitHub's key, as I have no idea who else can trigger commits or tags using the same key.

To clarify, I do not use GitHub's UI to create the tags. All signed tags are created on my local machine.

[mholt]

I think before going forward and doing anything to act on this, I want to fully understand what happened. But I am not sure if that will be possible :( As far as I can tell, everything on my end was the same.

I will make it a point to tag a -rc.1 version with the next release and make sure the tag is behaving as expected...

[ArisuOngaku]

@mholt I tried adding the key to the trusted keys of the PKGBUILD, but the same error occurred; SIGNATURE NOT FOUND. While I initially thought it was because of a missing key, I am now convinced that the v2.2.1 tag is simply not signed.

What's confusing is that github displays as if it was signed, when in fact only the commit is signed and not the tag.

[ArisuOngaku]

Correction: github actually displays in the popup menu what is the signed thing, for all tags it's This tag was signed[...] except for the v2.2.1 where it's This commit was signed[...].

My mistake, I should have read that better.

[emlun]

You can also use git show <tag> to see that tag v2.2.0 is signed and v2.2.1 is not.

[mholt]

The new beta release is signed by my key: https://github.com/caddyserver/caddy/releases/tag/v2.3.0-beta.1

I suspect there's a serious bug somewhere in the VS Code git integration but I'll use the command line from now on.