make gpgkeypath 🗝 support being a list 📓

[cgwalters]

In f244c70 we added support for importing a single file, but there are use cases for multiple such as Fedora GPG keys across major versions.

We probably should try parsing this entry as a single string first, then a list, since GKeyFile requires the trailing ; so it wouldn't be compatible to just make it a list.

[dustymabe]

now that we have a unified repo in fedora this functionality would be much appreciated as we don't really gain anything from a unified repo setup without it

[mi1os]

I actually stumbled upon this myself when I've tried to mirror atomic repo to closer server because of the poor performance when downloading to europe. Anyways the simplest way was to

ostree --repo=/srv/mirror remote  add fedora https://kojipkgs.fedoraproject.org/atomic/repo/
cat /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-{27,28,29}-primary|  ostree -v --repo=/srv/mirror remote gpg-import --stdin fedora
ostree  --repo=/srv/mirror pull --mirror --depth=-1 fedora

this way you can have as many gpg keys trusted and not rely on gpgkeypath

[miabbott]

I actually stumbled upon this myself when I've tried to mirror atomic repo to closer server because of the poor performance when downloading to europe.

I setup my own mirror in Europe too - https://faw.piratemirror.party/README.txt

I like your approach of cat'ing the keys together for the import. I might have to adjust my mirror to do the same!

[cgwalters]

See also rpm-software-management/libdnf#43 - libdnf basically auto-imports all the keys in the filesystem, which we could support that too.

[dustymabe]

libdnf basically auto-imports all the keys in the filesystem, which we could support that too.

+1

[nullr0ute]

Support for key rollover is important for IoT use cases.

[cgwalters]

Note that since the very beginning libostree has supported providing multiple keys in /usr/share/ostree/trusted.gpg.d/ and more recently, each remote can have its own keyring.

This issue came about because those paths are distinct from the libdnf stack, but one can definitely do multiple keys with libostree today, it just involves duplicating the rpm ones - for people using rpm-ostree, which is not all libostree users.

[dustymabe]

would a PR for having OSTree auto-import all the keys in the filesystem under /etc/pki/rpm-gpg/ be accepted?

[cgwalters]

would a PR for having OSTree auto-import all the keys in the filesystem under /etc/pki/rpm-gpg/ be accepted?

Stated like that...no. I mean, if I'm using Flatpak on Debian, it doesn't make sense to look at /etc/pki/rpm-gpg for anything right?

We could add gpgkeyglob=/etc/pki/rpm-gpg/RPM-GPG-KEY-* or so.

I would note though this particular problem is also solved with rojig as in rpm-ostree we can more easily tell libostree to trust the same keys trusted for RPMs that were loaded via libdnf.

[dustymabe]

Stated like that...no. I mean, if I'm using Flatpak on Debian, it doesn't make sense to look at /etc/pki/rpm-gpg for anything right?

correct..

We could add gpgkeyglob=/etc/pki/rpm-gpg/RPM-GPG-KEY-* or so.

Something like that is actually what I meant. Sorry for not being more thorough before. How about something like this where we can mix/match if needed:

• gpgkeypath=/path/to/file
• gpgkeypath=/path/to/file,/path/to/another/file
• gpgkeypath=/path/to/directory/

So we support a single file, a list of files, or a path to a directory where all files are to be imported (or a combination of the 3). Theoretically we could add globbing in there but maybe extra credit?

I would note though this particular problem is also solved with rojig as in rpm-ostree we can more easily tell libostree to trust the same keys trusted for RPMs that were loaded via libdnf.

yep. that's true

[rfairley]

If this is available to pick up and work on, I'd be happy to work on this :)