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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It's all quite confusing having to reason about both the pre-composefs
ostree and the composefs version. But hopefully soon we more firmly
leave behind that first legacy.
Signed-off-by: Colin Walters <walters@verbum.org>
If composefs was explicitly requested (`enabled = true`) but libostree
was not compiled with composefs support, error out at deploy time. This
matches the logic in `ostree-prepare-root`.
The composefs libostree integration has been supported for a while now
and is actively in use in various ostree/bootc-based systems. Let's
turn it on by default.
This has no effect if composefs support is not compiled in. Note also
that this does not change the default value of the `composefs.enabled`
tristate to `true`. The default is still `maybe`, but the deploy API
will now also create composefs images for `maybe`.
The reason for doing it this way is so that systems upgrading from
old libostree versions (which may either not have composefs support or
may have composefs-related bugs) will still be able to upgrade and not
trip `ostree-prepare-root` in the new deployment (which allows missing
composefs images for `maybe`).
We may in the future change the default value to `true`.
See also: https://github.com/ostreedev/ostree/issues/2867
When recomputing selinux attrs during commit, we weren't sorting,
which could cause various issues like fsck failures.
This is a big hammer; change things so we always canonicalize
(i.e. sort) the incoming xattrs when creating a file header
and directory metadata.
I think almost all places in the code were already keeping
things sorted, but it's better to ensure correctness first.
If we ever have some performance issue (I'm doubtful) we
could add something like `_ostree_file_header_known_canonicalized`
or so.
Closes: https://github.com/ostreedev/ostree/issues/3343
Signed-off-by: Colin Walters <walters@verbum.org>
struct fsverity_digest starts with a __u16, so it will normally require
16-bit alignment, which is not guaranteed for a char array.
Resolves: https://github.com/ostreedev/ostree/issues/3339
Signed-off-by: Simon McVittie <smcv@debian.org>
In practice in ostree-sysroot-deploy.c we only react to having
`composefs = yes`; the docs mention `maybe` but that never did
anything.
The value is wrong in the code too, but I'm not touching
that here to avoid conflating changes - the main thing to fix
is the docs because here `maybe == no`.
Signed-off-by: Colin Walters <walters@verbum.org>
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>
In GPG 2.2.45, a diagnostic message about the only trusted key having
already expired causes this import to produce exit status 2, but the
import still succeeds (the key is still revoked).
Bug: https://dev.gnupg.org/T7351
Bug-Debian: https://bugs.debian.org/1086140
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>
xref: https://github.com/coreos/fedora-coreos-tracker/issues/1808
For the kernel/initramfs that we copy to `/boot`
we use an explicit relabeling today, ignoring the source SELinux
context.
When we added handling for devicetree it reuse the `copy_dir_recurse`
we have for `etc` handling, and that copied the source xattrs.
Let's ensure that the devicetree is also `boot_t` by *not* copying
xattrs and relying on the default labeling.
Signed-off-by: Colin Walters <walters@verbum.org>
Followup to the previous curl fixes; if we'd had an assertion
earlier debugging the failure would have been more obvious.
All of these are "should not fail" cases so asserting is
right.
