sign-ed25519: Implement sign and verify using openssl

libsodium is used if configured to keep the old behaviour, but if
it is not enabled, and openssl is used, then ed25519 is now supported.

sign-ed25519: Drop some uses of libsodium

This adds some defines for ed25519 key sizes and drops uses
of the libsodium defines for these, as well as replacing sodium_bin2hex
use with ot_bin2hex. Some code that wes optionally built before are now
always built.

The goal for this is to support both libsodium and openssl.

Also fixes return value of _load_pk_from_stream(). It used
to always return FALSE.

Merge pull request #2923 from alexlarsson/fix-composefs-test

tests: Fix composefs test

tests: Fix composefs test

- Was using the wrong metadata key
- We were missing setting the canonical commit args which assigns
  e.g. owner uid 0, which is important for reproducibility
- Use the new --print-hex to make things easier to read

show: Add --print-hex

The default GVariant output for byte arrays is illegible to humans,
and byte arrays are super common for us.

Merge pull request #2913 from cgwalters/tmpfile-not-on-revokefs

fetcher: Always open tmpfiles in repo (except on FUSE)

Merge pull request #2918 from ostreedev/dependabot/submodules/composefs-ac729b5

build(deps): bump composefs from `412cb5e` to `ac729b5`

Merge pull request #2912 from cgwalters/itest-transactionality-debug

tests/inst: A few small patches

Merge pull request #1633 from cgwalters/pkglibexec-tests

Drop "ostree trivial-httpd" CLI, move to tests directory

fetcher: Always open tmpfiles in repo (except on FUSE)

This reverts commit 4e61e6f7d0d6aebd6abcdc455ec53164afe39e8d
and re-instates the fix for ensuring that we download temporary
files into the repository location.

However in order to ensure we don't re-introduce
https://github.com/ostreedev/ostree/issues/2900
we detect the case where we're writing to a FUSE mount
and keep the prior behavior.

I've verified that this works with flatpak.

Note a downside of this is the change needs to be triplicated
across the 3 http backends.

This then again
Closes: https://github.com/ostreedev/ostree/issues/2571

Merge pull request #2905 from cgwalters/prepare-root-static-split

Separate prepare-root static path + link to glib

build(deps): bump composefs from `412cb5e` to `ac729b5`

Bumps [composefs](https://github.com/containers/composefs) from `412cb5e` to `ac729b5`.
- [Release notes](https://github.com/containers/composefs/releases)
- [Commits](https://github.com/containers/composefs/compare/412cb5e6aaf516c5e2a7f67e426a25ed2926e101...ac729b579dd332938c6ad43ba83b2b896631dad4)

---
updated-dependencies:
- dependency-name: composefs
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

Drop "ostree trivial-httpd" CLI, move to tests directory

See https://github.com/ostreedev/ostree/issues/1593

Basically this makes it easier for people packaging, as the trivial-httpd
is only for tests, and this way the binary will live with the tests.

Also at this point nothing should depend on `ostree trivial-httpd`.

Merge pull request #2916 from cgwalters/release

Release 2023.5

Merge pull request #2914 from cgwalters/doc-usergroups

docs: Update user and group section

configure: post-release version bump

Release 2023.5

Merge pull request #2899 from ostreedev/dependabot/submodules/composefs-412cb5e

build(deps): bump composefs from `08bdb03` to `412cb5e`

prepare-root: Link to glib

Since we've split off the "prepare root as init" code
into a separate file, we can now use glib to parse
the config file again, which is a lot less hacky.

This is particularly motivated by composefs, where
we want to do more in the initramfs.  Future patches
may also link to parts of libostree.

Separate prepare-root static path

We should have done this a long time ago.  We don't have any test
coverage for the no-initramfs path, and I think it's not long
term supportable as we want to add more features like composefs.

Particularly now that there's good support for embedding an
initramfs in a kernel image, I see little value in a path for
having custom static linking for this prepare root flow.

That said, we will continue to make a best-effort "it compiles"
attempt to support it.

Fork the "pid 1" prepare root code into a new
`ostree-prepare-root-static.c` file, and drop the runtime conditionals.

We can drop the composefs logic from `-static.c` which ends up
keeping that file much smaller.

A further next step here will be to actually fold the
`prepare-root.c` logic into the main `ostree` binary which we
can then just include in the initramfs.

build(deps): bump composefs from `08bdb03` to `412cb5e`

Bumps [composefs](https://github.com/containers/composefs) from `08bdb03` to `412cb5e`.
- [Release notes](https://github.com/containers/composefs/releases)
- [Commits](https://github.com/containers/composefs/compare/08bdb030fcff4f55ef63aa828b09b57a6cd4d234...412cb5e6aaf516c5e2a7f67e426a25ed2926e101)

---
updated-dependencies:
- dependency-name: composefs
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

docs: Update user and group section

- mention `DynamicUser=yes`
- mention the recent systemd JSON bits
- mention sysusers.doc

And briefly talk about the tradeoffs in these.

Merge pull request #2911 from cgwalters/fix-generator-regression

Fix return value of generator on non-ostree systems

Merge pull request #2910 from cgwalters/more-ci-fixes

ci: Fix executability

tests: Enable mtime test

I think this just accidentally was never enabled.

While looking at the code, add a sleep here to be resilient to
filesystems with only second mtime granularity.

tests: Drop unused alias

tests/transactionality: Port a bit to xshell

This will give us more useful error messages which should
help debug a flake.

Merge pull request #2907 from cgwalters/test-composefs

tests: Source libtest before exiting

test-composefs: Sync flow with other tests

I am not sure why this is failing on older Debian systems,
but I'm wildly guessing that something being done in `libtest.sh`
is setting up automake in a way that we need.  This is done
in other tests.

Or maybe it's the missing `$CMD_PREFIX`?  Let's see...

Fix return value of generator on non-ostree systems

Commit aa72caffb540114a0e8635ab2990b9c8b0b8f9db
regressed the `ostree-system-generator` on non-ostree systems.
If there's no `ostree=` karg, we need to just exit 0.

Closes: https://github.com/ostreedev/ostree/issues/2909
Fixes: aa72caffb540114a0e8635ab2990b9c8b0b8f9db

ci: Fix executability

Merge pull request #2904 from cgwalters/prow-ci

ci/prow: Build tests before trying to install

Merge pull request #2906 from cgwalters/compiletest-static-prepareroot

ci: Add "it compiles" coverage for --with-static-compiler

ci: Add "it compiles" coverage for --with-static-compiler

Prep for further changes.

ci/prow: Build tests before trying to install

Our `install` target doesn't depend on `all` unlike the
rpm-ostree version; not doing so is arguably better, so let's
explicitly build before installing.

Merge pull request #2902 from ericcurtin/ostree-aboot-pass-options

bootloader: Pass "options" to aboot bootloader backend

Merge pull request #2901 from cgwalters/revert-fetcher-change

Revert "fetcher: Always open tmpfiles in repo location"

Revert "fetcher: Always open tmpfiles in repo location"

This reverts commit f7f6f87c513c9f35bc24f35e909779c19cb49d3a.

This seems to have broken flatpak, so we'll revert and then
investigate.

Closes: https://github.com/ostreedev/ostree/issues/2900

Merge pull request #2903 from dbnicholson/composefs-digest-fix

prepare-root: Adjust to composefs mount struct changes

prepare-root: Adjust to composefs mount struct changes

This fixes a regression from the latest composefs submodule update in
1582edd1d4a6b26874d3897de8a5586f979a0715. In composefs commit
7560a4fd388481f479c0b3fc2e6d20c6321d9b74 the struct field was changed
from the generic `expected_digest` with the thought that there may be
other signatures or digests in the future.

bootloader: Pass "options" to aboot bootloader backend

aboot-deploy must know where the next root filesystem to boot is to set
up a symlink /ostree/root.a or /ostree/root.b , this location is in the
ostree= part of these passed in options.

Signed-off-by: Eric Curtin <ecurtin@redhat.com>

Merge pull request #2896 from akiernan/main

lib/deploy: Use off_t not __off_t

lib/deploy: Use off_t not __off_t

Not clear why this was __off_t which is the sole appearance in the code
base, but it breaks musl builds.

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>

Merge pull request #2895 from cgwalters/release

Release 2023.4

Merge pull request #2893 from cgwalters/update-prow-config

ci: Add some composefs testing

Merge pull request #2892 from ostreedev/dependabot/submodules/composefs-08bdb03

build(deps): bump composefs from `c9188cd` to `08bdb03`

configure: post-release version bump

Release 2023.4

Merge pull request #2891 from cgwalters/commit-compute-composefs-digest

lib: Rework composefs metadata, drop custom signatures

ci: Sync prow config with rpm-ostree, enable composefs there

I want to gain testing over the composefs path; but without
yet changing the main Jenkins build.  Because we have duplicate/overlapping
CI systems, we can take advantage of this by testing the composefs
flow via Prow.

Sync the Prow build scripts with what's in coreos/rpm-ostree
right now.

Then let's test the composefs flow a bit more e2e there.

tests: Add a sanity check for composefs

Prep for adding some coverage of this flow when booting with
composefs.

docs/composefs: Updates

- fix URL
- Document requirements
- Document kernel argument
- Adjust for recent changes

build(deps): bump composefs from `c9188cd` to `08bdb03`

Bumps [composefs](https://github.com/containers/composefs) from `c9188cd` to `08bdb03`.
- [Release notes](https://github.com/containers/composefs/releases)
- [Commits](https://github.com/containers/composefs/compare/c9188cd1f80374d0785e90d2e4d31749b9f91395...08bdb030fcff4f55ef63aa828b09b57a6cd4d234)

---
updated-dependencies:
- dependency-name: composefs
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

lib: Rework composefs metadata, drop custom signatures

We will be switching to handling signature verification of
the target ostree commit.

Merge pull request #2890 from cgwalters/composefs-err-frees

composefs: Avoid double free in error path

composefs: Avoid double unref

The interaction of `iter_loop` and autofree is way too subtle;
I happened to be reading this code and noticed we did the NULL
reset in one path but not another.

The real fix is Rust...

Merge pull request #2885 from cgwalters/doc-composefs

composefs: Add some basic docs

Merge pull request #2886 from daissi/wip/daissi/disable-http2

ostree-fetcher-curl: explicitly use HTTP1.1 when HTTP2 is disabled

Merge pull request #2888 from cgwalters/more-error-prefixing

Add more error prefixing when parsing commit objects

Add more error prefixing when parsing commit objects

I've got more debug information in the error case that motivated
https://github.com/ostreedev/ostree/pull/2884/commits/bae4347abeaa2a66d213758f790058f42cb71fd1
"pull: Add error prefixing for corrupt checksums"
where the sole error is

`error: Invalid checksum of length 0 expected 32`

This must be coming from the pull code in the case where we've
already fetched the commit object.

- Add some error prefixing here in the core commit validation code
- Ensure that we do the validation immediately after loading, including
  of the parent commit reference where I think this error must be coming
  from
- Then the pull code can just safely call `ostree_commit_get_parent`
  which already does the hex conversion etc.

ostree-fetcher-curl: explicitly use HTTP1.1 when HTTP2 is disabled

The current logic to select the HTTP version to be use relies on
the fact that curl don't use by default HTTP2. This assumption seems wrong with
recent versions of curl.

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

composefs: Add some basic docs

Let's describe the state of things at a high level, independent
of the tracking issue which has a lot more detail (and hence noise).

This document keeps things at a high level and describes how to
enable things today.

Merge pull request #2880 from kraj/main

fix build with lld linker

libostree: Link with libgpg-error for gpg_strerror_r API

With f461c02bb55bf2853a3b81ed5c8618040ab54e98 use of gpg_strerror_r
was added this symbol comes from libgpg-error however, therefore its
needed to add -lgpg-error to cmdline to resolve this symbol especially
with gold and lld linker. Fixes

aarch64-yoe-linux-ld.lld: error: undefined reference due to --no-allow-shlib-undefined: gpg_strerror_r
>>> referenced by ./.libs/libostree-1.so

Merge pull request #2884 from cgwalters/errprefix-pull-checksums

pull: Add error prefixing for corrupt checksums

pull: Add error prefixing for corrupt checksums

I got a bug report with the bare error
```
error: Invalid checksum of length 0 expected 32
```

And I'm pretty sure it's from here.  Add error prefixing so we
know exactly which metadata object was corrupt.

Merge pull request #2881 from ostreedev/dependabot/submodules/composefs-c9188cd

build(deps): bump composefs from `af8e1a7` to `c9188cd`

Merge pull request #2882 from cgwalters/more-test-concurrency

test-concurrency: Don't lower timeout

test-concurrency: Don't lower timeout

I think there's never been a real race condition here.  Instead
the problem is:

- We have a timeout on the lock, after which we error out (30s)
- This test actually *lowers* the timeout

Looking through the failures for test-concurrency what I see
is
`error: Locking repo exclusive failed: Resource temporarily unavailable`
which is us hitting the timeout.

Hardcoded timeouts are just going to be subject to race conditions.
I understand not wanting to block forever in some cases, but any
arbitrary timeout is just going to get hit in real world conditions
too.

Anyways for now, stop shooting ourselves in the foot and at least
keep the timeout at the default.

Closes: https://github.com/ostreedev/ostree/issues/2038

Merge pull request #2865 from barthalion/increase-metadata-size

Increase the metadata size limit to 128MB

Update big metadata size in test-pull-large-metadata

build(deps): bump composefs from `af8e1a7` to `c9188cd`

Bumps [composefs](https://github.com/containers/composefs) from `af8e1a7` to `c9188cd`.
- [Release notes](https://github.com/containers/composefs/releases)
- [Commits](https://github.com/containers/composefs/compare/af8e1a7cf6864c27e2ceac44cc145bd78734df30...c9188cd1f80374d0785e90d2e4d31749b9f91395)

---
updated-dependencies:
- dependency-name: composefs
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

Merge pull request #2879 from alexlarsson/composefs-new-signature-approach

composefs: Change how we do signatures

composefs: Change how we do signatures

Currently we generate a signature for the actual composefs image, and
then we apply that when we enable fsverity on the composefs
image. However, there are some issues with this.

First of all, such a signed fs-verity image file can only be read if
the corresponding puiblic keyring is loaded into the fs-verity
keyring. In a typical secure setup we will have a per-commit key that
is loaded from the initrd. Additionally, the keyring is often sealed
to avoid loading more keys later.

This means you can only ever mount (or even look at) composefs images
from the current boot. While this is not a huge issue it is something
of a pain for example when debugging things.

Secondly, and more problematic, during a deploy we can't enable
fs-verity on the newly created composefs file, because and at that
point you need to pass in the signature. Unfortunately this will fail
if the matching public key is not in the keyring, which will fail for
similar reasons as the first issue.

The current workaround is to *not* enable fs-verity during deploy, but
write the signature to a file. Then the first time the particular
commit is booted we apply the signature to the iamge. This works
around issue two, but not issue one. But it causes us to do a lot of
writes and computation during the first boot as we need to write the
fs-verity merkle tree to disk. It would be much better and robust if
the merkle tree could be written during the deployment of the update
(i.e. before boot).

The new apporach is to always deploy an unsigned, but fs-verity
enabled composefs image. Then we create separate files that contain
the expected digest, and a signature of that file. On the first boot
we sign the digest file, and on further boots we can just verify
that it is signed before using it.

This fixes issue 1, since all deploys are always readable, and it
makes the workaround for issue 2 much less problematic, as we only
need to change a much smaller file on the first boot.

Long term I would like to avoid the first-boot writing totally, and
I've been chatting with David Howells (kernel keyring maintainer) and
he proposed adding a new keyring syscall that verifies a PKCS#7
signature from userspace directly. This would be exactly what
fs-verity does, except we wouldn't have to write the digest to disk
during boot, we would just read the digest file and the signature file
each boot and ask the kernel to verify it.

Merge pull request #2877 from ericcurtin/ostree-aboot

Add ostree=aboot for signed Android Boot Images

Update submodule: composefs

We will need the new fsverity computation helpers.

Fix read_proc_cmdline_key ("ot-composefs") memory leak

Make it an autofree_char rather than a char

Add ostree=aboot for signed Android Boot Images

Some kernel images are delivered in a signed kernel + cmdline +
initramfs + dtb blob. When this is added to the commit server side, only
after this do you know what the cmdline is, this creates a recursion
issue. To avoid this, in the case where we have ostree=aboot karg
set, create a symlink after deploy to the correct ostree target in the
rootfs, as the cmdline can't be malleable and secured client-side at
the same time.

Merge pull request #2875 from cgwalters/tempf-always-repo

fetcher: Always open tmpfiles in repo location

Merge pull request #2872 from cgwalters/composefs-followups

Composefs followups

fetcher: Always open tmpfiles in repo location

In an installation environment (like a live ISO) we may
not have significant space outside of the target installation
repository.

There's no reason not to always open a linkable tempfile.  In
the future we should fix the pull path to verify the checksum
and then just directly link in the object instead of copying.

Closes: https://github.com/ostreedev/ostree/issues/2571

Merge pull request #2874 from aospan/inode64-fix

commit: fix ostree deployment on 64-bit inode fs

commit: fix ostree deployment on 64-bit inode fs

This commit addresses a bug that was causing ostree deployment
to become corrupted on the large fs, when any package was installed using
'rpm-ostree install'.

In such instances, multiple files were assigned the same inode. For
example, the '/home' directory and a regular file 'pkg-get' were
assigned the same inode (2147484070), making the deployment unusable.

A root cause analysis was performed, running the process under gdb,
which revealed a lossy conversion from guint64 to guint32, for example
6442451366 converted to 2147484070:

(gdb) p name
$10 = 0x7fe9224d2d70 "home"

(gdb) p inode
$73 = 6442451366

(gdb) s
    device=66311, modifier=0x7fe914791840) at
src/libostree/ostree-repo-commit.c:1590

The conversion resulted in entirely independent files potentially
receiving the same inode.

The issue was discovered on PoC machine equipped with a large NVME
(3.4TB), but the bug can be easily reproduced using `cosa run -m 4000
--qemu-size +3TB', followed by installation of any package using
`rpm-ostree install`. The resulting deployment will be unusable due to
many files being "corrupted" by the aforementioned issue.

prepare-root: More logging in composefs, minor cleanup

- Hoist the `.ostree.cfs` to a shared constant
- Add more logging in general for extra visibility

prepare-root: Add another missing O_CLOEXEC

composefs: Factor out a shared helper for setting error

To keep the error messages consistent.

mount-util: Add missing O_CLOEXEC

Seen in review.

Merge pull request #2640 from alexlarsson/composefs

Add initial composefs integration

Merge pull request #2871 from dustymabe/dusty-fallocate-einval

lib/deploy: skip fallocate call when requested size is 0

lib/deploy: skip fallocate call when requested size is 0

If the requested size is 0 then of course we have enough room 🙂

This avoids the fallocate call returning an EINVAL.

Closes: #2869

Merge pull request #2870 from dustymabe/dusty-log-messages

lib/deploy: Disambiguate error messages for early prune space check

lib/deploy: Disambiguate error messages for early prune space check

Having the same error message in multiple places means it's not
clear which case failed. Let's make them unique.

composefs: When using signatures, delay application until first boot

We can't safely apply the fs-verity with signature until we have
booted with the new initrd, because the public key that matches the
signature is loaded from it. So, instead we save the .sig file next
to the compoosefs, and on the first boot we detect that it is there, and
the composefs file isn't fs-verity, so we apply it.

Things get a bit more complex due to having to temporarily make
/sysroot read-write for the fsverity operation too.

CI: Build with composefs on some versions

This enables --with-composefs on:
 * Fedora Latest
 * Debian Testing
 * Ubuntu Latest

These all should have new enough version of dependencies.

Update submodule: composefs

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.

ostree-remount: Don't skip remount if root is composefs

When using composefs the root fs will always be read-only, but in this
case we should still continue remounting /sysroot. So, we record a
/run/ostree-composefs-root.stamp file in ostree-prepare-root if composefs
is used, and then react to it in ostree-remount.

sysroot: Ensure deployment detection works when using composefs

In the case of composefs, we cannot compare the devino of the rootfs
and the deploy dir, because the root is the composefs mount, not a
bind mount. Instead we check the devino of the etc subdir of the
deploy, because this is a bind mount even when using composefs.

prepare-root: Support using composefs as root filesystem

This changes ostree-prepare-root to use the .ostree.cfs image as a
composefs filesystem, instead of the checkout.

By default, composefs is used if support is built in and the .ostree.cfs
file exists in the deploy dir, otherwise we fall back to the old
method. However, if the ot-composefs kernel option is specified this
can be tweaked as per:
 * off: Never use composefsz
 * maybe: Use if possible
 * on: Fail if not possible
 * signed: Fail if the cfs image is not fs-verity signed with
   a key in the keyring.
 * digest=....: Fail if the cfs image does not match the specified
   digest.

The final layout when composefs is active is:

 /        ro overlayfs mount for composefs
 /sysroot "real" root
 /etc     rw bind mount to $deploydir/etc
 /var     rw bind mount to $vardir

We also specify the $deploydir/.ostree-mnt directory as the (internal)
mountpoint for the erofs mount for composefs. This can be used to map
the root fs back to the deploy id/dir in use,

A further note: I didn't test the .usr-ovl-work overlayfs case, but a
comment mentions that you can't mount overlayfs on top of a readonly
mount. That seems incompatible with composefs. If this is needed we
have to merge that with the overlayfs that composefs itself sets up,
which is possible with the libcomposefs APIs.

switchroot: Make read_proc_cmdline_ostree() take a key argument

This changes it into read_proc_cmdline_key(), as this will later be
used to read additional keys.

composefs deploy: Store cfs signature in .ostree.cfs.sig file

In many cases, such as when using osbuild, we are not preparing the final
deployment but rather a rootfs tree that will eventually be copied to the
final location. In that case we don't want to apply the signature directly
but when the deployment is copied in place.

To make this situateion workable we also write the signature to a file
next to the composefs image file. Then whatever mechanism that does
the final copy can apply the signature.