Hi,
I wonder if it would be not beneficial enabling repo_gpgcheck for all centos repos? A short cross check shows that also SIG repos have repomd.xml signed. mirror.centos.org has no TLS enabled and repo_gpgcheck would add an additional security layer per default? This could be started for EL8? Or are there any barries?
-- Thanks Leon
On 9/3/20 2:40 PM, Leon Fauster via CentOS-devel wrote:
Hi,
I wonder if it would be not beneficial enabling repo_gpgcheck for all centos repos? A short cross check shows that also SIG repos have repomd.xml signed. mirror.centos.org has no TLS enabled and repo_gpgcheck would add an additional security layer per default? This could be started for EL8? Or are there any barries?
--
It is on almost all repos ..
C6, c7, and c8
The reason mirror.centos.org is not https is many machines are donated .. and could be taken away 9reclaimed) by the donors, who have physical control of the machines. We don't want 'private' keys on those donated machines and the reason we created repo_gpgcheck repos.
Am 04.09.20 um 16:08 schrieb Johnny Hughes:
On 9/3/20 2:40 PM, Leon Fauster via CentOS-devel wrote:
Hi,
I wonder if it would be not beneficial enabling repo_gpgcheck for all centos repos? A short cross check shows that also SIG repos have repomd.xml signed. mirror.centos.org has no TLS enabled and repo_gpgcheck would add an additional security layer per default? This could be started for EL8? Or are there any barries?
--
It is on almost all repos ..
C6, c7, and c8
The reason mirror.centos.org is not https is many machines are donated .. and could be taken away 9reclaimed) by the donors, who have physical control of the machines. We don't want 'private' keys on those donated machines and the reason we created repo_gpgcheck repos.
Sure, this applies to TLS. Therefore I was suggesting to enable repo_gpgcheck for all CentOS repos in the _configuration files_. The default is false or are they enabled elsewhere?
# grep repo_gpgcheck /etc/yum.repos.d/C* # echo $? 1
-- Leon
On Fri, Sep 4, 2020, at 10:36, Leon Fauster via CentOS-devel wrote:
Am 04.09.20 um 16:08 schrieb Johnny Hughes:
On 9/3/20 2:40 PM, Leon Fauster via CentOS-devel wrote:
Hi,
I wonder if it would be not beneficial enabling repo_gpgcheck for all centos repos? A short cross check shows that also SIG repos have repomd.xml signed. mirror.centos.org has no TLS enabled and repo_gpgcheck would add an additional security layer per default? This could be started for EL8? Or are there any barries?
--
It is on almost all repos ..
C6, c7, and c8
The reason mirror.centos.org is not https is many machines are donated .. and could be taken away 9reclaimed) by the donors, who have physical control of the machines. We don't want 'private' keys on those donated machines and the reason we created repo_gpgcheck repos.
Sure, this applies to TLS. Therefore I was suggesting to enable repo_gpgcheck for all CentOS repos in the _configuration files_. The default is false or are they enabled elsewhere?
# grep repo_gpgcheck /etc/yum.repos.d/C* # echo $? 1
-- Leon
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
While we want signed repodata to be *available* to folks who want to enable it, We don’t want it necessarily to be the default for all users. We want it to be a decision that folks make for their own sites.
—Brian
On 9/4/20 12:09 PM, Brian Stinson wrote:
On Fri, Sep 4, 2020, at 10:36, Leon Fauster via CentOS-devel wrote:
Am 04.09.20 um 16:08 schrieb Johnny Hughes:
On 9/3/20 2:40 PM, Leon Fauster via CentOS-devel wrote:
Hi,
I wonder if it would be not beneficial enabling repo_gpgcheck for all centos repos? A short cross check shows that also SIG repos have repomd.xml signed. mirror.centos.org has no TLS enabled and repo_gpgcheck would add an additional security layer per default? This could be started for EL8? Or are there any barries?
--
It is on almost all repos ..
C6, c7, and c8
The reason mirror.centos.org is not https is many machines are donated .. and could be taken away 9reclaimed) by the donors, who have physical control of the machines. We don't want 'private' keys on those donated machines and the reason we created repo_gpgcheck repos.
Sure, this applies to TLS. Therefore I was suggesting to enable repo_gpgcheck for all CentOS repos in the _configuration files_. The default is false or are they enabled elsewhere?
# grep repo_gpgcheck /etc/yum.repos.d/C* # echo $? 1
-- Leon
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
While we want signed repodata to be *available* to folks who want to enable it, We don’t want it necessarily to be the default for all users. We want it to be a decision that folks make for their own sites.
—Brian
Agreed.
On Fri, Sep 4, 2020 at 1:10 PM Brian Stinson brian@bstinson.com wrote:
While we want signed repodata to be *available* to folks who want to enable it, We don’t want it necessarily to be the default for all users. We want it to be a decision that folks make for their own sites.
This is a very bizarre stance to take. Enabling repo_gpgcheck for the CentOS provided repos in their repo files should not harm anything else, and only further ensures the integrity of the repository content.
Is there a compelling reason to *not* change the defaults? Because from my perspective, I don't see any.
-- 真実はいつも一つ!/ Always, there's only one truth!
Am 08.09.20 um 17:12 schrieb Neal Gompa:
On Fri, Sep 4, 2020 at 1:10 PM Brian Stinson brian@bstinson.com wrote:
While we want signed repodata to be *available* to folks who want to enable it, We don’t want it necessarily to be the default for all users. We want it to be a decision that folks make for their own sites.
This is a very bizarre stance to take. Enabling repo_gpgcheck for the CentOS provided repos in their repo files should not harm anything else, and only further ensures the integrity of the repository content.
This was exactly my motivation for asking.
After 5 years of "maturing" it could be the default now, thought.
https://lists.centos.org/pipermail/centos/2015-May/152065.html
Is there a compelling reason to *not* change the defaults? Because from my perspective, I don't see any.
But I am not sure respectively I do not have a test scenario where this could lead to a problem. Especially in the initial setup stage where dnf/yum asks to check this but do not have the key (composer, kickstart?) - or will this be ignored by dnf/yum for those scenarios? I remember asking somewhere, if the integrity in generall gets checked (anaconda or kickstart list) but got no feedback.
JFI: https://bugzilla.redhat.com/show_bug.cgi?id=998
Once the system is installed it would ask as it is done for the normal rpm checks (gpgcheck=1).
And for the suggestion of Brian: The problem that I see with "local" configurations of repo_gpgcheck is that all files are (correctly) packaged with %config(noreplace) and that would lead to more management friction ... normaly the presets are save and do not need to be altered. Or does dnf supports drop-in configs that get merged when the repo definitions are read? :-)
-- Leon
On Tue, 8 Sep 2020, Leon Fauster via CentOS-devel wrote:
I remember asking somewhere, if the integrity in generall gets checked (anaconda or kickstart list) but got no feedback.
To what end other than exercising electrons without adding certainty of more security ?
Just for the record, how do you propose to solve the MitM attack by Dr Evil substituting in a fraudulent set of signing key and 'gimmicked' rpm binary, which will cheerfully report 'all is well', post install [1]
The only way I know of is taking a couple of sums, and human sight checking them against an authoritative signed set from upstream, at install time, and every time tehreafter, rather than relying on a stored key .... but as the recent grub2 chain vulnerability indicates, a later update can compromise even seemingly cryptographiceally secured boot chains, and sneak exploited execulables in
-- Russ herrold
[1] trap doored binaries RPM signed and released to distribution https://access.redhat.com/errata/RHSA-2008:0855
On Tue, Sep 8, 2020, at 11:12 AM, Neal Gompa wrote:
On Fri, Sep 4, 2020 at 1:10 PM Brian Stinson brian@bstinson.com wrote:
While we want signed repodata to be *available* to folks who want to enable it, We don’t want it necessarily to be the default for all users. We want it to be a decision that folks make for their own sites.
This is a very bizarre stance to take. Enabling repo_gpgcheck for the CentOS provided repos in their repo files should not harm anything else, and only further ensures the integrity of the repository content.
Is there a compelling reason to *not* change the defaults? Because from my perspective, I don't see any.
The only reason might be to prevent breaking folks who regenerate the repomd locally. Not sure whether pulp preserves the original md or regenerates its own. (I always use exactly the upstream repomd for precisely this reason of avoiding breaking repo_gpgcheck, which is often on "security hardening" checklists.)
V/r, James Cassell
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Tue, Sep 08, 2020 at 02:51:19PM -0400, James Cassell wrote:
On Tue, Sep 8, 2020, at 11:12 AM, Neal Gompa wrote:
On Fri, Sep 4, 2020 at 1:10 PM Brian Stinson brian@bstinson.com wrote:
While we want signed repodata to be *available* to folks who want to enable it, We don’t want it necessarily to be the default for all users. We want it to be a decision that folks make for their own sites.
This is a very bizarre stance to take. Enabling repo_gpgcheck for the CentOS provided repos in their repo files should not harm anything else, and only further ensures the integrity of the repository content.
Is there a compelling reason to *not* change the defaults? Because from my perspective, I don't see any.
The only reason might be to prevent breaking folks who regenerate the repomd locally. Not sure whether pulp preserves the original md or regenerates its own. (I always use exactly the upstream repomd for precisely this reason of avoiding breaking repo_gpgcheck, which is often on "security hardening" checklists.)
well, no idea if the yum/dnf in CentOS/RHEL have the same issues as the Fedora versions, but there are a LOT of corner cases around signed repos.
https://bugzilla.redhat.com/show_bug.cgi?id=1247644 "dnf --cacheonly wants to import GPG key when using repo_gpgcheck"
Because dnf stores repo gpg keys in it's cache, every user has to import it/might be confused when it's not there.
https://bugzilla.redhat.com/show_bug.cgi?id=1768206 DNF prompts for GPG key import for "repo_gpgcheck=1"-repositories despite "rpm --import"-ing the keys first
This one causes dnf to prompt for the key when people don't expect it to.
and more...
There's just a lot of corner cases around this, so I would be carefull about enabling it accross the board.
kevin
On Tue, Sep 8, 2020, at 13:51, James Cassell wrote:
On Tue, Sep 8, 2020, at 11:12 AM, Neal Gompa wrote:
On Fri, Sep 4, 2020 at 1:10 PM Brian Stinson brian@bstinson.com wrote:
While we want signed repodata to be *available* to folks who want to enable it, We don’t want it necessarily to be the default for all users. We want it to be a decision that folks make for their own sites.
This is a very bizarre stance to take. Enabling repo_gpgcheck for the CentOS provided repos in their repo files should not harm anything else, and only further ensures the integrity of the repository content.
Is there a compelling reason to *not* change the defaults? Because from my perspective, I don't see any.
The only reason might be to prevent breaking folks who regenerate the repomd locally. Not sure whether pulp preserves the original md or regenerates its own. (I always use exactly the upstream repomd for precisely this reason of avoiding breaking repo_gpgcheck, which is often on "security hardening" checklists.)
V/r, James Cassell
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
There's also the fact that we make a reasonable effort to keep the repodata signatures up to date, but every signature we make is done by hand. We put our focus on delivering the bits, and delays on a repodata signature or two have been known to happen (I think I'm personally on top of the leaderboard for pushing repos before signatures by mistake, so apologies here inline for that).
Even if we were perfect, though, this is an extra part of the client/mirror relationship to troubleshoot and it seems to me that burden is best placed on folks who affirmatively know that they need this functionality.
--Brian
On Tue, Sep 8, 2020 at 7:56 PM Brian Stinson brian@bstinson.com wrote:
There's also the fact that we make a reasonable effort to keep the repodata signatures up to date, but every signature we make is done by hand. We put our focus on delivering the bits, and delays on a repodata signature or two have been known to happen (I think I'm personally on top of the leaderboard for pushing repos before signatures by mistake, so apologies here inline for that).
Yeah, when we use this feature for publishing on download.ceph.com, we've found two problems:
There's also the fact that we make a reasonable effort to keep the repodata signatures up to date, but every signature we make is done by hand. We put our focus on delivering the bits, and delays on a repodata signature or two have been known to happen (I think I'm personally on top of the leaderboard for pushing repos before signatures by mistake, so apologies here inline for that).
Yeah, when we use this feature for download.ceph.com, we've found two problems:
1) In a perfect world, we would always publish the correct repomd.xml and corresponding .asc file at the exact same time. In reality, this is difficult to perfectly accomplish this 100% of the time. The goal of "keeping the GPG material and signing process secure" is at odds with "overall ease of use".
2) When it comes to volunteer-operated mirrors, all bets are off regarding consistent updates. Mirrors update files at different times. If a CentOS mirror syncs an updated repomd.xml but not the corresponding .asc file, users hit problems.
As far as ease-of-use goes, Fedora and Red Hat use the Robosignatory project to make signing a bit more repeatable and automated, however this issue for signing repomd.xml has been open for a long time: https://pagure.io/robosignatory/issue/14
As far as the overall feature goes as implemented in DNF and Yum, https://pagure.io/releng/issue/133 has some interesting reading on this subject. Quoting from Colin Walters' comment there:
having both repomd.xml and repomd.xml.asc means two files, which introduces another race. Debian went through the same issue and recently changed to doing signatures inline: http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-e...
Colin's talking about the fact that modern versions of Apt load an "InRelease" file that contains both the metadata and the inline GPG signature, reducing the room for errors.
I'd rather see some kind of inline signature support in DNF (and MirrorManager) than see a lot of "howto" blogs talking about ignoring CentOS GPG errors because the current implementation is racy and confusing.
Top posting to answer all of you.
It now accumulated a lot of reasons to not enabling it. Corner cases, race conditions, and practical ones in a wider scope. Very interesting.
Thanks for the insights. Leon
Am 09.09.20 um 17:00 schrieb Ken Dreyer:
On Tue, Sep 8, 2020 at 7:56 PM Brian Stinson brian@bstinson.com wrote:
There's also the fact that we make a reasonable effort to keep the repodata signatures up to date, but every signature we make is done by hand. We put our focus on delivering the bits, and delays on a repodata signature or two have been known to happen (I think I'm personally on top of the leaderboard for pushing repos before signatures by mistake, so apologies here inline for that).
Yeah, when we use this feature for publishing on download.ceph.com, we've found two problems:
There's also the fact that we make a reasonable effort to keep the repodata signatures up to date, but every signature we make is done by hand. We put our focus on delivering the bits, and delays on a repodata signature or two have been known to happen (I think I'm personally on top of the leaderboard for pushing repos before signatures by mistake, so apologies here inline for that).
Yeah, when we use this feature for download.ceph.com, we've found two problems:
In a perfect world, we would always publish the correct repomd.xml and corresponding .asc file at the exact same time. In reality, this is difficult to perfectly accomplish this 100% of the time. The goal of "keeping the GPG material and signing process secure" is at odds with "overall ease of use".
When it comes to volunteer-operated mirrors, all bets are off regarding consistent updates. Mirrors update files at different times. If a CentOS mirror syncs an updated repomd.xml but not the corresponding .asc file, users hit problems.
As far as ease-of-use goes, Fedora and Red Hat use the Robosignatory project to make signing a bit more repeatable and automated, however this issue for signing repomd.xml has been open for a long time: https://pagure.io/robosignatory/issue/14
As far as the overall feature goes as implemented in DNF and Yum, https://pagure.io/releng/issue/133 has some interesting reading on this subject. Quoting from Colin Walters' comment there:
having both repomd.xml and repomd.xml.asc means two files, which introduces another race. Debian went through the same issue and recently changed to doing signatures inline: http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-e...
Colin's talking about the fact that modern versions of Apt load an "InRelease" file that contains both the metadata and the inline GPG signature, reducing the room for errors.
I'd rather see some kind of inline signature support in DNF (and MirrorManager) than see a lot of "howto" blogs talking about ignoring CentOS GPG errors because the current implementation is racy and confusing.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel