llvm dev - Jan 2021 - RFC: Automated signing of release files

+llvm-dev <llvm-dev at lists.llvm.org>

(sorry forgot the mailing list...)


On Wed, Jan 13, 2021 at 9:49 AM Christian Kühnel <kuhnel at google.com>
wrote:
> Hi Tom,
>
> 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:
>
> 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.
>
> Pro:
>
> * one central place to manage the keys
> * central auditing options, you can log who signed which files
>
> Con:
>
> * 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.
>
> * Central place to get hacked.
>
>
> 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.
>
> Pro:
>
> * no server infrastructure needed, just openssl and a bunch of scripts
>
> * you can track releases back to users via the signatures
>
> * Keys can be stored on simple USB hardware security modules (e.g.
> Yubikey) to avoid leaking. You can have multiple of these for redundancy.
>
> Con:
>
> * Users need to take care of the keys themselves.
>
> * 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.
>
> * Impossible to audit: We never know what files the users actually signed
> with their keys.
>
> * 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.
>
>
> I'm not so familiar with the release process, so I can't say which
option
> is better.
>
> Best,
> Christian
>
>
> On Wed, Jan 13, 2021 at 6:13 AM Tom Stellard via llvm-dev <
> llvm-dev at lists.llvm.org> 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?
>>
>> Thanks,
>> Tom
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210113/7c726131/attachment.html>