Commit Graph

5 Commits

Author SHA1 Message Date
Aleksa Sarai
26cfe14231 release: explicitly set --keyserver in release signing scripts
On my machine, the --recv-keys steps to get upstream keys started
producing errors recently, and even setting a default keyserver in the
global gpg configuration doesn't seem to help:

  + gpg --homedir=/tmp/runc-sign-tmpkeyring.qm0IP6
        --no-default-keyring --keyring=seccomp.keyring
        --recv-keys 0x47A68FCE37C7D7024FD65E11356CE62C2B524099
  gpg: keybox '/tmp/runc-sign-tmpkeyring.qm0IP6/seccomp.keyring' created
  gpg: keyserver receive failed: No keyserver available

So just explicitly specify a reputable keyserver. Ideally we would use
an .onion-address keyserver to avoid potential targeted attacks but not
everybody runs a Tor proxy on their machine.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
2025-02-13 14:42:24 +11:00
Kir Kolyshkin
760105ab11 script/*: fix gpg usage wrt keyboxd
I used script/keyring_validate.sh, which gave me this error:

> [*] User cyphar in runc.keyring is not a maintainer!

Apparently, when gnupg 2.4.1+ sees a fresh install (i.e. no ~/.gnupg
directory), it configures itself to use keyboxd instead of keyring
files, and when just silently ignores options like --keyring and
--no-default-keyring, working with keyboxd all the time.

The only way I found to make it not use keyboxd is to set --homedir.
Let's do that when we explicitly want a separate keyring.

Similar change is made to script/release_key.sh.

Also, change "--import --import-options=show-only" to "--show-keys"
which is a shortcut. When using this, there is no need to protect
the default keyring since this command does not read or modify it.

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
2024-06-05 17:05:05 -07:00
Aleksa Sarai
957bccfe2f scripts: release: add verification checks for signing keys
We need to make sure the release is being signed by a key that is
actually listed as a trusted signing key, and we also need to ask the
person cutting the release whether the list of trusted keys is
acceptable.

Also add some verification checks after a release is signed to make sure
everything was signed with the correct keys.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
2023-04-19 13:48:14 +10:00
Kir Kolyshkin
457ca62f1f script/release_*.sh: fix usage
- release_build: fix -H <hash_cmd> option (was -h)
- release_sign: add -H and -S options

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
2021-12-09 00:59:43 -08:00
Aleksa Sarai
acd8f12f24 release: correctly handle binary signing for "make releaseall"
My GPG keys are not available inside the container, so it makes little
sense to try to sign the binaries inside the container's release.sh. The
solution is to split things into separate build and sign stages, with
signing ocurring after the in-Docker build.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
2021-12-07 18:10:34 +11:00