IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Fixes a regression from the previous commit; in
the case where the target repo doesn't have composefs in
signed mode there's no reason to verify the digest
at checkout time because we aren't verifying it at
boot time either.
The regression is in cases that use rpm-ostree e.g.
where as of recently we unconditionally add the composefs
digest, but for e.g. FCOS we aren't deploying with fsverity
enabled.
Closes: https://github.com/ostreedev/ostree/issues/3330
Signed-off-by: Colin Walters <walters@verbum.org>
This fixes a truly horrific performance bug when
composefs is enabled, but fsverity is not supported
by the filesystem. We'd fall back to doing *userspace*
checksumming of all files at deployment time which was absolutely
not expected or required.
There's really an immense amount of technical debt
here, such as the confusion between `ex-integity.composefs`
vs the prepare-root config, how we handle "torn" states
where some objects don't have verity enabled but some do,
etc.
The ostree composefs state has two modes:
- signed: We need to enforce fsverity
- unsigned: Best effort resilience
So we fix this by making the deploy path to make verity
"opportunistic" - if the ioctl gives us the data, then we
add it to the composefs.
However, this code path is also invoked when we're
computing the expected composefs digest to inject
as commit metadata, and *that* API must work regardless
of whether the target repo has fsverity enabled as
it may operate on a build server.
One lucky thing in all of this: When I went to add
the "checkout composefs" API I added a stub `GVariant`
for options extensibility, which we now use.
Signed-off-by: Colin Walters <walters@verbum.org>
We were missing the simple, obvious API and CLI to go
from ostree commit -> composefs.
Internally, we had `ostree_repo_checkout_composefs`
with the right "shape" mostly, except it had more code
in the deploy path to turn that into a composefs.
Add a straightforward public API that does what
the deploy code did before, and then the old
API becomes an explicitly internal helper with an `_`
prefix.
Goals:
- Lead towards a composefs-oriented future
- This makes the composefs logic more testable directly
Signed-off-by: Colin Walters <walters@verbum.org>
This avoids false negatives from `ostree --version | grep -q ...`
exiting with failure under `set -o pipefail` because `grep -q` can exit
as soon as it sees the desired string, leaving `ostree --version` to be
terminated by `SIGPIPE` next time it writes to stdout.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise, this test fails on Debian 12 (Linux 6.1) kernels if /var/tmp
is a tmpfs. Some autobuilders put the entire build chroot on a tmpfs,
to speed up builds.
Signed-off-by: Simon McVittie <smcv@debian.org>
For ostree_repo_export_tree_to_archive(), and 'ostree export', when the
exported tree contains multiple files with the same checksum, write an
archive with hard links.
Without this, importing a tree, then exporting it again breaks
hardlinks.
As an example of savings: this reduces the (compressed) size of the
Fedora Flatpak Runtime image from 1345MiB to 712MiB.
Resolves: #2925
- Was using the wrong metadata key
- We were missing setting the canonical commit args which assigns
e.g. owner uid 0, which is important for reproducibility
- Use the new --print-hex to make things easier to read
I am not sure why this is failing on older Debian systems,
but I'm wildly guessing that something being done in `libtest.sh`
is setting up automake in a way that we need. This is done
in other tests.
Or maybe it's the missing `$CMD_PREFIX`? Let's see...
