pathrs-lite supports transparently switching to libpathrs.so as the
backend with the "libpathrs" build tag. In order to make this work
properly with our CI and release build scripts, we we need to have a
similar setup as with we do with libseccomp.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Because we add the runc-$version/ prefix to the archive we generate,
including the version in the name makes it easier for some tools to
operate on as it matches most other projects (for openSUSE we rename the
archive file to this format in order for the automated RPM scripts to
work properly).
Also, when doing several releases at the same time, being able to
double-check that the correct artefact versions were uploaded for each
release can be quite handy.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
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>
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>
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>
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>
Aleksa Sarai