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>
A new libseccomp releases (v2.5.6 and v2.6.0) were cut last month.
Theoretically, we could use v2.6.0 but let's stay conservative for now.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
While this is used by the majority of upper container runtimes, it was
not needed for runc itself. Since commit 515f09f7 runc uses overlay,
too, so let's add a check for this.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.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>
It seems that newer podman versions need the kernel comment flag too.
By podman run, iptables using -m comment in the iptables-command to add the corresponding network rules.
Signed-off-by: Christian Happ <Christian.Happ@jumo.net>
Looking at the code, I found out that kernel_lt function was actually
doing le ("less than or equal") rather than lt ("less than") operation.
Let's fix this and do exactly what the name says.
A bigger issue is, the function use was not consistent (some uses
implied "less than or equal").
To fix the usage, find out all relevant kernel commits and kernel
versions that have them (the latter is done using "git describe
--contains $sha"), and fix the wrong cases. While at it, add references
to all these kernel commits for the future generations of
check-config.sh hackers.
Also, add kernel_ge function which is the opposite of kernel_lt,
and document both.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
...when the stdout is not a terminal, and also when NO_COLOR environment
variable is set to any non-empty value (as per no-color.org).
Co-authored-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Kernel commit e55b9f96860f (which made its way into Linux v6.1-rc1)
removes CONFIG_MEMCG_SWAP entirely, so there's no sense to check for in
on newer kernels.
Make the check conditional.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
"armhf" means ARMv7 for Debian, ARMv6 for Raspbian.
ARMv6 is chosen here for compatibility.
https://wiki.debian.org/RaspberryPi
> Raspberry Pi OS builds a single image for all of the Raspberry families,
> so you will get an armhf 32-bit, hard floating-point system, but built
> for the ARMv6 ISA (with VFP2), unlike Debian's ARMv7 ISA (with VFP3)
> port.
Prior to this commit, the script was setting GOARM=6 for armel,
GOARM=7 for armhf.
Fix issue 4033
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
We need these to match the Makefile detection of the right gcc for
runc-dmz, as well as making sure that everything builds properly for our
cross-i386 tests. While we're at it, add x86 to the list of build
targets for release builds (presumably nobody will use it, but since we
do test builds of this anyway it probably won't hurt).
In addition, clean up the handling of the native architecture build by
treating it the same as any other build (ensuring that building runc
from a different platform will work the same way regardless of the
native architecture). In practice, the build works the same way as
before.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
For "make integration", the tests are run inside a Docker/Podman
container. Problem is, if cgroup v2 is used, the in-container
/sys/fs/cgroup/cgroup.subtree_control is empty.
The added script, used as Docker entrypoint, moves the current process
into a sub-cgroup, and then adds all controllers in top-level
cgroup.subtree_control.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
These checks ensure that all of the keys in the runc.keyring list are
actually the keys of the specified user and that the users themselves
are actually maintainers.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.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>
In order to allow any of the maintainers to cut releases for runc,
create a keyring file that distributions can use to verify that releases
are signed by one of the maintainers.
The format matches the gpg-offline format used by openSUSE packaging,
but it can be easily imported with "gpg --import" so any distribution
should be able to handle this keyring format wtihout issues.
Each key includes the GitHub handle of the associated user. There isn't
any way for this information to be automatically verified (outside of
using something like keybase.io) but since all changes of this file need
to be approved by maintainers this is okay for now.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
cgroup v2 requires CONFIG_CGROUP_BPF kernel option to be set
else runc can not start containers.
check-config.sh script checks if the CONFIG_CGROUP_BPF option
is set. The script checks if version of kernel is atleast
4.15 and cgroup v2 is being used before checking if the
CONFIG_CGROUP_BPF option is set.
Closes#3547
Signed-off-by: dharmicksai <dharmicksaik@gmail.com>
Add checking of downloaded tarball checksum.
In case it doesn't match the hardcoded value, the error is like this:
libseccomp-2.5.4.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
In case the checksum for a particular version is not specified in the
script, the error will look like this:
./script/seccomp.sh: line 29: SECCOMP_SHA256[${ver}]: unbound variable
In case the the hardcoded value in the file is of wrong format/length,
we'll get:
sha256sum: 'standard input': no properly formatted SHA256 checksum lines found
In any of these cases, the script aborts (due to set -e).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
One particularly bad one is ${codes[@]} which is fine in bash 4.4+,
but gives "codes[@]: unbound variable" with older bash versions,
such as with bash 4.2 used on CentOS 6. It's good that this is the only
array in the script that can potentially be empty.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
... and add this file to shellcheck target in Makefile.
These:
In script/check-config.sh line 27:
kernelMinor="${kernelVersion#$kernelMajor.}"
^----------^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
Did you mean:
kernelMinor="${kernelVersion#"$kernelMajor".}"
In script/check-config.sh line 103:
source /etc/os-release 2>/dev/null || /bin/true
^-------------^ SC1091 (info): Not following: /etc/os-release was not specified as input (see shellcheck -x).
In script/check-config.sh line 267:
NET_CLS_CGROUP $netprio
^------^ SC2206 (warning): Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Like this one:
In ./script/check-config.sh line 215:
if [ "$kernelMajor" -lt 5 ] || [ "$kernelMajor" -eq 5 -a "$kernelMinor" -le 1 ]; then
^-- SC2166 (warning): Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. Allow wrap_bad and wrap_good to have an optional arguments.
2. Remove unneeded echos; this fixes the shellcheck warnings like
In ./script/check-config.sh line 178:
echo "$(wrap_bad 'cgroup hierarchy' 'nonexistent??')"
^-- SC2005 (style): Useless echo? Instead of 'echo $(cmd)', just use 'cmd'.
3. Fix missing color argument in calls to wrap_color (when printing the
hint about how to install apparmor).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This check was always broken, and it slipped through the cracks because
we never run it without additional architectures now.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
It was released about a month ago. I don't see anything major
in the changelog but it makes sense to keep tracking upstream deps.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.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>
Commit f30244ee1b broke the scenario of using Dockefile for
anything but making a release. This happened because it installed
native libseccomp build to a temporary directory, and so linking against
libseccomp required setting a few environment variables.
Let's fix this, and simplify libseccomp installation. Instead of using
temporary directories, let's install native libseccomp to a specified
directory, all the cross-builds to its subdirectories, and set
PKG_CONFIG_PATH and LD_LIBRARY_PATH in Dockerfile so that the built
library will found by pkg-config and the dynamic linker (without setting
LD_LIBRARY_PATH, ld picks up distro-provided libseccomp.so).
While at it, fix some bugs introduced by the abovementioned commit.
This fixes building runc in make targets like shell, dbuild,
integration, unittest -- i.e. those that depend on runcimage.
Fixes: f30244ee1b
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This implements cross-build for "make release", moving the build into a
container. This way we can support arm, arm64, ppc, and whatnot.
* script/seccomp.sh: separate out of script/release.sh, amend to support
cross-compile and save needed environment variables to a file.
* Dockerfile: add installing libseccomp from source, as this is needed
for release builds.
* script/release.sh: amend to support more architectures in addition to
the native build. Additional arches can be added by specifying
"-a <arch>" argument (can be specified multiple times), or
"make RELEASE_ARGS="-a arm64" release" if called via make.
All supported architectures can be enabled via "make releaseall".
* Makefile: move "release" target to "localrelease", add "release" and
"releaseall" targets to build via the Dockerfile. This is done because
most distros (including Fedora and openSUSE) lack cross-glibc, which is
needed to cross-compile libseccomp.
* Makefile: remove 'cross' and 'localcross' targets, as this is now done
by the release script.
* .github/workflows/validate.yum: amend the release CI job to cross-build
for supported architectures, remove cross job.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
openSUSE comes with site-config package, which makes configure select
${prefix}/lib64 as libdir on x86_64, unless explicitly specified.
Since release.sh relies on a particular libdir path (for pkgconfig), it
breaks things:
> + make -C /home/kir/git/runc PKG_CONFIG_PATH=/tmp/tmp.QgIJ1sR5c9/lib/pkgconfig COMMIT_NO= EXTRA_FLAGS=-a 'EXTRA_LDFLAGS=-w -s -buildid=' static
> make[1]: Entering directory '/home/kir/git/runc'
> CGO_ENABLED=1 go build -trimpath -a -tags "seccomp netgo osusergo" -ldflags "-extldflags -static -X main.gitCommit=v1.0.0-204-g963e0146 -X main.version=1.0.0+dev -w -s -buildid=" -o runc .
> Package libseccomp was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libseccomp.pc'
To fix, we have to explicitly specify libdir.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
What it takes is add an empty buildid, which, together with previously
added strip invocation, results in reproducible build!
NB: earlier versions of this patch also added the following:
1. non-random libseccomp install $prefix;
2. "objcopy --enable-deterministic-archives $prefix/lib/libseccomp.a"
to strip ar dates and UIDs/GIDs;
3. "-B=0x00" to EXTRA_LDFLAGS to have non-variable NT_GNU_BUILD_ID.
Apparently, all this is not needed with strip.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This patch
* drops the default `-w` flag for `make static`, which helps with
debugging the static runc binary;
* adds `EXTRA_LDFLAGS="-w -s"` to `script/release.sh` to disable DWARF
generation and symbol table for the release runc binary;
* adds strip in `script/release.sh` for a further size-optimized release
runc binary.
Signed-off-by: Kailun Qin <kailun.qin@intel.com>
https://golang.org/cmd/go/#hdr-Build_and_test_caching says:
> If you have made changes to the C libraries on your system, you will
> need to clean the cache explicitly or else use the -a build flag
> (see 'go help build') to force rebuilding of packages that depend
> on the updated C libraries.
This means that:
1. We need to either 'go clean -cache' or 'go build -a' when building
the release binary. Adding '-a' seems less intrusive / more focused.
2. The check for existing libseccomp.a (added by commit d748280aa)
is no longer needed.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
libseccomp is LGPL, meaning if we statically link it, we have to include
the source code of the library.
Amend "make release" to download and build libseccomp, build runc
against it, and include its sources into the release directory.
The only caveat is I found no way to stop go build from using the
stock (distro-provided) libseccomp.a, so the script checks that
the stock libseccomp.a is not available, and aborts otherwise.
While at it:
- enable shellcheck for script/release.sh
- remove libseccomp installation from the gha job
- add dependecies needed for libseccomp build to the gha job
[v2: also include libseccomp .asc file]
[v3: rebase]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Apparently, scripts/validate-c is not working in CI (or maybe
maintainers ignored the failures from it) -- current C code
gets some changes if we run indent on it.
This commit fixes this, simplifying things along the way.
In particular:
1. Remove "validate" make target, add "cfmt" target that just runs
indent on all *.c files in the repository (NOTE that *.h files
are not included, as before).
This may help a contributor to fix their code -- they just need
to run "make cfmt" now instead of running "make validate" and
copy-pasting the indent command and options from the hint.
2. Split GHA validate/misc into validate/release and validate/cfmt.
The latter checks that the sources are not changed after "make cfmt".
3. Adds a few more options to indent. This was mostly motivated by
trying to save the existing formatting, minimizing the amount of
changes indent produces.
The new options are:
* -il0: sets the offset for goto labels to 0 (currently all labels
but one are not indented -- let's keep it that way);
* -ppi2: sets the indentation for nested preprocessor directives
to 2 spaces (same as it is done in "SYS_memfd_create" defines);
* -cp1: sets the indentation between #else / #endif and the
following comment to 1 space.
4. Reformat the code using the new indent options.
5. Remove the now-unused script/{.validate,validate-c}.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
