On 1/11/22 17:18, Colin Walters wrote:
On Tue, Jan 11, 2022, at 4:00 AM, Panu Matilainen wrote:
The point was though, that the rpmdb is not at all the only data of this
kind and so having a dedicated home makes sense.
You mentioned dnf/yum/PackageKit data; there's two kinds of that. One is e.g.
/var/cache/dnf which does *not* move. It's just a cache. (Now there is this whole
other very interesting thread around "why don't we include a cache of the
rpm-md inside e.g. ostree or container images? And the reason why not is we don't
want to have to respin all images every time a package not in the image changes)
dnf does have its own outside-of-rpm state database in /var/lib/dnf which is closer to
this. The situation with that is messier. AIUI this proposal so far is not calling for
moving this. Where it lives and how it's versioned has strong implications for the
people who want to support snapshot/rollback. But it's not relevant for rpm-ostree,
which does not use this part of libdnf. We maintain our own little "state
file" - for lots more detail on this, see
https://github.com/coreos/rpm-ostree/issues/2326
(And it's important to note that rpm-ostree's origin file has almost nothing
*unless* one explicitly engages client-side layering/overrides)
For one, /state (or whatever toplevel directory) allows for the fact
that there are write-operations to rpmdb that do not touch any external
files while maintaining read-only /usr. Such as rpmdb --rebuilddb,
`rpmdb --rebuilddb` is basically about supporting switching from e.g. bdb to
sqlite, right?
On the rpm-ostree side at least, the default format comes from the base image;
there's no reason to directly support `rpmdb --rebuilddb` as something any
normal user or admin would need.
No, it's a database maintenance/repair operation. Converting between
formats is merely a convenient side-effect.
or rpm --import.
OK yes, this (along with rpms that install into /opt as you mentioned) are I think the
biggest examples of "rpmdb has stuff not about /usr".
rpm --import actually encapsulates really well all the problems and benefits
with everything we're trying to do. I have a big related blurb here
https://github.com/rpm-software-management/libdnf/issues/43
But as I understand it, the creation of /etc/pki/rpm-gpg was at least partially motivated
by the fact that in the traditional RPM model, the fact that GPG keys are stored in the
rpmdb meant there was no way to update them "in band" of a default rpm
operation. Today Fedora ships these GPG keys as an RPM which hence contain files, and
when you type `yum upgrade` (or rpm-ostree upgrade) you get updates to those files, the
same as other files. Now, as noted in the issue PackageKit (whose code was the
precursor to libdnf, which has the code that rpm-ostree uses but AFAIK still not current
dnf which has this logic in Python) auto-imports all of them. I am not completely sure
how updating the rpmdb with new e.g. Fedora GPG key works. It might be part of
system-upgrade or something?
And then this all relates to a higher level goal we have with "image based updates",
which is avoiding (or minimizing as much as possible) per-system hysteresis or "unmanaged
state", particularly opaque (hard to see/diagnose/inspect) state.
This set of trusted GPG keys stored in the rpmdb is both. The set of keys will
just keep growing across in-place upgrades, depending on the initial Fedora
version installed. And wh And this is security-relevant state, it's the set of
trusted keys for RPM. Now, I am sure a number of sysadmins do understand that
the rpmdb contains GPG keys. I'd bet a whole lot don't. I definitely think
that it's confusing to have both /etc/pki/rpm-gpg *and* keys stored in the
rpmdb. Of the two, I think the former - i.e. text files one can edit with
standard tools - is much easier to understand and work with. It's also already
in a place that is designed for users to edit in `/etc`.
So by moving the rpmdb to /usr, it's basically saying that `rpm --import`
should change.
This doesn't seem to be documented as a dependency of this move...
That said, this design could also clearly use some "systemd style" config
model. ostree already supports /usr/share/ostree/trusted.gpg.d which is designed for
keys shipped by the OS vendor. But, what's really tricky about this is we want to
support in-place updates from previous versions (i.e. at least N-1), but hopefully not
too old versions. Well, this is leading to a tangent so I'll cut off this sub-thread.
The TL;DR for me is: I think everyone agrees that moving the rpmdb as it is
today to /usr is not 100% a perfect fit. But it's a ~90% fit - almost all the
raw data is just headers which are clearly immutable data generated elsewhere.
And by making this change, we're basically saying we'll fix the remaining 10%
of cases.
Note for the people who are trying to do "client side snapshot/rollback" (i.e. the people whose
names are attached to the Change), the rpmdb is still mutable by default. And I think their idea is is that
by doing a "snapshot, then upgrade in place via traditional rpm/yum methods" approach, the blast
radius is then contained to what happens on explicit rollback. And that's then very limited to e.g. "I
wanted to add a 3rd party RPM and did `rpm --import` to trust their key and then rolled back and lost that
change" which is clearly not a big deal.
For rpm-ostree's "image based" updates model, to avoid hysteresis we always
construct a *new* root (just hardlinked) so any manual outside-of-rpm-ostree's control
changes to `/usr` will always be thrown away, and that's why it's read-only. So having
`rpm --import` fail is intentional today.
But, I hope we can get agreement about something like having `rpm --import`
write to `/etc/pki/rpm-gpg` and dropping gpg keys from the rpmdb.
Rpm actually supports a keyring from the fs since 4.6 I think, it's just
not integrated with --import and doesn't play that well along with the
rest of the ecosystem because everything expects those gpg-pubkey
"packages". We had bugs filed because somebody tried to use the fs-based
thing but yum broke up.
The problem with fs based keyring is that packages can drop arbitrary
unrelated keys in there, combined with the rpm model of imported ==
trusted. The trust aspect would have to be maintained in a place not
directly accessible to packages.
That imported == trusted implication is of course a long-standing flaw
in rpm but difficult to change because of all the assumptions that have
been built around it. Everybody (me included) loves to hate the
gpg-pubkey headers as we know them, but rpmdb as a keyring storage does
make sense. I mean, rpmdb is data which rpm knows, and is free to store
whatever it wishes there. Do understand that Fedora or anybody else
moving it to /usr will not prevent rpm from adding more features that
may need to modify it to store further data. So while it may seem "okay"
now, it may as well not be that way in the future.
- Panu -
- Panu -
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
