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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The current "ed25519" signing type assumes raw Ed25519 key format for
both public and private keys. This patch generalizes it by adding a
new signature type "spki" which uses the X.509 SubjectPublicKeyInfo
format for public keys. Keys in this format can easily be created with
openssl tools and provide crypto agility[1] as the format embeds
algorithm identifier.
The supposed use-case of this feature is to attach multiple signatures
with different algorithms to a single commit, so even if an algorithm
turned vulnerable, the signatures made with other algorithms can still
be used as a fallback. For instance, signer can create an Ed25519
signature along with a quantum-resistent ML-DSA signature.
The following are a couple of implementation notes:
- The private keys shall be stored in the PKCS#8 format, though future
extensions may support other format such as opaque key handles on a
hardware token.
- The "spki" signature type prefers the keys to be encoded in the PEM
format on disk, while it still accepts base64 encoded keys when given
through the command-line.
1. https://en.wikipedia.org/wiki/Cryptographic_agility
Signed-off-by: Daiki Ueno <dueno@redhat.com>
This adds a new class OstreePemReader, which reads PEM blocks from an
input stream. This would be useful for the "x509" signing backend, as
the keys are typically stored in the PEM format.
Signed-off-by: Daiki Ueno <dueno@redhat.com>
This defines a new interface OstreeBlobReader, which encapsulates the
key file parsing logic. This would make it easy to support custom file
formats such as PEM.
Signed-off-by: Daiki Ueno <dueno@redhat.com>
We saw this in an error message:
```
error: Generating commit from rootfs: syncfs: Not a directory
```
I'm pretty sure it's this function call but let's be a bit
more sure by adding a bit more context.
Grub doesn't support replaying XFS journal, so when using
XFS for /boot, fsync() or syncfs() are not enough and can
leave the system in an unbootable state.
Signed-off-by: Etienne Champetier <e.champetier@ateme.com>
This effectively reverts ac1a919f ("boot: Add
ostree-finalize-staged.path").
A bug came in on the OCP side that demonstrates that the way things are
setup right now is racy. If a reboot is triggered quickly after staging
a deployment, the whole pipeline of:
- ostree-finalize-staged.path, which triggers
- ostree-finalize-staged.service, which triggers
- ostree-finalize-staged-hold.service,
may not fully have happened before systemd isolates to `reboot.target`
which will want to kill all pending jobs.
Just directly starting the systemd unit is less elegant but much more
explicit and gets rid of any possible race because it's directly part of
the staging operation.
Fixes: https://issues.redhat.com/browse/OCPBUGS-51150
Previously we were erroring out if xattrs were provided in
non-canonical (e.g. unsorted) form all the way down to just
the bare-user path. But for archive repos and dirmeta we
canonicalized.
Canonicalize bare-user xattrs on both read and write consistently
instead of erroring.
Signed-off-by: Colin Walters <walters@verbum.org>
I hit this in the rpm-ostree rechunker flow somehow
and with this change I now get:
`error: Generating commit from rootfs: Processing dir var: Writing content object: Incorrectly sorted xattr name (prev=user.Librepo.checksum.mtime, cur=security.selinux), index=2`
which is more useful, although I still need to figure out
and fix why that's happening (again?).
Signed-off-by: Colin Walters <walters@verbum.org>
This makes it possible to use pkg-config to link against libostree as
a static library. Unlike shared libraries, static libraries don't
encode their dependencies in the library file, so we have to
communicate them via pkg-config.
Let's quiet the output of libselinux by default, all we
get is the pointless "regex version mismatch" warnings.
This is what e.g. systemd does.
This is exposed via the library; our binary opts in,
then we expect higher level tools like e.g. bootc to
do this too.
Signed-off-by: Colin Walters <walters@verbum.org>
sys/prctl.h already provides prctl.h and adding both imports fails on
musl libc:
/usr/include/sys/prctl.h:88:8: error: redefinition of 'struct prctl_mm_map'
88 | struct prctl_mm_map {
| ^~~~~~~~~~~~
In file included from src/libotutil/ot-unix-utils.c:33:
/usr/include/linux/prctl.h:134:8: note: originally defined here
134 | struct prctl_mm_map {
| ^~~~~~~~~~~~
Followup to 9a0acd7249
Basically our composefs enablement flag has long had a tension between
trying to do two things:
- Enable generating the composefs blob (at deployment time)
- Enable at runtime in prepare-root
And we've hit issues in "ratcheting" enabling composefs
across upgrades because of this.
This change builds on the previous one, and now it's really
simple to talk about:
- If composefs is enabled at build time, we *always*
generate a composefs blob at deplyment time
- Configuring the prepare-root config now mostly
only affects the runtime state.
There is one detail though: in order to handle the
verity requirement at deploy time, we do still parse
the config then.
But for the basic "is composefs enabled at all at runtime"
that is now fully keyed off the config, not the build time
or (worse) whether the deployment happened to have a composefs
blob.
For users who want composefs on, they need to do so in the base
image configuration.
Signed-off-by: Colin Walters <walters@verbum.org>
We have drift again here because we're using an old clang-format
in CI, and some things have landed that it didn't catch.
And update clang-format to ubuntu-24.04 so we are running
against something more modern.
Signed-off-by: Colin Walters <walters@verbum.org>
Adds a new `--kexec` flag to `ostree admin upgrade` which will cause
the deployment to be loaded into kexec after the upgrade completes.
It is particularly useful in conjunction with the `--reboot` flag to
perform a reboot into the new deployment without waiting for the
(often slow) firmware initialization to take place. (And in my case,
allows me to avoid a normal reboot, which can be unreliable on my
hardware).
After an image has been loaded (using the `kexec_file_load` syscall),
the `systemctl-reboot` command (which is called when the existing
`-r` flag is included) will trigger a kexec on the loaded image
rather than a normal reboot. From `systemctl(1)`:
If a new kernel has been loaded via kexec --load, a kexec will be
performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_KEXEC=1"
has been set. If a new root file system has been set up on
"/run/nextroot/", a soft-reboot will be performed instead of a
reboot, unless "SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1" has been set.
A good in-depth technical explanation of kexec can be found here:
https://web.archive.org/web/20090505132901/http://www.ibm.com/developerworks/linux/library/l-kexec.html
My implementation uses the `kexec_file_load` syscall rather than the
older `kexec_load` syscall, which allows the kernel to verify the
signatures of the new kernel. It is supported on Linux 3.17 and
newer. I assume this probably won't be an issue, but if it is, it's
not that hard to put a preprocessor directive around the kexec stuff
to disable it for older kernels. Even RHEL is new enough now to
not be an issue :)
Closes: #435
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>
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>
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>
