On Tue, 2021-01-12 at 21:13 -0800, Tom Stellard via Release-testers wrote: > Hi, > > I would like to automate the signing of some of the release files we > upload to the release page, starting with the source tarballs. My > initial goal is to have a CI job that automatically creates, signs, and > uploads the source tarballs, whenever a new release is tagged. I would > also like the key used for signing to be a 'project' key and not > someone's personal key. > > Once this is done, I would like to implement something similar for the > release binaries, so that testers could upload the binaries and have > them automatically signed. This will be more difficult than the source > tarballs, because the binaries are built by individual testers, so we > would need to prove that they come from a trust-worthy source. > > Implementing these changes, will help streamline the release process and > let release managers avoid doing a lot of manual mistake-prone tasks. > > The questions I have for the community are: > > Is this a good idea? > > How can I implement this securely?
I have mixed feelings about automatic signing. Since releases are done by humans anyway, I don't see much gain by avoiding humans in the signing process. Of course, there are some factors to consider. First of all, it is quite clear that LLVM currently relies on GitHub for the repo. No offense meant but I honestly doubt that anyone actively monitors whether the repo has not been tampered with -- how would you go about that anyway? So I suppose it matters little whether you sign release tarballs automatically or manually because whatever you sign might be forged at this point already. Not saying this couldn't be improved. For example, in Gentoo we sign all commits (but I don't think GH supports rejecting unsigned commits). Then you could at least verify that every commit corresponds to the repo state signed by someone you somewhat trust enough to give push access. Secondly, I would presume any key stored outside your own trusted Infra as compromised. Now, if we were talking about signing the artifacts of automated builds (e.g. nightlies), then I'd suggest using a separate key for automated signatures (that's kept on the server) and manual signatures (that's kept on you). But if we're talking about final semi- manual releases, then I think you should keep the key on yourself. If you're planning to use PGP, please remember not to upload the secret portion of the primary key to the server and keep that on you only. This will make it possible to easily replace the signing subkey if the server is compromised. Thirdly, this also requires a trusted release process. You need to verify that the binaries weren't tampered with before signing them, so I guess they need to be signed too. It might be just simpler to let release testers upload binaries along with their signatures, and just provide an explicit list of who signed what rather than a single signing key. -- Best regards, Michał Górny _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
