Mailing List Archive: Optimal workflow with GPG signatures from multiple parties

Optimal workflow with GPG signatures from multiple parties

Mar 4, 2023, 9:18 AM

Post #1 of 3 (220 views)

Hi list,

We have a build server, it stores a private key and is capable of signing the resulting build artifact. The artifact then gets verified in the target environment during installation. There are multiple issues with current approach:

1. A random developer cannot trigger a build on the server from a random branch that they pushed. Therefore, if a random developer wants to test something they wrote and build a clean artifact, it has to go through the build server admin, who has an account on the build server, and ask him to build and sign something manually. This is a huge bottleneck.

2. The build server is the single source of truth, since it has the private key. Which is also the reason, why a random developer shouldn't get an account on the build server. If the private key is leaked, anybody can sign anything and run it in the target environment.

3. The build server is only a single computer. We also want to build on different hardware, e.g. a cluster that spins up Docker containers, where every random developer has their own running container, is able to build and sign the artifacts.

So, everyone interested should be able to build, sign and deploy the artifacts. At the same time, it is important to not share direct access to the private key between everyone. Additionally, the solution should be scalable and flexible: the developer should be able to build and sign something locally on their laptop, if they so desire.

The problem can also be described in terms of "production" and "development" builds. Currently, the build server only issues "production" builds, and everyone who wants to build and test their artifacts has to either wait for a nightly build, or ask the build server admin to do it manually. What we want is to also introduce "development" builds, artifacts quickly hacked together for testing purposes, that many developers can build and sign as they wish. Logically, it probably should not be as simple as the developer deploying their personal public key into the target environment and then signing their artifact, for two reasons: the target environment gets wiped, and it practically cannot account for all personal keys of all the developers; and then there is not much difference versus giving the developer direct access to the main private key.

What are some available solutions? How would you suggest to organize the keys? Maybe, there should be some signing server in-place, that the developers sends an artifact to?

Thanks,
ave

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Optimal workflow with GPG signatures from multiple parties [ In reply to ]

gnupg-users at gnupg

Mar 4, 2023, 5:17 PM

Post #2 of 3 (219 views)

Permalink

Ave Milia via Gnupg-users wrote:

> Logically, it probably should not be as simple as the developer deploying their personal public key into the target environment and then signing their artifact, for two reasons: the target environment gets wiped, and it practically cannot account for all personal keys of all the developers; and then there is not much difference versus giving the developer direct access to the main private key.
>

Er, I may be mistaken here, but I understand that if any of the code you
distribute is GPLv3, installing a personal public key into the target
environment is exactly what you are required to permit. (Or the
"Installation Instructions" required under section 6 of the GPLv3 can
include the main private key, your choice.) The only way you get out of
this is if you are not actually distributing code and this whole
scenario is internal to some organization.

> What are some available solutions? How would you suggest to organize the keys? Maybe, there should be some signing server in-place, that the developers sends an artifact to?
>

Since you are asking on a list for GPG users, I suspect you are likely
using GPG to verify artifacts in the target environment, and therefore
need to comply with GPLv3... addressing that first may solve your problem.

-- Jacob

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Optimal workflow with GPG signatures from multiple parties [ In reply to ]

gnupg-users at gnupg

Mar 6, 2023, 3:28 AM

Post #3 of 3 (217 views)

Permalink

On 04/03/2023 17:18, Ave Milia via Gnupg-users wrote:
> What are some available solutions? How would you suggest to organize the keys? Maybe, there should be some signing server in-place, that the developers sends an artifact to?

I built something similar for $WORK. You lock down the signing server
and use your preferred form of authentication to allow only your
developers (and the build server) to submit an artifact for signature.
This could be done using a simple REST API.

Once you have this in place, it would be easy to extend it with a second
signing key for development purposes only, and make sure that only the
production public key is distributed with your production artifacts.
That way all your developers can get their dev builds signed, but only
your build server and maybe your release manager have the credentials to
sign with the production key. This could be done by linking the signing
key to the user credentials, or by having two signing servers.

A

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users