Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)

Kevin Fenzi kevin at
Sun Apr 6 18:21:47 UTC 2014

On Thu, 03 Apr 2014 14:29:16 +0200
Miroslav Suchý <msuchy at> wrote:

> On 04/03/2014 03:46 AM, Toshio Kuratomi wrote:


> > For whoever is going to approach infra about signing the packages in
> > copr it probably makes more sense to either talk about enhancing
> > sigul to work with copr or getting obs-sign to be able to sign
> > packages from koji.  We'd probably also want to ask bressers or
> > someone else from the security team to do some sort of evaluation
> > of the code bases that we're looking at.
> That would be probably me. I mean the guy who will be implementing
> signing of packages in Copr.
> I investigated several possibilities and talked to several people.
> But you are correct that I did not send conclusion to mailing list
> yet. Maybe it is right time to do it now.
> One of the guy to who I talked to is Miroslav Trmac, who is current
> maintainer and main author of Sigul since 2009. The conclusion from
> discussion with him is that:
> * we would need need different instance, because to use the same
> instance for main distribution and for relaxed ring (Copr,
> Playground...) is not best idea. Neither from security POV nor for
> technical implementation. (*)
> * we would need to do some development of Sigul before deploying new
> instance
> * and we would likely should migrate to gpg2 (from gpg1)
> * Sigul have very restricted network setup, which is probably not
> needed for Copr
> On the other hand obs-sign:
> * is actively maintained
> * is more simple
> * used in OBS as well (which mean community and so on)
> * have security model and network setup good enough for Copr (I
> arranged meeting of Adrian Shröter from OBS and Mirek Trmač during
> where they discussed technical details and none of them
> seen any blocker).

So, one consideration here is that we also are looking at trying to
sign rawhide packages and perhaps scratch builds and/or official
builds. It would be very nice to not duplicate a bunch in solutions for
signing copr and for the above too. It would be nice to reuse things
that make sense there. 

> Yes, obs-sign is not packaged for Fedora (yet), but the spec exists
> and I can get it in Fedora withing week. I do not see that as problem.
> If I sum it up, then obs-sign is clear winner to me. Therefore this
> is the way I would like to go in Copr.
> But it still does not bubble up in my TODO list. So we have plenty of
> time for discussion :)

Sure. obs-sign could perhaps work for the other use cases with a koji
plugin to talk to it as desired. See for more discussion. 

> (*) You suggested that having one signing server is better as "The
> more signing servers we have the greater the
>  > attack surface infrastructure has to protect." I disagree.

Well, it means two things to update, two things to protect. 
obs-signd also stores private key and passphrase on local disk right?

> First: it is not technical possible. Because Koji and current Sigul
> is in different networks and I'm not sure if we want to change it.

Sure, but thats not a problem. We could have a server listening to
fedmsg do the signing. That won't work for copr tho, because the sigul
server doesn't have access to the copr packages to write out a

> Likely not. Second: if you compromise Copr signing server then you
> have compromised main distribution. Therefore even from security POV
> is better to have different signing server for main distribution and
> for Copr.

Well, it's not that black and white. To compromise sigul you need both
access to the keystore and passphrase(s) to each key to unlock the
private key. If you just have access to the keystore you can't still
get access to the private key. If you just have a passphrase for a key
you can't do anything without access to the server or the keystore.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <>

More information about the devel mailing list