| Summary: | New instructions for verifying keys | ||
|---|---|---|---|
| Product: | Infrastructure | Reporter: | Aniruddha <mailingdotlist> |
| Component: | Websites | Assignee: | Nicolas Chauvet <kwizart> |
| Status: | RESOLVED EXPIRED | ||
| Severity: | normal | CC: | fedora, lxtnow, mailingdotlist, sergio |
| Priority: | P5 | ||
| Version: | NA | ||
| Hardware: | All | ||
| OS: | GNU/Linux | ||
| See Also: |
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3532 https://bugzilla.rpmfusion.org/show_bug.cgi?id=3313 |
||
| namespace: | |||
|
Description
Aniruddha
2015-05-30 10:54:42 CEST
I made some additional changes: Verify 1 Download the keys for your Fedora version from http://rpmfusion.org/keys 2 Import the keys into RPM's database by hand using the following command: #rpm --import KEY 3 Verify rpm's with # rpm -K 4 Verify that the keys installed on your system match the keys listed on rpmfusion.org/keys with gpg --quiet --with-fingerprint /etc/pki/rpm-gpg/KEY For more infomation on how to manage keys in rpm see: man rpmkeys For example for Fedora 22 the steps would be 1 Download RPM-GPG-KEY-rpmfusion-free-fedora-21 and RPM-GPG-KEY-rpmfusion-nonfree-fedora-22 from http://rpmfusion.org/keys 2 # rpm --import RPM-GPG-KEY-rpmfusion-free-fedora-22 # rpm --import RPM-GPG-KEY-rpmfusion-nonfree-fedora-22 3 $ rpm -K rpmfusion-free-release-22.noarch.rpm rpmfusion-free-release-22.noarch.rpm: rsa sha1 (md5) pgp md5 OK $ rpm -K rpmfusion-nonfree-release-22.noarch.rpm rpmfusion-nonfree-release-22.noarch.rpm: rsa sha1 (md5) pgp md5 OK 4 gpg --quiet --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-22 pub 4096R/97F4D1C1 2013-12-15 RPM Fusion free repository for Fedora (22) <rpmfusion-buildsys@lists.rpmfusion.org> Key fingerprint = 5065 885A 371C 6200 3ED7 AC4F 81C9 B423 97F4 D1C1 $ gpg --quiet --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-22 pub 4096R/A6708DA3 2013-12-15 RPM Fusion nonfree repository for Fedora (22) <rpmfusion-buildsys@lists.rpmfusion.org> Key fingerprint = BAD2 40A4 79FF 87E7 791E 105F 27D7 7A09 A670 8DA3 Check of these match with the keys on http://rpmfusion.org/keys Ok, so now that the wiki is served over https, let's review this change request. long story short, it's a bootstrapping issue. The main issue is: -> where to start the trust from ? In the previous case, we've considered that users found our wiki somehow and that the primary point to roll the trust between users and us. The trusting decision is to install the rpm release* package. That will only guaranty that a later package installation comes from the same origin that the primary rpmfusion-*-release package (and we only guarantied that). In this setup, gpg is an internal means. RPM will ask the users to verify the gpg key based on the repository definition and the provided key only on the next package install from the repo. This verification is a second guard step to make sure the installation setup is coherent. I agree that the current situation can be improved. Here are some elements that can make the process safer: - wiki has been migrated to https - our GPG keys have been provided into the distribution-gpg-keys Your change seems to imply to make gpg a primary start point for the installation process. I think it's valuable improvement, but I wonder if that can be made more easy using dnf repomanage instead ? None provided an updated process. Closing as expired. |