Colin Walters [Thu, 26 Aug 2021 16:47:00 +0000 (12:47 -0400)]
tests/basic: Skip --no-xattrs if we have selinux
It cannot work to use `--no-xattrs` when SELinux is enabled
because we get a `security.selinux` attribute on created files
regardless. So just skip this test if true.
Also add some `ostree fsck`s in here which helped me debug
this.
Colin Walters [Mon, 12 Apr 2021 22:42:05 +0000 (18:42 -0400)]
Add an API to verify a commit signature explicitly
We have a bunch of APIs to do GPG verification of a commit,
but that doesn't generalize to signapi. Further, they
require the caller to check the signature status explicitly
which seems like a trap.
This much higher level API works with both GPG and signapi.
The intention is to use this in things that are doing "external
pulls" like the ostree-ext tar import support. There we will
get the commitmeta from the tarball and we want to verify it
at the same time we import the commit.
Colin Walters [Thu, 26 Aug 2021 13:53:56 +0000 (09:53 -0400)]
ci: Run main GH action CI build+test as non-root
This is really the standard best practice, matching how
e.g. dpkg/rpm work, as well as most local development
environments (including mine) with e.g. `toolbox`.
Luca BRUNO [Wed, 25 Aug 2021 12:30:21 +0000 (12:30 +0000)]
lib: improve transactions auto-cleanup logic
This fixes some aspects of OstreeRepoAutoTransaction and re-aligns
it with the logic in flatpak. Specifically:
* link to the underlying repo through refcounting
* bridge internal errors to warning messages
* verify the input pointer type
This is a preparation step before exposing this logic as a public API.
Simon McVittie [Mon, 26 Jul 2021 10:48:45 +0000 (11:48 +0100)]
tests: Unset SOURCE_DATE_EPOCH
Some distributions set this during build in order to have reproducible
builds from the same source code: for example, Debian uses the date
from debian/changelog.
However, some of our tests assume that `ostree commit` will result in
a commit with the current date/time, and SOURCE_DATE_EPOCH breaks that
assumption. Unset it for our build-time tests.
Resolves: https://github.com/ostreedev/ostree/issues/2405 Signed-off-by: Simon McVittie <smcv@collabora.com>
Dan Nicholson [Tue, 27 Aug 2019 16:28:10 +0000 (10:28 -0600)]
libotutil: Add helper for GPG WKD update URLs
Calculate the advanced and direct update URLs for the key discovery
portion[1] of the OpenPGP Web Key Directory specification, and include
the URLs in the key listing in ostree_repo_remote_get_gpg_keys(). These
URLs can be used to locate updated GPG keys for the remote.
Dan Nicholson [Mon, 26 Aug 2019 16:09:57 +0000 (10:09 -0600)]
libotutil: Import implementation of zbase32 encoding
This will be used to implement the PGP Web Key Directory (WKD) URL
generation. This is a slightly cleaned up implementation[1] taken from
the zbase32 author's original implementation[2]. It provides a single
zbase32_encode API to convert a set of bytes to the zbase32 encoding.
I believe this should be acceptable for inclusion in ostree. The license
in the source files is BSD style while the original repo LICENSE file
claims the Creative Commons CC0 1.0 Universal license, which is public
domain.
Dan Nicholson [Tue, 13 Aug 2019 16:10:50 +0000 (10:10 -0600)]
bin/remote: Add list-gpg-keys subcommand
This provides a wrapper for the `ostree_repo_remote_get_gpg_keys`
function to show the GPG keys associated with a remote. This is
particularly useful for validating that GPG key updates have been
applied. Tests are added, which checks the
`ostree_repo_remote_get_gpg_keys` API by extension.
Dan Nicholson [Tue, 13 Aug 2019 19:36:00 +0000 (13:36 -0600)]
lib/repo: Add ostree_repo_remote_get_gpg_keys()
This function enumerates the trusted GPG keys for a remote and returns
an array of `GVariant`s describing them. This is useful to see which
keys are collected by ostree for a particular remote. The same
information can be gathered with `gpg`. However, since ostree allows
multiple keyring locations, that's only really useful if you have
knowledge of how ostree collects GPG keyrings.
The format of the variants is documented in
`OSTREE_GPG_KEY_GVARIANT_FORMAT`. This format is primarily a copy of
selected fields within `gpgme_key_t` and its subtypes. The fields are
placed within vardicts rather than using a more efficient tuple of
concrete types. This will allow flexibility if more components of
`gpgme_key_t` are desired in the future.
Dan Nicholson [Wed, 14 Jul 2021 17:04:59 +0000 (11:04 -0600)]
lib/repo: Allow preparing GPG verifier without global keyrings
Currently the verifier decides whether to include the global keyrings
based on whether the specified remote has its own keyring or not. Allow
callers to exclude the global keyrings even when that's not the case.
This will be used in a subsequent commit in order to get the GPG keys
only associated with a remote.
Dan Nicholson [Tue, 13 Aug 2019 16:36:11 +0000 (10:36 -0600)]
lib/repo: Factor out GPG verifier preparation
In order to use the GPG verifier, it needs to be seeded with GPG keys
after instantation. Currently this is only used for verifying data, but
it will also be used for getting a list of trusted GPG keys in a
subsequent commit.
Luca BRUNO [Fri, 9 Jul 2021 16:17:31 +0000 (16:17 +0000)]
ci/release-build: evaluate package_version from m4 definition
This fixes the ci-release-build.sh script to directly source
and evaluate 'package_version' from its m4 definition, without
requiring a fully configured source tree.
Jonathan Lebon [Tue, 22 Jun 2021 15:18:48 +0000 (11:18 -0400)]
ostree-remount: Order before systemd-rfkill.*
The `systemd-rfkill.*` service falls in the category of early things
that need write access to `/var`, so we need to make sure we run before
or it might hit the read-only sysroot.
The long-term fix for this is
https://github.com/ostreedev/ostree/issues/2115.
Luca BRUNO [Tue, 22 Jun 2021 10:42:36 +0000 (10:42 +0000)]
lib/commit: respect SOURCE_DATE_EPOCH for commit timestamp
This tweaks `ostree_repo_write_commit` so that it checks for the
envinroment variable `SOURCE_DATE_EPOCH` as a way to override
the current time, which is used as the commit timestamp.
Dan Nicholson [Mon, 21 Jun 2021 16:56:53 +0000 (10:56 -0600)]
ci: Use Debian and Ubuntu release stage tags
Rather than use the release codename tags, use the release stage tags.
This way the configuration (theoretically) doesn't need to be updated
when new Debian and Ubuntu releases are made.
For Debian stable is used instead of buster and a testing (bullseye)
build is added. For Ubuntu, latest is used instead of focal for the
current LTS and rolling is used instead of groovy for the latest
release. This actually changes the Ubuntu build from groovy to hirsute.
Dan Nicholson [Mon, 21 Jun 2021 17:40:07 +0000 (11:40 -0600)]
ci: Update Debian and Ubuntu build dependencies
This refreshes the build dependencies installed for the GitHub Tests
workflow based on the Build-Depends in the upstream packaging. The
handling is now more explicit about any deviations and any release
differences.
Dan Nicholson [Mon, 21 Jun 2021 17:55:59 +0000 (11:55 -0600)]
ci: Disable fail-fast in GitHub Tests workflow
Don't cancel all the jobs if one distro config fails. The jobs are
mostly independent, so we do want to let the others continue in case
the failure is isolated to that particular distro configuration.
Dan Nicholson [Fri, 18 Jun 2021 21:22:39 +0000 (15:22 -0600)]
ci: So long, Travis CI
travis-ci.org stopped running builds on June 15, 2021. Since this
organization is very unlikely to switch to travis-ci.com, just drop the
setup. The new GitHub Actions tests completely replace it.
Dan Nicholson [Fri, 18 Jun 2021 17:33:56 +0000 (11:33 -0600)]
ci: Add GitHub Actions workflow for test suite
This runs the test suite in various distros. The intention is to use
this to replace the Travis CI setup since it often has rate limit
failures.
Each configuration in the matrix runs in a Docker container, installs
system dependencies and then builds and tests ostree. The scripts are
basically copy and paste of the travis ones with some of the lesser used
features pruned out.
Some differences from the travis setup:
* OS details are gathered from `/etc/os-release` instead of being passed
in as environment variables.
* The scripts always assume the user is root and don't try to use
`sudo`.
* The `installcheck` test has been removed since ostree doesn't actually
use that. It could be added to run the installed tests or
`gnome-desktop-testing-runner` could just be called directly.
There should be enough flexibility to run other distros like Fedora,
Arch or Alpine. Another option would be to use the other build scripts
in ci/.
Dan Nicholson [Fri, 18 Jun 2021 18:35:41 +0000 (12:35 -0600)]
Don't fail build when systemd unit path not defined
In configure the systemd unit path is optional, but in the code it's
assumed to be defined. Add an `#ifdef` that throws an error when it's
not defined like the handling of `HAVE_LIBMOUNT` below it.
Simon McVittie [Sun, 18 Apr 2021 11:45:24 +0000 (12:45 +0100)]
libtest-core: On failure, make it clearer what has happened
If we fail as a result of `set -x`, It's often not completely obvious
which command failed or how. Use a trap on ERR to show the command that
failed, and its exit status.
Signed-off-by: Simon McVittie <smcv@collabora.com>
[Originally from bubblewrap commits c5c999a7 "tests: test --userns"
and 3e5fe1bf "tests: Better error message if assert_files_equal fails";
separated into this commit by Simon McVittie.]
Colin Walters [Wed, 16 Jun 2021 13:26:24 +0000 (09:26 -0400)]
Use generator to enable ostree-remount.service and ostree-finalize-staged.path
We struggled for a long time with enablement of our "internal units",
trying to follow the philosophy that units should only be enabled
by explicit preset.
See https://bugzilla.redhat.com/show_bug.cgi?id=1451458
and https://github.com/coreos/rpm-ostree/pull/1482
etc.
And I just saw chat (RH internal on a proprietary system sadly) where
someone hit `ostree-remount.service` not being enabled in CentOS8.
Thinking about this more, I realized we've shipped a systemd generator
for a long time and while its only role until now was to generate `var.mount`,
but by using it to force on our internal units, we don't require
people to deal with presets anymore.
Basically we're inverting things so that "if ostree= is on the kernel
cmdline, then enable our units" and not "enable our units, but have
them use ConditionKernelCmdline=ostree to skip".
Drop the weird gyrations we were doing around `ostree-finalize-staged.path`
too; forking `systemctl start` is just asking for bugs.
So after this, hopefully we won't ever again have to think about
distribution presets and our units.
Colin Walters [Wed, 9 Jun 2021 13:44:09 +0000 (09:44 -0400)]
deploy: Warn if we find content in the deployment's /var
This will be ignored, so let's make it very clear
people are doing something wrong. Motivated by a bug
in a build pipeline that injected `/var/lib/rpm` into an ostree
commit which ended up crashing rpm-ostree because it was an empty db
which it wasn't expecting.
It *also* turns out rpm-ostree is incorrectly dumping content in the
deployment `/var` today, which is another bug.
Dan Nicholson [Thu, 22 Apr 2021 15:10:15 +0000 (09:10 -0600)]
tests: Add single process repo locking tests
The semantics of multiple process locking are covered by
test-concurrency.py, but the semantics of the repository locking from a
single process aren't handled there.
This checks how the repository locking is handled from a single thread
with one OstreeRepo, a single thread with multiple OstreeRepos, and
multiple threads sharing an OstreeRepo.
Dan Nicholson [Mon, 19 Apr 2021 16:03:57 +0000 (10:03 -0600)]
test-concurrency: Lower lock timeout
If there's a locking issue in this test, then it's likely not going to
resolve after a few seconds of serializing access. Lower the default 30
second lock timeout to 5 seconds to prevent the test from hanging
unnecessarily.
projects / ostree.git / log