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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When support for devicetree was added, it created a problem
because old and new ostree versions would compute different
checksums for the "boot data". The scenario here is:
- Have system with ostree < 2020.4
- Reboot into system with ostree 2020.5
- Try to perform an operation that would retain
that previous booted deployment (common)
Currently ostree iterates over all the deployments
that will be retained and calls `install_deployment_kernel()`,
even for the booted one (which is a bit silly), but
just to verify that all boot data for the targeted
deployments are installed.
This then re-computes the checksum and we'd trip this
assertion.
In practice though, we don't strictly require them to match;
the only thing that will happen if they don't is that we'll
end up with another copy of the kernel/initramfs - and
that only temporarily until the previous deployment
gets GC'd.
Longer term, I think what we really want to do anyways
is probably closer to like a little ostree repo for `/boot`
so that we can e.g. still hardlink kernels there even if
the initramfs changes, or hardlink both kernel/initramfs
if just the devicetree changes, etc.
Closes: https://github.com/ostreedev/ostree/issues/2154
The extreme special case of "zero mode" files like `/etc/shadow`
comes up again. What we want is for "user mode" checkouts to
override it to make the file readable; otherwise when operating
as non-root without `CAP_DAC_OVERRIDE` it becomes very difficult
to work with.
Previously, we were hardlinking these files, but then it intersects
with *another* special case around zero sized files, which is
*also* true for `/etc/shadow`.
Trying to avoid hardlinking there unveiled this bug - when
we go to do a copy checkout, we need to override the mode.
Add a new function `ostree_repo_static_delta_execute_offline_with_signature`
which takes a signature engine to verify the delta before applying it.
The `ostree_repo_static_delta_execute_offline` is just a wrapper to this
new function, passing a NULL signature engine.
When this function is called without signature engine, but with a sign
delta, it will only fails if `sign-verify-deltas` is set to true in repo
core options.
This commits move signature existence check and delta signature
verification to share common parts between existing APIs and the new
function.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
This checks if the static delta file is signed or not to be able to
correctly get the superblock to dump.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
This checks if the static delta file is signed or not to be able to
correctly get the superblock to apply.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
Add new "static-delta verify" sub-command.
This supports multiple keys to verify the static-delta file.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
This retrieves the signatures and pass the static delta block as an array
of bytes to ostree_sign_data_verify().
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
While the commits contained in the single static-delta file are signed so
we can check them and operate on trusted data, the superblock isn't signed
in any way, so it end up operating on untrusted data to:
1. actually find where the trusted data is, and
2. check whether the update is fit for the current device by looking at
the collection id stored in the metadata
This commit generates signatures of all static data, and concatenate them
to the existing static delta format, i.e. as a GVariant layout `a{sv}ay`
where
- a{sv}: signatures
- ay: existing delta variant
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
This was only used in one place, and (especially with the simplification
with GMainContextPopDefault) and the one caller doesn't really do
much more than call the helper. Additionally, what little it does (saving
the result in the cache) is inherently tied to how the helper work,
and will become even more so when we support summary indexes.
This is a preparatory cleanup for supporting summary indexes. It
doesn't change any behaviour and passes make check on its own.
This loads and makes a digest for a delta superblock. The previous
code was used when generating the deltas section in the summary
file. This changes nothing, but is in preparation for using similar
formats in a separate delta index file.
The change in cbf1aca1d5c08d2f40832d16670484ba878d95fb actually
only mmaps the signature file, not the summary. This change makes
use mmap both, as well as extract the cache loading into a helper
function that we will later use in more places.
ostree_repo_list_static_delta_names() tried to validate that
any second-level directory element was a directory, but there was
a cut-and-paste issue, and it used `dent->d_type` instead
of `sub_dent->d_type`.
This fixes the code, but all old ostree versions will break if
there are non-directories in a subdirectory of the deltas directory
in the repo, so be wary.
Looking at
https://github.com/coreos/coreos-assembler/issues/1703
a user is getting a bare:
`error: fsetxattr: Permission denied`
I don't think it's these code paths since a deploy
isn't happening but on inspection I noticed we didn't
have error prefixing here.
That test will not make it into the fedora-coreos-config repo until the
libostree fix gets percolated down. PR is:
https://github.com/coreos/fedora-coreos-config/pull/586
But we want to make sure that the fix does work and that we don't
regress on it. So manually fetch it for now.
When we remount `/sysroot` as read-only, we also make `/etc` read-only.
This is usually OK because we then remount `/var` read-write, which also
flips `/etc` back to read-write... unless `/var` is a separate
filesystem and not a bind-mount to the stateroot `/var`.
Fix this by just remounting `/etc` read-write in the read-only sysroot
case.
Eventually, I think we should rework this to set everything up the way
we want from the initramfs (#2115). This would also eliminate the window
during which `/etc` is read-only while `ostree-remount` runs.
