[opensuse-buildservice] RFC: OBS repository security enhancements
We would like to increase the security level when using repository from the OBS by making the repository ownerships more visible. This is hardly possible atm (but not impossible) since we use the same gpg key for all projects. Here are our ideas (together with our security team), any input is appreciated. Requirements: * Make it obvious to the user that adding a repository from another project needs again to trust in it (because different people will have write access there). The installer should point the user to this and ask for his trust on it. * It should work with existing distributions best as possible, of course esp. with openSUSE distris and YaST installer. But of course it should work as good as possible with any other package manager. What we plan to do is * Each project will get an own gpg key, which is used to sign the packages and repository meta files. * The new generated public key gets signed with a global OBS key, so people can check, if the the repository got build indeed for the OBS (this means you can trust that the binaries come from the sources hosted on OBS). * We do not sign any repository anymore with the global OBS key, but generate a key for each existing project Known problems: * People who currently use repositories from OBS will need to import the new gpg key(s). Otherwise the package managers will report errors. Possible future enhancements: * YaST should show which keys signed a pubkey about to get imported. * Allow upload of privates to be used to sign repos ? These keys *must not* get signed by the global OBS key, since they can be used elsewhere. * Does it make sense allow to reuse one key for multiple projects ? Does anyone want to have this at all ? Implementation: * the signing instance stays to be read - only. * The global OBS key remains to be on the signing instance only. * Generated private keys get stored encrypted (with OBS global key) on general storage server to keep signing host an instance without needed backup. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de ------------------------------------------------------- -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wed, 5 Sep 2007, Adrian Schröter wrote:
* People who currently use repositories from OBS will need to import the new gpg key(s). Otherwise the package managers will report errors.
Is signing with two keys possible? If so use a new buildservice key and still sign all packages with the old one (at least for older distributions). Add multi-key handling for openSUSE 10.3 and start using it there.
* Allow upload of privates to be used to sign repos ? These keys *must not* get signed by the global OBS key, since they can be used elsewhere.
Don't think this is useful. I would not upload any of my private keys. But I would like to sign my repository-key with my private key. The buildservice should then provide the signed public keys.
* Does it make sense allow to reuse one key for multiple projects ? Does anyone want to have this at all ?
- If multiple signatures are possible, this would be useful. - Also it would be required to have only one key for subprojects (e.g. Education:xxx) Ciao -- http://www.dstoecker.eu/ (PGP key available)
On Wed, Sep 05, 2007 at 06:13:07PM +0200, Dirk Stoecker wrote:
On Wed, 5 Sep 2007, Adrian Schröter wrote:
* People who currently use repositories from OBS will need to import the new gpg key(s). Otherwise the package managers will report errors.
Is signing with two keys possible? If so use a new buildservice key and still sign all packages with the old one (at least for older distributions). Add multi-key handling for openSUSE 10.3 and start using it there.
It is possible and we thought about it. The problem is that you can remove signatures from .asc files later on, just leaving one in them without knowing the private key of the one left. (A GPG signature is just a stream of data, which you can process.) However, we do not want to rely on trusting the OBS full key anymore, since in man-in-the-middle attack scenarios people could replace a "trusted" repo with their home repository.
* Allow upload of privates to be used to sign repos ? These keys *must not* get signed by the global OBS key, since they can be used elsewhere.
Don't think this is useful. I would not upload any of my private keys. But I would like to sign my repository-key with my private key. The buildservice should then provide the signed public keys.
You would generate a new one for the BS was the idea. But we were not convinced either this is a good idea. Of course you can sign your projects key with your own private keys.
* Does it make sense allow to reuse one key for multiple projects ? Does anyone want to have this at all ?
- If multiple signatures are possible, this would be useful. - Also it would be required to have only one key for subprojects (e.g. Education:xxx)
This is one line of thought we have not fully thought through. The problem here is you have different persons in different subprojects, and might want to differentiate between them. CIao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wednesday 05 September 2007 18:13:07 wrote Dirk Stoecker:
On Wed, 5 Sep 2007, Adrian Schröter wrote:
* People who currently use repositories from OBS will need to import the new gpg key(s). Otherwise the package managers will report errors.
Is signing with two keys possible? If so use a new buildservice key and still sign all packages with the old one (at least for older distributions). Add multi-key handling for openSUSE 10.3 and start using it there.
We discussed this as well. It is technical possible but showed more problems. The biggest one is that people just can remove one of the keys on their mirror, so YaST would only check only one. If this is only the generic OBS key, it is not enough anymore, but YaST (and any other package manager afaik) can not decide between trusted and less trusted keys.
* Allow upload of privates to be used to sign repos ? These keys *must not* get signed by the global OBS key, since they can be used elsewhere.
Don't think this is useful. I would not upload any of my private keys. But I would like to sign my repository-key with my private key. The buildservice should then provide the signed public keys.
You could create another private key pair to upload, which you sign with your main key. But yes, it is additionally possible to implement something that you can sign repos without to upload your private key. Both are possible things to be implemented in future additionally.
* Does it make sense allow to reuse one key for multiple projects ? Does anyone want to have this at all ?
- If multiple signatures are possible, this would be useful. - Also it would be required to have only one key for subprojects (e.g. Education:xxx)
k, +1 bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, 6 Sep 2007, Adrian Schröter wrote:
* People who currently use repositories from OBS will need to import the new gpg key(s). Otherwise the package managers will report errors.
Is signing with two keys possible? If so use a new buildservice key and still sign all packages with the old one (at least for older distributions). Add multi-key handling for openSUSE 10.3 and start using it there.
We discussed this as well. It is technical possible but showed more problems. The biggest one is that people just can remove one of the keys on their mirror, so YaST would only check only one. If this is only the generic OBS key, it is not enough anymore, but YaST (and any other package manager afaik) can not decide between trusted and less trusted keys.
From my point of view it was very complicated to add a key for Suse 10.1 (searching key, getting key, calling rpm with a commandline). 10.2 did it automatically after a button press if I remember.
I myself still have some machines running 10.1 (gladly no longer 9.x, as Strato allowed updates of the virtual servers :-) and don't want to do this all again for all the projects I use. So my concern is that you may introduce lots of new work. The OBS key is outdated in May 2008 if I'm right. When you have proper keyhandling in openSUSE 10.3 and 10.2 all is fine and you may introduce new handling there, but leave the old key until it ends for the older distributions. Is this possible? P.S. yast needs a RPM keyhandling module, where I can list, disable, enable, ... the keys when you introduce such a mass of keys. Ciao -- http://www.dstoecker.eu/ (PGP key available)
On Thursday 06 September 2007 08:44:16 wrote Dirk Stoecker:
On Thu, 6 Sep 2007, Adrian Schröter wrote:
* People who currently use repositories from OBS will need to import the new gpg key(s). Otherwise the package managers will report errors.
Is signing with two keys possible? If so use a new buildservice key and still sign all packages with the old one (at least for older distributions). Add multi-key handling for openSUSE 10.3 and start using it there.
We discussed this as well. It is technical possible but showed more problems. The biggest one is that people just can remove one of the keys on their mirror, so YaST would only check only one. If this is only the generic OBS key, it is not enough anymore, but YaST (and any other package manager afaik) can not decide between trusted and less trusted keys.
From my point of view it was very complicated to add a key for Suse 10.1 (searching key, getting key, calling rpm with a commandline). 10.2 did it automatically after a button press if I remember.
Yes, so this is a problem, what will disappear over the time ;)
I myself still have some machines running 10.1 (gladly no longer 9.x, as Strato allowed updates of the virtual servers :-) and don't want to do this all again for all the projects I use.
So my concern is that you may introduce lots of new work. The OBS key is outdated in May 2008 if I'm right. When you have proper keyhandling in openSUSE 10.3 and 10.2 all is fine and you may introduce new handling there, but leave the old key until it ends for the older distributions. Is this possible?
that is not that easy, since we design the new mechanism to have one (or more) key(s) per project. So all created repositories would have the same keys ... So I am a bit unsure what to do here, I would like to avoid to spend too much work into something what has too much future and will be obsolete not that far away. (openSUSE 10.0 is about to run out of maintainance already and 10.1 is next ...)
P.S. yast needs a RPM keyhandling module, where I can list, disable, enable, ... the keys when you introduce such a mass of keys.
Yes, that would be good ... I create an official request in our internal system for that ... bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi, during my work with an own obs instance here, I have found the following tuning possibility when using reiserfs for the partition containing the buildroot chroot tree: - mount this partition with: "data=writeback,noatime" options Before this, I had setup times for the creation of the chroot and required rpms of about 4-6 minutes (very similiar to your buildserver). With these mount options they have dropped drastically to about 1 minute. Is this an optimization you would also consider (you seem to also use reiserfs for the buildroot environments)? Are any bad side effects know with using noatime here and with the writeback mode in reiserfs? The effect of this here is that short running jobs do drastically speed up. Regards, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thursday 06 September 2007 13:57:57 wrote Martin Mohring:
Hi,
during my work with an own obs instance here, I have found the following tuning possibility when using reiserfs for the partition containing the buildroot chroot tree:
- mount this partition with: "data=writeback,noatime" options
Before this, I had setup times for the creation of the chroot and required rpms of about 4-6 minutes (very similiar to your buildserver). With these mount options they have dropped drastically to about 1 minute.
Is this an optimization you would also consider (you seem to also use reiserfs for the buildroot environments)? Are any bad side effects know with using noatime here and with the writeback mode in reiserfs?
In general, we need a setup to test the performance to answer that in a qualified way. Do you use also XEN or do you use chroot enviroments ? We have some fear that this might break some testsuite, like the glibc test suite. On the other hand, one could of course disable that test, if the speed increasement is really that high. btw, one of the major reasons, why we use reiserfs is that "mkfs" is so fast ;) bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi, it was just the question if you are a) interested b) think that "noatime" can work c) "data=writeback" works with reiserfs. It seems that the glibc testsuite at least seems not to check if "atime only" works correctly. Ist that a bug in glibc? OBS Server/Workers setup here: - we use no XEN, but chroot - Worker node machines are SUSE Linux 10.0/10.1 and openSUSE 10.2 mixed - Architecture is x86-64 and 32 bit mixed - OBS-Server is on a openSUSE 10.2 machine x86-64 Mount options: - major speedup comes from "data=writeback" with reiserfs - some speedup comes from "noatime" Testing and "noatime": - in order to do some basic testing, we have also copied an instance some of your Projects in our OBS-Instance, e.g. of the Project "Base:build" here, which contains Package "glibc" running the testsuite ok - other Packages from Base:build run, including the respective testsuites, ok, e.g. base system "Base:build" work, x86-64 and x86-32 (e.g. gcc with testsuite and bootstrapping). - I can remember that some SUSE Releases had "data=writeback" deactivated with reiserfs due to triggered bugs Ciao, Martin Adrian Schröter wrote:
On Thursday 06 September 2007 13:57:57 wrote Martin Mohring:
Hi,
during my work with an own obs instance here, I have found the following tuning possibility when using reiserfs for the partition containing the buildroot chroot tree:
- mount this partition with: "data=writeback,noatime" options
Before this, I had setup times for the creation of the chroot and required rpms of about 4-6 minutes (very similiar to your buildserver). With these mount options they have dropped drastically to about 1 minute.
Is this an optimization you would also consider (you seem to also use reiserfs for the buildroot environments)? Are any bad side effects know with using noatime here and with the writeback mode in reiserfs?
In general, we need a setup to test the performance to answer that in a qualified way. Do you use also XEN or do you use chroot enviroments ?
We have some fear that this might break some testsuite, like the glibc test suite. On the other hand, one could of course disable that test, if the speed increasement is really that high.
btw, one of the major reasons, why we use reiserfs is that "mkfs" is so fast ;)
bye adrian
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello, on Montag, 10. September 2007, Adrian Schröter wrote: [performance tuning]
btw, one of the major reasons, why we use reiserfs is that "mkfs" is so fast ;)
Another idea for performance tuning: The startup of every build is always the same: 1. create and boot virtual machine 2. create filesystem 3. install base RPMs 4. install whatever the specfile BuildRequires additionally 5. compile Did you ever think about using "templates" for the XEN guests? I can imagine that you could gain a major speedup if you prepare diskimages with the base packages already installed for the targets used most. This would result in the following workflow: 1. copy diskimage 2. start preinstalled virtual machine 3. continue with step 4 from above Regards, Christian Boltz --
Kann man die dar CD mit bearbeiten Standart Tools bearbeiten. Man kann eine CD sicherlich mit vielen Werkzeugen bearbeiten, aber wenn Du noch Daten davon lesen möchtest, würde ich einzig ein Baumwolltuch daran lassen. [> Patrice Staudt und Martin Schmitz in suse-linux]
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Monday 10 September 2007 23:37:48 wrote Christian Boltz:
Hello,
on Montag, 10. September 2007, Adrian Schröter wrote: [performance tuning]
btw, one of the major reasons, why we use reiserfs is that "mkfs" is so fast ;)
Another idea for performance tuning:
The startup of every build is always the same: 1. create and boot virtual machine 2. create filesystem 3. install base RPMs 4. install whatever the specfile BuildRequires additionally 5. compile
Did you ever think about using "templates" for the XEN guests?
The problem is that we would need to cache a lot of different images on each build host and this may lead to lacking disk space. Additionally, the setup of the systems is mostly IO bound due to the fast CPUs, so I do not see a majort advantage. But we do this indeed inhouse, when we build for arm, mips or s390 (where the setup of the system is more CPU bound).
I can imagine that you could gain a major speedup if you prepare diskimages with the base packages already installed for the targets used most. This would result in the following workflow:
1. copy diskimage 2. start preinstalled virtual machine 3. continue with step 4 from above
Regards,
Christian Boltz
-- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello, on Dienstag, 11. September 2007, Adrian Schröter wrote:
On Monday 10 September 2007 23:37:48 wrote Christian Boltz:
on Montag, 10. September 2007, Adrian Schröter wrote: [...] Did you ever think about using "templates" for the XEN guests?
The problem is that we would need to cache a lot of different images on each build host and this may lead to lacking disk space.
Well, if you have images for the "simple" targets, you should be done with about 20 images and would already cover the majority of the builds.
Additionally, the setup of the systems is mostly IO bound due to the fast CPUs, so I do not see a majort advantage.
Hmmm, I can't imagine that rpm is really as fast as cp ;-) but if you say so, I'll believe that your CPUs are fast enough (or the harddisks are too slow *g*) Regards, Christian Boltz --
Danke, dass du das Brett vorm Kopf ein wenig gelockert hast ;) Kein Problem. Das mit den Brettern passiert mir auch ständig ;-) [> Stephan Chudowski und Sören Wengerowsky in suse-linux]
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wednesday 12 September 2007 00:08:59 wrote Christian Boltz:
Hello,
on Dienstag, 11. September 2007, Adrian Schröter wrote:
On Monday 10 September 2007 23:37:48 wrote Christian Boltz:
on Montag, 10. September 2007, Adrian Schröter wrote:
[...]
Did you ever think about using "templates" for the XEN guests?
The problem is that we would need to cache a lot of different images on each build host and this may lead to lacking disk space.
Well, if you have images for the "simple" targets, you should be done with about 20 images and would already cover the majority of the builds.
Additionally, the setup of the systems is mostly IO bound due to the fast CPUs, so I do not see a majort advantage.
Hmmm, I can't imagine that rpm is really as fast as cp ;-)
well, rpm itself is, but it does need to uncompress the rpms with bzip2 algorithm which is the real cpu killer. However, it seems that our cpus are indeed fast enough for that, it does at least not speed up so much that the extra overhead of storing and refetching of images gets compensated to our internal tests.
but if you say so, I'll believe that your CPUs are fast enough (or the harddisks are too slow *g*)
The harddiscs are 5 SATA discs using striping for maximal performance on the newer build hosts, so they are also fast ... -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wed, 5 Sep 2007, Adrian Schröter wrote:
* We do not sign any repository anymore with the global OBS key, but generate a key for each existing project
BTW: How do you want to handle aggregates? Having mixed signatures in one project seems not to be very fine. Ciao -- http://www.dstoecker.eu/ (PGP key available)
On Thursday 06 September 2007 07:53:55 wrote Dirk Stoecker:
On Wed, 5 Sep 2007, Adrian Schröter wrote:
* We do not sign any repository anymore with the global OBS key, but generate a key for each existing project
BTW: How do you want to handle aggregates? Having mixed signatures in one project seems not to be very fine.
The plan was to re-sign it with the other key on aggregate. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (5)
-
Adrian Schröter -
Christian Boltz -
Dirk Stoecker -
Marcus Meissner -
Martin Mohring