Hi there,
I stumbled upon an older post by Johnny Hughes about gpg-checking the repository metadata. [1] In the mean time, we seem to have signed metadata not only for "updates", but also for "base", "extras" and "centosplus" (just the "base" signature for CentOS Linux 6 is missing).
What are the reasons for not enabling the repo gpg check in our default installation? Would it be a bad idea to do that in our Vagrant images?
Best regards, Laurențiu
[1] https://seven.centos.org/2015/05/signed-repository-metadata-is-now-available...
On 05/01/17 09:22, Laurentiu Pancescu wrote:
Hi there,
I stumbled upon an older post by Johnny Hughes about gpg-checking the repository metadata. [1] In the mean time, we seem to have signed metadata not only for "updates", but also for "base", "extras" and "centosplus" (just the "base" signature for CentOS Linux 6 is missing).
What are the reasons for not enabling the repo gpg check in our default installation? Would it be a bad idea to do that in our Vagrant images?
if all the metadata is now signed, the corresponding centos-release can carry the gpgcheck enabled.
as a distro flag - this is a huge change. We just need to make sure ( quantify ? ) that we dont break existing installs. In most cases, this is just a case of orchestrating it right ( ie, maybe centos-release with the enabled flag needs to the staged out, in a way that only people with all the repos signed are going to see this new file, and do it as a second cycle ).
Regards
On 05/01/17 14:32, Karanbir Singh wrote:
if all the metadata is now signed, the corresponding centos-release can carry the gpgcheck enabled.
I was thinking about enabling repo_gpgcheck only for the official CentOS repos - the ones which are signed. I just went through CentOS-*.repo to find which repos are signed in c6 and c7:
- base (c7 only) - updates - extras - centosplus - CR - fasttrack
The debuginfo repo, all repos on vault.centos.org and C6 base are not signed right now. Are there any plans to sign C6 base?
as a distro flag - this is a huge change. We just need to make sure ( quantify ? ) that we dont break existing installs. In most cases, this is just a case of orchestrating it right ( ie, maybe centos-release with the enabled flag needs to the staged out, in a way that only people with all the repos signed are going to see this new file, and do it as a second cycle ).
How would one generate a patch to enable checking just the relevant repos? I cloned the c7 branch of rpms/centos-release.git, but, except for CentOS-CR.repo, which has its own patch creating it from scratch, the other ones appear to be simply copied from %{buildroot}. What would be the best way: to have this change in the files being copied, or an additional patch, like for CR? In any case, we should be careful not to enable this for C5, since the .spec file seems to be used for all releases. Or maybe I'm looking at the wrong sources?
Thanks, Laurențiu
On 01/05/2017 09:20 AM, Laurentiu Pancescu wrote:
On 05/01/17 14:32, Karanbir Singh wrote:
if all the metadata is now signed, the corresponding centos-release can carry the gpgcheck enabled.
I was thinking about enabling repo_gpgcheck only for the official CentOS repos - the ones which are signed. I just went through CentOS-*.repo to find which repos are signed in c6 and c7:
- base (c7 only)
- updates
- extras
- centosplus
- CR
- fasttrack
The debuginfo repo, all repos on vault.centos.org and C6 base are not signed right now. Are there any plans to sign C6 base?
I will sign that for 6.9 for sure .. I was holding off on the current 6.8 repo, although theoretically it does not impact anything if I do sign and put on there too (6.8).
The reason I would not do it would be that we have an Everything ISO for C7 and the older ones did not have signed repodata, so I don't want a different repo on ISO than on the mirrors.
But for C6 that is not really applicable, because anaconda splits the ISOs separately and the ISO metadata does not match the repo metadata anyway. So, if it would help to standarize things, I can put a signed metadata file on the c6.8 base repo.
As to vault and debuginfo .. I don't want to revise the vault (that is what was released, and those are not really supported, just published). Debuginfo is also problematic as scripts rebuild metadata as required there and it would be a huge change in process to try to roll in signing there. If we really, really need it then we could but I would rather not do so.
<snip>
On 05/01/17 16:56, Johnny Hughes wrote:
I will sign that for 6.9 for sure .. I was holding off on the current 6.8 repo, although theoretically it does not impact anything if I do sign and put on there too (6.8).
The reason I would not do it would be that we have an Everything ISO for C7 and the older ones did not have signed repodata, so I don't want a different repo on ISO than on the mirrors.
I first tried to produce a patch for rpms/centos-release, but after "git clone --branch c7 https://git.centos.org/git/rpms/centos-release.git/" I noticed that the repo hasn't yet been updated for 7.3.1611, and centos-release-7-2.1511.tar.gz isn't included. I couldn't find any c6 branch, either, so I ended up producing patches against the default .repo files from our official Vagrant images (attached, tested locally).
Would it be ok in this form? The only disadvantage I see is being asked to trust the official CentOS key several times during the first "yum update" (instead of just once).
Thanks, Laurențiu
On 01/06/2017 03:49 AM, Laurentiu Pancescu wrote:
On 05/01/17 16:56, Johnny Hughes wrote:
I will sign that for 6.9 for sure .. I was holding off on the current 6.8 repo, although theoretically it does not impact anything if I do sign and put on there too (6.8).
The reason I would not do it would be that we have an Everything ISO for C7 and the older ones did not have signed repodata, so I don't want a different repo on ISO than on the mirrors.
I first tried to produce a patch for rpms/centos-release, but after "git clone --branch c7 https://git.centos.org/git/rpms/centos-release.git/" I noticed that the repo hasn't yet been updated for 7.3.1611, and centos-release-7-2.1511.tar.gz isn't included. I couldn't find any c6 branch, either, so I ended up producing patches against the default .repo files from our official Vagrant images (attached, tested locally).
Would it be ok in this form? The only disadvantage I see is being asked to trust the official CentOS key several times during the first "yum update" (instead of just once).
Right, the only real issue is more trust requests for the same key.
On 12/01/17 16:16, Johnny Hughes wrote:
On 01/06/2017 03:49 AM, Laurentiu Pancescu wrote:
Would it be ok in this form? The only disadvantage I see is being asked to trust the official CentOS key several times during the first "yum update" (instead of just once).
Right, the only real issue is more trust requests for the same key.
Then, which is the earliest time we could enable this? 7.4?
I tried to avoid the "importing key" prompt by importing the key in advance, according to the documentation I found:
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 # rpm -qa gpg-pubkey* gpg-pubkey-f4a80eb5-53a7ff4b # rpm -qi gpg-pubkey-f4a80eb5-53a7ff4b Name : gpg-pubkey Version : f4a80eb5 Release : 53a7ff4b Architecture: (none) Install Date: Thu 12 Jan 2017 04:16:24 PM UTC Group : Public Keys Size : 0 License : pubkey Signature : (none) Source RPM : (none) Build Date : Mon 23 Jun 2014 10:19:55 AM UTC Build Host : localhost Relocations : (not relocatable) Packager : CentOS-7 Key (CentOS 7 Official Signing Key) security@centos.org Summary : gpg(CentOS-7 Key (CentOS 7 Official Signing Key) security@centos.org) Description : [skipped due to verbosity]
But I'm still asked during the first "yum update", several times for the same key - the fingerprint displayed during each prompt matches the key I had already imported. Could anyone shed some light on what's going on? Perhaps because we have a gpgkey setting in the .repo file?
Thanks, Laurențiu
-
Johnny Hughes -
Karanbir Singh -
Laurentiu Pancescu