Hiyas,
now that the groups repo is not used anymore in mock, imho the gpgcheck option can be enabled by default and only be disabled for the local repo. It will only need the required gpg-keys be included in the mock rpm and some more lines in the config files. I will write a patch for this if you will apply it.
Regards, Till
On Sun, Nov 18, 2007 at 11:01:40PM +0100, Till Maas wrote:
Hiyas,
now that the groups repo is not used anymore in mock, imho the gpgcheck option can be enabled by default and only be disabled for the local repo. It will only need the required gpg-keys be included in the mock rpm and some more lines in the config files. I will write a patch for this if you will apply it.
This sounds reasonable. I can queue it up for 0.8.9. As long as the patch is sane, I dont see why we cant do something like this. -- Michael
On Monday 19 November 2007 09:01:59 Michael E Brown wrote:
On Sun, Nov 18, 2007 at 11:01:40PM +0100, Till Maas wrote:
now that the groups repo is not used anymore in mock, imho the gpgcheck option can be enabled by default and only be disabled for the local repo. It will only need the required gpg-keys be included in the mock rpm and some more lines in the config files. I will write a patch for this if you will apply it.
This sounds reasonable. I can queue it up for 0.8.9. As long as the patch is sane, I dont see why we cant do something like this.
One problem here is, that mock should then contain a copy of the Fedora public rpm keys, because otherwise it would not work to build Fedora rpms on a rhel or centos machine. Would it be ok, to include them at these locations?
/etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora /etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora-rawhide /etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora-test
Regards, Till
On Sat, 15 Dec 2007 16:07:30 +0100 Till Maas opensource@till.name wrote:
One problem here is, that mock should then contain a copy of the Fedora public rpm keys, because otherwise it would not work to build Fedora rpms on a rhel or centos machine. Would it be ok, to include them at these locations?
/etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora /etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora-rawhide /etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora-test
Couldn't the repo configs just point to the online version of it, and have yum download the key when needed? (or if it's already on the file system use it?)
On Saturday 15 December 2007 16:34:44 Jesse Keating wrote:
Couldn't the repo configs just point to the online version of it, and have yum download the key when needed? (or if it's already on the file system use it?)
It is possible afaik, but it is less secure, because yum can not check, whether or not the downloaded key is really the wanted. It would work, if the download url is an https one and there is a good certificate used and yum verifies whether or not the certificate is valid. But imho shipping the gpg keys with mock is less error-prone.
Regards, Till
On Sat, Dec 15, 2007 at 08:40:25PM +0100, Till Maas wrote:
On Saturday 15 December 2007 16:34:44 Jesse Keating wrote:
Couldn't the repo configs just point to the online version of it, and have yum download the key when needed? (or if it's already on the file system use it?)
It is possible afaik, but it is less secure, because yum can not check, whether or not the downloaded key is really the wanted. It would work, if the download url is an https one and there is a good certificate used and yum verifies whether or not the certificate is valid. But imho shipping the gpg keys with mock is less error-prone.
So lets see if we can work this out.
It looks to me like the goal of adding gpg key support is to add some stricter security guarantees around mock builds. It would be nice if you could codify exactly what you think the security guarantee should look like, and what are the possible attack vectors against this. This should guide us in resolving this.
Yum uses urllib underneath to download stuff. I assume it would support https, but I dont know anything about how it verifies certificates.
On the other hand, shipping the GPG keys with mock creates a maintenance overhead, but one that I dont think is very large. These keys dont ever (afaik) change, so it should be just a one time thing to get them in and the configs set up. -- Michael
On Thu, 2008-01-03 at 15:31 -0600, Michael E Brown wrote:
So lets see if we can work this out.
It looks to me like the goal of adding gpg key support is to add some stricter security guarantees around mock builds. It would be nice if you could codify exactly what you think the security guarantee should look like, and what are the possible attack vectors against this. This should guide us in resolving this.
Yum uses urllib underneath to download stuff. I assume it would support https, but I dont know anything about how it verifies certificates.
it uses urlgrabber which uses urllib[2] underneath. ssl connections specific ca to focus on.
but what does this have to do with gpg certs? gpg certs aren't ssl certs.
-sv
On Do Januar 3 2008, seth vidal wrote:
it uses urlgrabber which uses urllib[2] underneath. ssl connections specific ca to focus on.
but what does this have to do with gpg certs? gpg certs aren't ssl certs.
When yum (rpm?) verifies ssl certificates for https urls to acquire gpgkeys, it is possible to use these urls in the mock config, without losing (much) security.
Regards, Till
On Thu, 2008-01-03 at 23:18 +0100, Till Maas wrote:
On Do Januar 3 2008, seth vidal wrote:
it uses urlgrabber which uses urllib[2] underneath. ssl connections specific ca to focus on.
but what does this have to do with gpg certs? gpg certs aren't ssl certs.
When yum (rpm?) verifies ssl certificates for https urls to acquire gpgkeys, it is possible to use these urls in the mock config, without losing (much) security.
too many options here: 1. rpm has nothing to do, in yum, with downloading gpg keys or packages. 2. you want to use an ssl cert to verify the location we're retrieving the gpg keys from? And you want to use a special CA to guarantee we have the right one? 3. What's the LOSS of security you're worried with?
-sv
On Thu, Jan 03, 2008 at 05:22:27PM -0500, seth vidal wrote:
On Thu, 2008-01-03 at 23:18 +0100, Till Maas wrote:
On Do Januar 3 2008, seth vidal wrote:
it uses urlgrabber which uses urllib[2] underneath. ssl connections specific ca to focus on.
but what does this have to do with gpg certs? gpg certs aren't ssl certs.
When yum (rpm?) verifies ssl certificates for https urls to acquire gpgkeys, it is possible to use these urls in the mock config, without losing (much) security.
too many options here:
- rpm has nothing to do, in yum, with downloading gpg keys or packages.
- you want to use an ssl cert to verify the location we're retrieving
the gpg keys from? And you want to use a special CA to guarantee we have the right one? 3. What's the LOSS of security you're worried with?
I believe that Till is concerned with establishing a chain-of-trust so that we know the output RPMs from mock are good. This chain starts at the mock binary and goes to the mirror we download the RPMs from for the chroot. We have to have a way to know that what we are downloading from the mirror has not been compromised in any way.
Till, from a maintenance standpoint, I favor simply adding an https url for the gpg keys. From a security perspective, it would most likely be best if mock included the respective keys.
If mock is going to include keys, you should name them after the respective mock configs so it is easy to see when we can drop specific keys. RPM-GPG-KEY-fedora-8-x86_64 or something similar. -- Michael
On Thu, Jan 03, 2008 at 04:57:45PM -0600, Michael E Brown wrote:
On Thu, Jan 03, 2008 at 05:22:27PM -0500, seth vidal wrote:
On Thu, 2008-01-03 at 23:18 +0100, Till Maas wrote:
On Do Januar 3 2008, seth vidal wrote:
it uses urlgrabber which uses urllib[2] underneath. ssl connections specific ca to focus on.
but what does this have to do with gpg certs? gpg certs aren't ssl certs.
When yum (rpm?) verifies ssl certificates for https urls to acquire gpgkeys, it is possible to use these urls in the mock config, without losing (much) security.
too many options here:
- rpm has nothing to do, in yum, with downloading gpg keys or packages.
- you want to use an ssl cert to verify the location we're retrieving
the gpg keys from? And you want to use a special CA to guarantee we have the right one? 3. What's the LOSS of security you're worried with?
I believe that Till is concerned with establishing a chain-of-trust so that we know the output RPMs from mock are good. This chain starts at the mock binary and goes to the mirror we download the RPMs from for the chroot. We have to have a way to know that what we are downloading from the mirror has not been compromised in any way.
Till, from a maintenance standpoint, I favor simply adding an https url for the gpg keys. From a security perspective, it would most likely be best if mock included the respective keys.
If mock is going to include keys, you should name them after the respective mock configs so it is easy to see when we can drop specific keys. RPM-GPG-KEY-fedora-8-x86_64 or something similar.
Looking at this further, not a *huge* deal, but if you add the actual files to the mock rpm, this will break my unit tests unless you manually copies the files into place before running the tests. -- Michael
On Do Januar 3 2008, Michael E Brown wrote:
It looks to me like the goal of adding gpg key support is to add some stricter security guarantees around mock builds. It would be nice if you could codify exactly what you think the security guarantee should look like, and what are the possible attack vectors against this. This should guide us in resolving this.
Using gpg support for mock builds makes the resulting rpm packages more trustworthy, because then the rpms used to populate the chroot can be trusted to be the official Fedora/CentOS ones. This is e.g. useful for uses that have internet access via an untrusted network, e.g. on conferences or at universities. There easily man in the middle attacks can occur, e.g. via arp or dns cache poisining or on conferences via rogue dhcp servers. And it also prevents against bad mirrors. Basically, using gpg for mock chroots has the same advantages as using gpg for a normal system.
On the other hand, shipping the GPG keys with mock creates a maintenance overhead, but one that I dont think is very large. These keys dont ever (afaik) change, so it should be just a one time thing to get them in and the configs set up.
Even when only URLS are used that point to the keys, once the keys change, it is very likely that the URL changes, too. But I guess this will not happen for a specific release, so only when new config files for a new Fedora or CentOS release are created, maybe the gpg keys need to be adjusted.
Regards, Till
On Thu, Jan 03, 2008 at 11:15:21PM +0100, Till Maas wrote:
On Do Januar 3 2008, Michael E Brown wrote:
It looks to me like the goal of adding gpg key support is to add some stricter security guarantees around mock builds. It would be nice if you could codify exactly what you think the security guarantee should look like, and what are the possible attack vectors against this. This should guide us in resolving this.
Using gpg support for mock builds makes the resulting rpm packages more trustworthy, because then the rpms used to populate the chroot can be trusted to be the official Fedora/CentOS ones. This is e.g. useful for uses that have internet access via an untrusted network, e.g. on conferences or at universities. There easily man in the middle attacks can occur, e.g. via arp or dns cache poisining or on conferences via rogue dhcp servers. And it also prevents against bad mirrors. Basically, using gpg for mock chroots has the same advantages as using gpg for a normal system.
I would probably just focus the discussion on 'bad mirrors' or 'evil mirrors', as the other cases discussed are all just derivatives of this case (afaict).
On the other hand, shipping the GPG keys with mock creates a maintenance overhead, but one that I dont think is very large. These keys dont ever (afaik) change, so it should be just a one time thing to get them in and the configs set up.
Even when only URLS are used that point to the keys, once the keys change, it is very likely that the URL changes, too. But I guess this will not happen for a specific release, so only when new config files for a new Fedora or CentOS release are created, maybe the gpg keys need to be adjusted.
There is an exceedingly slight advantage to having to change only a URL in a config file over having to download and include another file. There is also the advantage that if we support lots of default configs, we dont have to ride herd on a directory full of gpg keys. (and knowning when to expire them or download new ones.)
I am leaning myself towards trying if at all possible to simply use a gpg key url. -- Michael
buildsys@lists.fedoraproject.org
-
Jesse Keating -
Michael E Brown -
Seth Vidal -
Till Maas