Hello,
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 file?

As far as I understand, copr will try include all his keys in
distribution-gpg-keys , not the reverse, copr have RPMFusion keys , so
just help on a secure installation of RPMFusion packages by end
users ..., so don't see what RPMFusion guys could comment :)
Thanks,
--
Sérgio M. B.

Hello,
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 file?

Right now at least two projects (mock and fedora-upgrade) contains and use those keys.
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 too.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys

Right now at least two projects (mock and fedora-upgrade) contains
and use those keys.
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?)

When it comes to keys on my systems, yes, I tend to get _that_ paranoid.
Btw, what about upstream links to the keys in the spec file?

I did not use SourceX in spec file, because my source is tar.gz file created from github.
This make the maintenance more easier.
However - good idea - I will create some documentation file, where I document from where
those files were obtained.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys

Dne 15.10.2015 v 23:23 Alexander Ploumistos napsal(a):
> Hello,
>
> 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
file?
>
Right now at least two projects (mock and fedora-upgrade) contains and use
those keys.
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
too.
--
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!

fedora-repos should have all the keys needed for upgrade. So the only thing needing the
keys is mock. However I'm not sure you should include rpmfusion keys in Fedora.
Dennis
On October 16, 2015 2:26:16 AM CDT, "Miroslav Suchý" <msuchy(a)redhat.com&gt;
wrote:

Dne 15.10.2015 v 23:23 Alexander Ploumistos napsal(a):
> Hello,
>
> 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
file?
>
Right now at least two projects (mock and fedora-upgrade) contains and
use those keys.
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
too.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

fedora-repos should have all the keys needed for upgrade. So the only
thing needing the keys is mock. However I'm not sure you should include rpmfusion keys
in Fedora.

On a related note, something that I thought about when trying to
verify old Fedora keys...
Would it be possible for people who create those keys (or other people
from release-engineering who can verify that they keys are correct) to
sign them with their private keys and upload the resulting signatures
to public key servers? It would provide an additional verification
path. Distribution package signing keys are important enough for this
to be worth the extra work imho.
Zbyszek

On Fri, Oct 16, 2015 at 07:37:15PM -0500, Dennis Gilmore wrote:
> fedora-repos should have all the keys needed for upgrade. So the only thing needing
the keys is mock. However I'm not sure you should include rpmfusion keys in Fedora.
On a related note, something that I thought about when trying to
verify old Fedora keys...
Would it be possible for people who create those keys (or other people
from release-engineering who can verify that they keys are correct) to
sign them with their private keys and upload the resulting signatures
to public key servers? It would provide an additional verification
path. Distribution package signing keys are important enough for this
to be worth the extra work imho.

Well if that needs to be done it should be maintained by rel-eng, but
ultimately there might be a better way to deal with it than
duplicating a bunch of files.

On Sat, Oct 17, 2015 at 2:46 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
> On Fri, Oct 16, 2015 at 07:37:15PM -0500, Dennis Gilmore wrote:
>> fedora-repos should have all the keys needed for upgrade. So the only thing
needing the keys is mock. However I'm not sure you should include rpmfusion keys in
Fedora.
>
> On a related note, something that I thought about when trying to
> verify old Fedora keys...
> Would it be possible for people who create those keys (or other people
> from release-engineering who can verify that they keys are correct) to
> sign them with their private keys and upload the resulting signatures
> to public key servers? It would provide an additional verification
> path. Distribution package signing keys are important enough for this
> to be worth the extra work imho.
Well if that needs to be done it should be maintained by rel-eng, but
ultimately there might be a better way to deal with it than
duplicating a bunch of files.

Would it be possible for people who create those keys (or other
people
from release-engineering who can verify that they keys are correct) to
sign them with their private keys and upload the resulting signatures
to public key servers? It would provide an additional verification
path. Distribution package signing keys are important enough for this
to be worth the extra work imho.