On Fri, Oct 16, 2015 at 3:26 AM, Miroslav Suchý <msuchy(a)redhat.com> wrote:
Dne 15.10.2015 v 23:23 Alexander Ploumistos napsal(a):
> Please forgive my ignorance, but how is this supposed to be used? I
> guess it's handy to keep track of all the current keys, but unlike,
> say rpmfusion-free-release, the keys are not placed or linked in
> /etc/pki/, nor are they imported in a gpg keyring. What am I missing?
> Also, shouldn't there be "SourceX" entries for each key in the spec
Right now at least two projects (mock and fedora-upgrade) contains and use
So once this get into Fedora (and Epel) I can remove those keys from
fedora-upgrade and mock and use this common package.
Mock need CentOS and Epel keys when installing epel chroot and vice versa
when installing fedora chroots on RHEL/CentOS.
It can not use epel-release because it is not available on Fedora.
The other keys (rpmfusion and in future Copr) are there just because we
can. It is meant as safe way of delivery.
Instead of manual downloading from web and verification that the download
is correct (do you really do that?) you
download distribution-gpg-keys package. Dnf will automatically check that
gpg key of this package so you can be sure
that those keys are downloaded correctly and has not been altered by man
in the middle.
I do not want to place them to /etc/pki and automatically import them. I
will leave it up to user if he really want to
import them (or some of them) or other tools. E.g. fedora-upgrade
automatically import some of them.
I announced it here, because in past I seen several people asking about
such collection of GPG keys. They usually ended
with mock collection. So I thought that this may be useful for somebody
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
They don't get automatically imported in the first place. If they haven't
been imported before, the user is queried about the package and the key and
then it would be imported if the user allows it.
真実はいつも一つ！/ Always, there's only one truth!