On 05/15/18 at 05:43pm, Bruno Pagani via arch-dev-public wrote: > Le 15/05/2018 à 17:25, Florian Pritz via arch-dev-public a écrit :
Just going to necro-bump this thread, since we didn't arrive at a conclusive descision. > > > On 13.05.2018 22:47, Christian Rebischke via arch-dev-public wrote: > >> We could just generate an automated cloud image signing key (only for > >> this purpose) of course and automatically sign the images with that key. > >> Problem with this is: If our build server ever get pwned the person will > >> have these keys for signing cloud images as well. Any opinion about > >> this? > > We had that discussion some years ago about signing our pacman > > databases. I mostly remember that we didn't reach a consensus, but you > > might want to search the archives for details. At some point there was a > > proposal to have a dedicated signing host that is well protected and > > receives files and then returns the signature. I'm not sure if that was > > turned down or if there was simply nobody to work on this. Does anyone > > remember that? > > > > I think this would be a viable option for us. We could also implement > > some form of rate limiting and sanity checks to ensure we only sign > > things that we want to sign. For example, only one ISO can be signed per > > month and the request must come from a specific IP. I probably won't do > > any implementation, but I'd offer to provide feedback and design help if > > someone wants to work on this. Assuming we first agree that we want to > > do it this way. I believe this solution is the way to go. > To me this is quite a good idea. :) > > I had a bit more sophisticated design in mind, where the signing host > /retrieves/ the file to be signed (so that the connection is initiated > from it, not toward it) by having the filename added to some text file > on an other (almost?) dedicated host (so that having access to the hosts > where the DB/iso/whatever are built is not enough and vice-versa, see > just after), text file that the signing host would be watching a way or > another (but should be in an authenticated way). Of course you need to > restrict what kind of files can be retrieved from what host (like you > proposed for the request coming from a specified IP). > > The goal of this setup is to have no open port on the signing host, > requiring physical/IPMI access to it to make any change. > > But maybe that does not bring much more than your setup, while adding > much more complexity… > > Just as you, I cannot help on implementing, but I can offer ideas and > design feedback if anyone want to take this task in charge. That sounds rather complicated, since we also wants this for the repo db as well. I wonder if we use the proposed method but restrict access not only source ip but also on the user who can make the request? On a seperate note, I don't believe the signing issue is new I know that Fedora and OpenSuSe have both signing solutions. For the OpenSuse Build Service, they have a daemon called obs-signd. [1] Their solution is a sperate machine with a port open for their signing daemon. I'm not sure how they resolve the don't sign any arbitrary file problem. For Fedora I couldn't find any information, I've reached out to a Fedora Dev for some more information. The only thing I can find is a proposal. [2] Maybe we should create a wiki page for signing the repository DB and ISO's. So we can list all the benefits and downsides along with the threat vector. [1] https://en.opensuse.org/openSUSE:Build_Service_Signer [2] https://fedoraproject.org/wiki/Koji_Build_Autosign_Proposal -- Jelle van der Waa
signature.asc
Description: PGP signature