<div dir="ltr"><a class="gmail_plusreply" id="plusReplyChip-1" href="mailto:llvm-dev@lists.llvm.org" tabindex="-1">+llvm-dev</a> <div><br></div><div>(sorry forgot the mailing list...)<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 13, 2021 at 9:49 AM Christian Kühnel <<a href="mailto:kuhnel@google.com">kuhnel@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Tom,<div><br></div><div>I would strongly advise against just storing the keys in some files on some file system, much less if that machine has internet access. They are just too easy to copy and you won't even notice they leaked. From a pure security perspective, I guess in general there are two basic ways to securely manage the signing keys:</div><div><br></div><div>1. Centralized: Set up (or pay for) a central server that keeps the keys and allows selected users to upload and sign files/hashes via UI or some command line tool.</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Pro: </div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>* one central place to manage the keys</div><div>* central auditing options, you can log who signed which files<br></div></blockquote></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Con:</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>* We need to run such a service securely or pay someone to do so. So we need to trust the admin of such an infrastructure.</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>* Central place to get hacked.</div></blockquote></blockquote><div><br></div><div>2. Decentralized: Use a "LLVM certificate" to sign multiple packager certificates. Then the packager can use their certificates to sign the files they just created on behalf of LLVM. <br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Pro:</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>* no server infrastructure needed, just openssl and a bunch of scripts</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>* you can track releases back to users via the signatures</div></blockquote></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>* Keys can be stored on simple USB hardware security modules (e.g. Yubikey) to avoid leaking. You can have multiple of these for redundancy.</div></blockquote></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Con:</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>* Users need to take care of the keys themselves.</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>* These signatures are harder to verify, as you need to verify the certificate chain and also check for revoked/expired certificates. Yet this can also be scripted.</div></blockquote></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>* Impossible to audit: We never know what files the users actually signed with their keys.</div></blockquote></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>* In case of distributing HSMs: We need to make sure that people can actually buy these in their country as there might be export regulations in place.</div></blockquote></blockquote><div><br></div><div>I'm not so familiar with the release process, so I can't say which option is better. </div><div><br></div><div><div><div dir="ltr"><div dir="ltr">Best,<div>Christian</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 13, 2021 at 6:13 AM Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I would like to automate the signing of some of the release files we <br>
upload to the release page, starting with the source tarballs.  My <br>
initial goal is to have a CI job that automatically creates, signs, and <br>
uploads the source tarballs, whenever a new release is tagged.  I would <br>
also like the key used for signing to be a 'project' key and not <br>
someone's personal key.<br>
<br>
Once this is done, I would like to implement something similar for the <br>
release binaries, so that testers could upload the binaries and have <br>
them automatically signed.  This will be more difficult than the source <br>
tarballs, because the binaries are built by individual testers, so we <br>
would need to prove that they come from a trust-worthy source.<br>
<br>
Implementing these changes, will help streamline the release process and <br>
let release managers avoid doing a lot of manual mistake-prone tasks.<br>
<br>
The questions I have for the community are:<br>
<br>
Is this a good idea?<br>
<br>
How can I implement this securely?<br>
<br>
Thanks,<br>
Tom<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>