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>
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>
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
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 command will apply fs-verity on all objects that need it and
needs to be called when an ostree deployment has been copied on a
file-by-file basis, which would loose information such as fs-verity.
This is needed by osbuild which works by creating the final image in a
rootfs, and then separately copying that rootfs file-by-file to a
loopback mounted filesystem image.
This pushes down the code for parsing the `ostree=` cmdline
in the generator into code that's part of libostree-1.so.
This is prep for using logic shared in libotcore.la.
But in general it's just cleaner to also keep the binary
entrypoint to just be a trampoline into the C library.
This will contain logic shared between ostree-prepare-root
and libostree-1.so. It will just link to libgio.so, so as
to avoid pulling in e.g. libcurl and other things.
In other words, `ostree-prepare-root` will not link to `libostree-1.so`,
but will pull in just what it needs from this library.
There's no reason to have these distinct really. If we're using
libsodium, we want it in the same places we're using openssl.
Prep for further refactoring.
Instead of using pkg-config, etc we just include composefs.
In the end the library is just 5 c source files, and it is set up
to be easy to use as a submodule.
For now, composefs support is disabled by default.
This supports checking out a commit into a tree which is then
converted into a composefs image containing fs-verity digests for all
the regular files, and payloads that are relative to a the
`repo/objects` directory of a bare ostree repo.
Some specal files are always created in the image. This ensures that
various directories (usr, etc, boot, var, sysroot) exists in the
created image, even if they were not in the source commit. These are
needed (as bindmount targets) if you want to boot from the image. In
the non-composefs case these are just created as needed in the checked
out deploydir, but we can't do that here.
This is all controlled by the new ex-integrity config section, which
has the following layout:
```
[ex-integrity]
fsverity=yes/no/maybe
composefs=yes/no/maybe
composefs-apply-sig=yes/no
composefs-add-metadata=yes/no
composefs-keyfiile=/a/path
composefs-certfile=/a/path
```
The `fsverity` key overrides the old `ex-fsverity` section if
specified. The default for all these is for the new behaviour to be
disabled. Additionally, enabling composefs implies fsverity defaults
to `maybe`, to avoid having to set both.
This leads to private symbols being exported.
Also specify the single C header, this relies on the gir_C_INCLUDES make variable,
which was introduced in gobject-introspection 1.51.5.
Refactor the summary signing APIs to use internal versions where the
directory fd containing the summary can be found. The existing signing
APIs still uses the repo directory fd, but this will allow using a
temporary directory for the summary and signature in the new metadata
generating API.
Currently this is just a wrapper around regenerating and signing the
summary in one call, but later it will be used to also generate the
`ostree-metadata` commit if the repo has a collection ID.
aboot is special in that it packages kernel, initrd, cmdline, dtb and
signature one combined image (similar to upcoming unified kernel
images). This is then loaded as an image into an aboot partition.
This image is signed by the OS vendor and covers everything in the
image. So locally on the deployed system it should not be possible to
boot an unsigned image (unless signature checking is turned off).
We call a shell script aboot-deploy when it is required to write a new
image to the aboot partition (a file typically starting with aboot and
ending in .img extension). This shell script may also read some
configurations from a .cfg file.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
Check if an argument is present in OstreeKernelArgs. This is a way to
make easier idempotent append and delete operations.
ostree_kernel_args_append_if_missing uses it to avoid inserting a
duplicate key.
Closes#2329
Signed-off-by: Rafael Garcia Ruiz <rafael.garcia@collabora.com>
update all existing deployments in place
Example:
$ sudo ostree admin kargs edit-in-place --append-if-missing=rw
See https://github.com/ostreedev/ostree/issues/2617
This will not add duplicate key, if there is `TESTARG=VAL1` in the
kernel arguments, `--append-if-missing=TESTARG=VAL2` will be ignored.
I was looking at our `.gir` and noticed we had the cmdprivate bits
because the pattern for excluding headers is `-private.h`, which
didn't match `cmdprivate.h`.
I'm aiming to do some more work on the Rust side around `fsck`
like functionality, and this is a useful primitive. There isn't
a great Rust crate for xattrs, and I think it's better to share this
code.
Recently we have noticed exceedingly long execution times
for multiple invocations of ostree prune. This is a result of
calculating full reachability on each invocation.
The --commit-only flag provides an alternative strategy. It will only
traverse and delete commit objects to avoid the more expensive
reachability calculations. This allows us to chain multiple --commit-only
commands cheaply, and then follow with a more expensive ostree prune
invocation at the end to clean up orphaned meta and content objects.
This allows to use Secure Execution with LUKS encrypted boot disk,
key and cryptab are stored only in 'sd-boot' encrypted image.
Signed-off-by: Nikita Dubrovskii <nikita@linux.ibm.com>
This is part of `OstreeCommitModifier`, but I'm not using
that in some of the ostree-ext Rust code.
It just makes more sense as a direct policy API, where it should
have been in the first place. There's already support for
setting a policy object on a commit modifier, so that's all the
old API needs to do now.
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.
This API is push rather than pull, which makes it much more
suitable to use cases like parsing a tar file from external
code.
Now, we have a large mess in this area internally because
the original file writing code was pull based, but static
deltas hit the same problem of wanting a push API, so I added
this special `OstreeRepoBareContent` just for writing regular
files from a push API.
Eventually...I'd like to deprecate the pull based API,
and rework things so that for regular files the push API
is the default, and then `write_content_object()` would
be split up into archive/bare cases.
In this world the `ostree_repo_write_content()` API would
then need to hackily bridge pull to push and it'd be
less efficient.
Anyways for now due to this bifurcation, this API only
works on non-archive repositories, but that's fine for
now because that's what I want for the `ostree-ext-container`
bits.
