The original idea here is that the result of --check is cached, so you can just run bootc status --json to get that data after invoking bootc upgrade --check. So I don't believe we need this, agreed?

Thanks for pointing that. Will have to give bootc status --json a try then.

However, right now we don't expose the diff in the status. I think it would likely make sense to do that. There's a bit of a messy thing here as we would need to probably change cached_update to be its own struct.

Also this relates to ostreedev/ostree-rs-ext#618 in that in the end we'd need to create a new ContainerImageDiff structure here anyways (because the API types for this crate need to be abstracted from those of ostree).

If I understand correctly, looking at ostreedev/ostree-rs-ext#618, all manifest diff operations cache the result in the repo, thus we need this to run as root with a writable /sysroot.

But does bootc offer an unprivileged path right now? (for usage by GNOME Software/Plasma Discover for example)

$ ostree container image pull --check test /sysroot/ostree/repo ostree-image-signed:registry:quay.io/travier/fedora-kinoite:latest
error: Preparing import: Fetching manifest: Writing cached pending manifest: Unable to write detached metadata: open(O_TMPFILE): Read-only file system

But does bootc offer an unprivileged path right now?

No. Historically the polkit/unprivileged stuff in both rpm-ostree and things like PackageKit are big, complex beasts that add a lot of security-sensitive code paths. My thinking here is that for now such a thing is probably best as a separate project on top of bootc. Or maybe we could add it as an optionally-installed secondary component here.

One thing I would say on this is that I also think many of the same concerns should apply to "workload" containers such as podman; ideally we share code there. Access to the podman (and docker) remote API is equivalent to root in practice right now, note. It may make sense to have a single component which can initiate upgrades for bootc as well as wrap e.g. https://docs.podman.io/en/latest/markdown/podman-auto-update.1.html (i.e. no ability to change system state, just do updates)

Creating a small daemon with a very limited, unprivileged DBus API would make sense. For GNOME Software/Plasma Discover, we mostly need "check for update" & "update" commands. And maybe something for "rebase/switch", but it would be hard to make this one unprivileged.

Might be needed to coordinate with the dnf team here. They already have a DBus daemon that does (a larger super set of) that.

I believe #472 (comment) covers this, please reopen if anyone disagrees.

#932 tracks the diff