Make fast forward from 2024.9-1

[dgit --quilt=unapplied]

Skip test-admin-deploy-uboot.sh on s390x

It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.

Bug: https://github.com/ostreedev/ostree/issues/3086
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch

test-sysroot: Skip on s390x by default

This test regularly fails on the buildds, but I cannot reproduce the
failure on a porterbox.

Bug: https://github.com/ostreedev/ostree/issues/2527
Bug-Debian: https://bugs.debian.org/1025532
Forwarded: not-needed

Gbp-Pq: Topic debian
Gbp-Pq: Name test-sysroot-Skip-on-s390x-by-default.patch

Skip test-pull-repeated during CI

This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.

It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.

Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch

Release to unstable

New upstream release

Update upstream source from tag 'upstream/2024.10'

Update to upstream version '2024.10'
with Debian dir bcbfca73aac7d6d1c8b452363bef7aaa9cc5175e

New upstream version 2024.10

Update changelog

d/salsa-ci.yml: Use recommended recipe

Merge pull request #3361 from cgwalters/release

Release 2024.10

Merge pull request #3351 from cgwalters/fix-transient-root-doc

man: Note semantics combining `root.transient` with `composefs.enabled`

Post-release version bump

Signed-off-by: Colin Walters <walters@verbum.org>

Release 2024.10

Signed-off-by: Colin Walters <walters@verbum.org>

man: Note semantics combining `root.transient` with `composefs.enabled`

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>

Merge pull request #3353 from jlebon/pr/composefs-maybe

libostree/deploy: enable composefs by default

Merge pull request #3354 from ruihe774/cfs-verity

prepare-root: Add composefs.enabled=verity

Merge pull request #3348 from qiuzhiqian/main

rofiles-fuse: when fuse execution fails, rofiles-fuse still returns exit code 0

Merge pull request #3357 from ruihe774/validate-len

sign-ed25519: Fix error message of validate_length

lib/deploy: error out if composefs enabled but unsupported

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`.

libostree/deploy: enable composefs by default

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

Merge pull request #3356 from cgwalters/fix-ci

Fix ci

sign-ed25519: Fix error message of validate_length

sysroot-deploy: Require fsverity when composefs.enabled=verity

prepare-root: Add composefs.enabled=verity

deny: Add Unicode-3.0

This is under e.g.
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/
and is now used by the unicode-ident crate.

Switch to quay.io vs registry.ci

The old one was a mirror that seems to have finally
been decommissioned.

Merge pull request #3346 from cgwalters/commit-label-ordering

core: Always sort incoming xattrs

rofiles-fuse: Fixed the problem that when fuse execution fails, the command returns a status code of 0

testcase:
`$ sudo rofiles-fuse a b`
fuse: bad mount point `b': No such file or directory
`$ echo $?`
0

core: Always sort incoming xattrs

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>

Merge pull request #3340 from smcv/issue3339

composefs: Ensure buffer is suitably aligned for struct fsverity_digest

composefs: Ensure buffer is suitably aligned for struct fsverity_digest

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>

Try re-enabling tests during Salsa-CI

Merge pull request #3337 from dabukalam/patch-1

README: Update buildstream URL to new github repo

README: Update buildstream URL to new github repo

Release to unstable

Make fast forward from 2024.8-2

[dgit --quilt=unapplied]

Skip test-admin-deploy-uboot.sh on s390x

It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.

Bug: https://github.com/ostreedev/ostree/issues/3086
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch

test-sysroot: Skip on s390x by default

This test regularly fails on the buildds, but I cannot reproduce the
failure on a porterbox.

Bug: https://github.com/ostreedev/ostree/issues/2527
Bug-Debian: https://bugs.debian.org/1025532
Forwarded: not-needed

Gbp-Pq: Topic debian
Gbp-Pq: Name test-sysroot-Skip-on-s390x-by-default.patch

Skip test-pull-repeated during CI

This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.

It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.

Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch

Drop patch that was applied upstream

New upstream release

Update upstream source from tag 'upstream/2024.9'

Update to upstream version '2024.9'
with Debian dir 915aefc068b31787b88aa2e67a1cabba6afe8de9

New upstream version 2024.9

Merge pull request #3328 from cgwalters/release

Release 2024.9

Release 2024.9

Signed-off-by: Colin Walters <walters@verbum.org>

configure: post-release version bump

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3334 from cgwalters/fix-composefs-default-docs

prepare-root: Fix composefs docs

Merge pull request #3331 from cgwalters/verity-no-verity

checkout: Only verify digest if repo requires fsverity

bootupd-static: Drop this test

It breaks due to https://bugzilla.redhat.com/show_bug.cgi?id=2308594

prepare-root: Fix composefs docs

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>

checkout: Only verify digest if repo requires fsverity

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>

Merge pull request #3333 from smcv/gpg-2-2-45

tests: Work around GPG 2.2.45 error behaviour when revoking an expired key

Release to unstable

Make fast forward from 2024.8-1

[dgit --quilt=unapplied]

Skip test-admin-deploy-uboot.sh on s390x

It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.

Bug: https://github.com/ostreedev/ostree/issues/3086
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch

test-sysroot: Skip on s390x by default

This test regularly fails on the buildds, but I cannot reproduce the
failure on a porterbox.

Bug: https://github.com/ostreedev/ostree/issues/2527
Bug-Debian: https://bugs.debian.org/1025532
Forwarded: not-needed

Gbp-Pq: Topic debian
Gbp-Pq: Name test-sysroot-Skip-on-s390x-by-default.patch

Skip test-pull-repeated during CI

This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.

It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.

Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch

tests: Work around GPG 2.2.45 error behaviour when revoking an expired key

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
Forwarded: https://github.com/ostreedev/ostree/pull/3333

Gbp-Pq: Name tests-Work-around-GPG-2.2.45-error-behaviour-when-revokin.patch

Add proposed patch to work around a test failure with gnupg 2.2.45

Mitigates: #1086140

tests: Work around GPG 2.2.45 error behaviour when revoking an expired key

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

Merge pull request #3332 from cgwalters/fixups-for-fcos-composefs-default

tests: Skip checking for immutable bit on composefs

tests: Skip checking for immutable bit on composefs

Needed changing after FCOS switch.

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3326 from cgwalters/hack-deploy-no-verity

deploy: Don't recompute verity checksums if not enabled

deploy: Don't recompute verity checksums if not enabled

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>

Merge pull request #3323 from cgwalters/copydir-no-xattrs

deploy: Don't copy xattrs for devicetree

deploy: Don't copy xattrs for devicetree

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>

Merge pull request #3316 from ruihe774/readonly-cmdline

prepare-root: allow `sysroot.readonly=true` with kernel cmdline `ro`

Merge pull request #3322 from cgwalters/tweak-commit-assertion

commit: Give a better error message for unhandled file type

commit: Give a better error message for unhandled file type

xref https://github.com/ostreedev/ostree/issues/3319

It'd be useful to know what file type is being hit here; I believe
this code path should be unreachable.

prepare-root: allow sysroot.readonly=true with kernel cmdline ro

Merge pull request #3317 from cgwalters/minor-overlay-tweaks

checkout: Add commentary around whiteout "quoting"

checkout: Add commentary around whiteout "quoting"

Signed-off-by: Colin Walters <walters@verbum.org>

Merge pull request #3311 from cgwalters/curl-minor

curl: Add more assertions for curl return values

Merge pull request #3313 from cgwalters/fix-readthedocs

rust-bindings: Fix readthedocs.io link

rust-bindings: Fix readthedocs.io link

It should now point at GH pages.

Closes: https://github.com/ostreedev/ostree/issues/3312
Signed-off-by: Colin Walters <walters@verbum.org>

Release to unstable

Make fast forward from 2024.7-3

[dgit --quilt=unapplied]

Skip test-admin-deploy-uboot.sh on s390x

It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.

Bug: https://github.com/ostreedev/ostree/issues/3086
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch

test-sysroot: Skip on s390x by default

This test regularly fails on the buildds, but I cannot reproduce the
failure on a porterbox.

Bug: https://github.com/ostreedev/ostree/issues/2527
Bug-Debian: https://bugs.debian.org/1025532
Forwarded: not-needed

Gbp-Pq: Topic debian
Gbp-Pq: Name test-sysroot-Skip-on-s390x-by-default.patch

Skip test-pull-repeated during CI

This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.

It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.

Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch

Drop patches that were included in the new upstream release

New upstream release

Update upstream source from tag 'upstream/2024.8'

Update to upstream version '2024.8'
with Debian dir a7c80d40c3c07286d9d4b6d78311343442782e33

New upstream version 2024.8

curl: Add more assertions for curl return values

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.

Merge pull request #3309 from cgwalters/release

Release 2024.8

Post-release version bump

Release 2024.8

Release to unstable

Make fast forward from 2024.7-2

[dgit --quilt=unapplied]

Skip test-admin-deploy-uboot.sh on s390x

It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.

Bug: https://github.com/ostreedev/ostree/issues/3086
Forwarded: no

Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch

test-sysroot: Skip on s390x by default

This test regularly fails on the buildds, but I cannot reproduce the
failure on a porterbox.

Bug: https://github.com/ostreedev/ostree/issues/2527
Bug-Debian: https://bugs.debian.org/1025532
Forwarded: not-needed

Gbp-Pq: Topic debian
Gbp-Pq: Name test-sysroot-Skip-on-s390x-by-default.patch

Skip test-pull-repeated during CI

This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.

It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.

Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch

curl: Make socket callback during cleanup into no-op

Because curl_multi_cleanup may invoke callbacks, we effectively have
some circular references going on here. See discussion in

https://github.com/curl/curl/issues/14860

Basically what we do is the socket callback libcurl may invoke into a no-op when
we detect we're finalizing. The data structures are owned by this object and
not by the callbacks, and will be destroyed below. Note that
e.g. g_hash_table_unref() may itself invoke callbacks, which is where
some data is cleaned up.

Signed-off-by: Colin Walters <walters@verbum.org>
Origin: upstream, 2024.8, commit:4d755a85225ea0a02d4580d088bb8a97138cb040
Bug: https://github.com/ostreedev/ostree/issues/3299
Bug-Debian: https://bugs.debian.org/1082121

Gbp-Pq: Name curl-Make-socket-callback-during-cleanup-into-no-op.patch

curl: Assert that curl_multi_assign worked

ref https://github.com/ostreedev/ostree/issues/3299

This won't fix that issue, but *if* this assertion triggers
it should give us a better idea of the possible codepaths
where it is happening.

Signed-off-by: Colin Walters <walters@verbum.org>
Origin: upstream, 2024.8, commit:472d9d493a3e4a08415da4c337a7e831e0c5a5e2
Bug-Debian: https://bugs.debian.org/1082121

Gbp-Pq: Name curl-Assert-that-curl_multi_assign-worked.patch

Add patches from upstream to avoid libflatpak crash with curl 8.10.x

Closes: #1082121

Merge pull request #3307 from cgwalters/curl-reorder-teardown

curl: Make socket callback during cleanup into no-op

Merge pull request #3306 from cgwalters/curl-assert

curl: Assert that curl_multi_assign worked

curl: Make socket callback during cleanup into no-op

Because curl_multi_cleanup may invoke callbacks, we effectively have
some circular references going on here. See discussion in

https://github.com/curl/curl/issues/14860

Basically what we do is the socket callback libcurl may invoke into a no-op when
we detect we're finalizing. The data structures are owned by this object and
not by the callbacks, and will be destroyed below. Note that
e.g. g_hash_table_unref() may itself invoke callbacks, which is where
some data is cleaned up.

Signed-off-by: Colin Walters <walters@verbum.org>