[opensuse-buildservice] [obs-signd] need advice about gpg key generation
Hi, I'm looking for an advice with key generation for obs-signd. We would run it independently from OBS. ( we want to utilize obs-signd for package signing at Copr - http://fedorahosted.org/copr). If I understand correctly, OBS manages user key outsides from obs-signd, and provides private[public] keys directly to /bin/sign. At our service we want to minimize key manamement, keep secrets on secured machine (where singd runs) and avoid sending secrets through network. Here is our (future) setup: host-0: secure machine where key-pairs is stored in /root/.gnupg/ it runs: - [A] perl signd - [B] small httpd service which generates new key-pairs into the keyring and write generated passphrases to /root/.phrases/ host-1: backend where builds occurs and result rpms are signed by invocation of /bin/sign [C] [C] is configured by /etc/sign.conf to access [A] at host-0 When user `foo` builds first package, service [B] will be invocked and passphrase will be added to /root/.phrases/ and keys will be added to keyring, so that [A] can sign packages for user `foo` without recieving keys through network. [C] will be used: * To sign rpm [@host-1]:# sign -u foo@example.com target.rpm * To obtain public key for user: [@host-1]:# sign -u foo@example.com -p Please, tell if this design makes sense or how should it be changed. Additional question: Do we really need to protect keys with passhrases on [host-0]? Private keys should never leave keyring at that machine. -- Best regards, Gologuzov Valentin. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tue, Sep 09, 2014 at 01:20:43PM +0200, Valentin Gologuzov wrote:
I'm looking for an advice with key generation for obs-signd. We would run it independently from OBS. ( we want to utilize obs-signd for package signing at Copr - http://fedorahosted.org/copr).
If I understand correctly, OBS manages user key outsides from obs-signd, and provides private[public] keys directly to /bin/sign. At our service we want to minimize key manamement, keep secrets on secured machine (where singd runs) and avoid sending secrets through network.
Sounds reasonable.
Here is our (future) setup:
host-0: secure machine where key-pairs is stored in /root/.gnupg/ it runs: - [A] perl signd - [B] small httpd service which generates new key-pairs into the keyring and write generated passphrases to /root/.phrases/
host-1: backend where builds occurs and result rpms are signed by invocation of /bin/sign [C]
[C] is configured by /etc/sign.conf to access [A] at host-0
When user `foo` builds first package, service [B] will be invocked and passphrase will be added to /root/.phrases/ and keys will be added to keyring, so that [A] can sign packages for user `foo` without recieving keys through network.
[C] will be used: * To sign rpm [@host-1]:# sign -u foo@example.com target.rpm * To obtain public key for user: [@host-1]:# sign -u foo@example.com -p
Please, tell if this design makes sense or how should it be changed.
Makes sense. We do it a bit different in OBS, though. We don't store the users' secret keys on our sign server, but instead encrypt them with a dedicated OBS key. The advantage is that the encrypted private keys can be stored and backuped like regular data, as you need access to the secret OBS key to decrypt them (which is only stored on the sign server). The disadvantage is that an intruder can use any stored key to sign rpms (but he can't copy the private key away and do more damage). So for build.opensuse.org we actually have two security levels. For most things we store the encrypted private key on the host, but there are a couple of keys like the opensuse key that are only stored in the sign server (and were created manually). Example:(copr@example.com is the dedicated key that needs to exist on the sign host) * create a new key: [@host-1]:# sign -u copr@example.com -P foo.priv -g rsa@2048 800 foo foo@example.com > foo.pub * sign rpm: [@host-1]:# sign -u copr@example.com -P foo.priv target.rpm
Additional question: Do we really need to protect keys with passhrases on [host-0]? Private keys should never leave keyring at that machine.
I don't think you need passphrases. They don't help much if they can be read from the filesystem anyway... Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Great thanks! Now I understand how obs-signd used in OBS :) . On 09/09/2014 02:14 PM, Michael Schroeder wrote: <skipped>
Makes sense. We do it a bit different in OBS, though. We don't store the users' secret keys on our sign server, but instead encrypt them with a dedicated OBS key. The advantage is that the encrypted private keys can be stored and backuped like regular data, as you need access to the secret OBS key to decrypt them (which is only stored on the sign server). The disadvantage is that an intruder can use any stored key to sign rpms (but he can't copy the private key away and do more damage).
So for build.opensuse.org we actually have two security levels. For most things we store the encrypted private key on the host, but there are a couple of keys like the opensuse key that are only stored in the sign server (and were created manually).
Example:(copr@example.com is the dedicated key that needs to exist on the sign host)
* create a new key: [@host-1]:# sign -u copr@example.com -P foo.priv -g rsa@2048 800 foo foo@example.com > foo.pub * sign rpm: [@host-1]:# sign -u copr@example.com -P foo.priv target.rpm
Additional question: Do we really need to protect keys with passhrases on [host-0]? Private keys should never leave keyring at that machine.
I don't think you need passphrases. They don't help much if they can be read from the filesystem anyway...
Cheers, Michael.
-- Best regards, Gologuzov Valentin. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (2)
-
Michael Schroeder
-
Valentin Gologuzov