There are some existing issues around fsck in unprivileged bare mode,
so this test does not really work at the moment. Leaving it as a FIXME
for the moment.
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.
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.
Followup to PRs related to https://github.com/ostreedev/ostree/issues/2410
Since the test suite now covers this the test was failing on
a Fedora SELinux enabled host where we see `security.selinux`
even if not in the commit.
I was seeing an `EPERM` here which was confusing.
It turned out the real error was `EEXIST`.
Since we're referring to the original error, but we do a
lot of computation in the middle, we need to save errno.
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`.
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.
As pointed out in the original review, `gpg-list-keys` fits better
alongside the existing `gpg-import`.
Changes were done with:
```
git grep -l list-gpg-keys | xargs sed -i 's/list-gpg-keys/gpg-list-keys/'
for src in $(git ls-files '*list-gpg-keys*'); do
dst=${src/list-gpg-keys/gpg-list-keys}
git mv "$src" "$dst"
done
```
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>