Airsonic: pgp signing key changed?

[anarcat]

Problem description

I'm maintaining a Docker image for airsonic. As part of that build process, I verify the OpenPGP signatures on the Airsonic releases. I had hardcoded this key as it was the one I found when I first built the Docker image:

pub   rsa2048/0A3F5E91F8364EDF 2012-10-25 [SC] [expire : 2021-09-02]
      F7E5D48CF5F4061684A626200A3F5E91F8364EDF
uid                [ inconnue] Andrew DeMaria (Work) <[email protected]>
uid                [ inconnue] Andrew DeMaria (Work) <[email protected]>
uid                [ inconnue] Andrew DeMaria (Colorado Hacker) <[email protected]>
sub   rsa2048/5D4AD7A7212ECF1E 2012-10-25 [E] [expire : 2021-09-02]

But now the build fails because the releases are signed with a different key:

gpgv: Signature made Wed 15 Apr 2020 06:28:26 PM UTC
gpgv:                using RSA key 262121A22A609283A6A46BCB7DEEDDBFC5A13AB4
gpgv: Can't check signature: No public key

That key seems to be:

pub   rsa4096/7DEEDDBFC5A13AB4 2019-10-22 [SC] [expire : 2021-10-21]
      262121A22A609283A6A46BCB7DEEDDBFC5A13AB4
uid                [ inconnue] François-Xavier Thomas (Git signing key) <[email protected]>
sub   rsa4096/1FB34C30957E9A4F 2019-10-22 [E] [expire : 2021-10-21]

It has no trust path to the previous key (ie. the previous key hasn't signed the new one) so I have no way to verify that signature is valid.

I see the signing key had expired last year (#1257), but this is a different problem: the release is just signed by a totally new key.

Steps to reproduce

$ curl -sSL https://github.com/airsonic/airsonic/releases/download/v10.6.0/artifacts-checksums.sha.asc | gpg --verify
gpg: Signature made Wed Apr 15 14:28:26 2020 EDT
gpg:                using RSA key 262121A22A609283A6A46BCB7DEEDDBFC5A13AB4
gpg: Good signature from "François-Xavier Thomas (Git signing key) <[email protected]>" [unknown]
gpg: [email protected]: Verified 1 signature in the past
     11 seconds.  Encrypted 0 messages.
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: 2621 21A2 2A60 9283 A6A4  6BCB 7DEE DDBF C5A1 3AB4

I understand the release was made by a different maintainer this time, but it would be nice to keep some consistency here.

[fxthomas]

Good point, I didn't realize this could be an issue. @muff1nman, could you help?

[muff1nman]

I think this is working as designed. I did not author the release, @fxthomas did which means that consumers now need to trust his key. I suppose the one thing we can do differently is add @fxthomas key (or in general any maintainers that plan to do releases) to https://github.com/airsonic/airsonic-docs/blob/c345b2b6e96e9bb8bf131e1d2f5c1deb4454997b/install/inc.download.md. We could maybe simplify this a bit by making a file of maintainer public keys that can be imported in one shot by gpg.

The alternative here is to setup a single signing key and integrate that with a travis/github actions/etc release pipeline but that has other work todo before that can happen. It also has slightly different semantics as it means you are now trusting a release pipeline's key stored on some public cloud.

[anarcat]

thanks for the update @muff1nman ! I was also hoping for something like this. at least the docs would need to be updated and the changelog would have mentioned the key change. ideally, there would be some sort of a cryptographic trust path between the releases as well.

i would also recommend shipping the openpgp public keys "inline": post them on the website or in the source code, do not rely on the keyserver network as a trusted third party: it definitely isn't. github, for example, might be a good place to leverage trust as we can have some reasonable hope that the "HTTPS" trust chain somewhat works, at least for "TOFU" (trust on first use).

[randomnicode]

It also has slightly different semantics as it means you are now trusting a release pipeline's key stored on some public cloud.

If you're going to do any kind of automated release, then you'll have to have a private key on a public cloud somewhere. The build system isn't going to fetch your private keys from your local system every time it does a build release. This kind of hand rolling releases only works if someone builds a whole release on their local machine and manually does a release.

i would also recommend shipping the openpgp public keys "inline": post them on the website or in the source code, do not rely on the keyserver network as a trusted third party

I agree with this. airsonic-advanced posts the public key within the repo for signature verification.

[fxthomas]

So, to summarize:

• [x] As a short term measure, I'll commit our release keys to a directory on the repo.
• [ ] Is it possible to update the signature without touching the key so that @muff1nman's key signs mine? If so I think it's a good idea to do that too.
• [x] We need documentation on the key signing process, I'll add that.

I think another maintainer wants to work on the build automation, and I would rather leave that to him for the time being.