Re: Optimal workflow with GPG signatures from multiple parties
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
Re: Optimal workflow with GPG signatures from multiple parties
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
Optimal workflow with GPG signatures from multiple parties
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
