[llvm-dev] RFC: Automated signing of release files
Neil Nelson via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 13 08:47:06 PST 2021
The public/private keys identify the unique source for whatever is
uploaded. The reason I suggested it be uploaded with a name attached to
the primary upload was that a program can then automatically do the
confirmation that the primary file is in good shape using the hash value.
If the primary upload was bogus, doing the hash on the bogus file and
sending that hash value by email will enable the receiver of the email
to confirm that hash value on the bogus primary upload. Nothing is
gained by not sending the hash value by the encryption keys.
Neil Nelson
On 1/13/21 1:49 AM, Diana Picus wrote:
>
> On Wed, 13 Jan 2021 at 08:22, Neil Nelson via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
> Just realized that the uploaded file's hash value needs to be
> handled easily and tied to subsequent uses of the file. It is the
> hash value that ties the primary file back to the user upload.
>
> To automate the use of the hash value we might upload that valuein
> a file using scp with the same public key as the primary upload
> file with a name tied to the primary upload file. Putting that
> hash value in the MySQL DB with the primary file name will be useful.
>
> I'm not a security expert, but I thought the main idea with sending
> the hash values via email was to have a separate communication channel
> than the scp transfer. Otherwise someone that uploads a bogus archive
> can just as easily upload a bogus hash value and it would look legit.
> Can we think of a different way to automate the sharing of the hash value?
>
> Neil Nelson
>
> On 1/13/21 12:00 AM, Neil Nelson via llvm-dev wrote:
>>
>> Not sure exactly what automatically signing means. Here is my
>> recent upload command.
>>
>> scp -i ~/.ssh/id_rsa_llvm.pub
>> clang+llvm-11.0.1-x86_64-linux-gnu-ubuntu-20.10.tar.xz
>> testers at releases-origin.llvm.org:/home/testers
>> <mailto:testers at releases-origin.llvm.org:/home/testers>
>>
>> My public key on the LLVM side, id_rsa_llvm.pub, identifies the
>> upload as coming from me. It may be better to change the name of
>> that public key to something like
>>
>> id_rsa_nnelson.pub
>>
>> Or possibly some identifier instead of nnelson assigned by LLVM.
>>
>> The public key on the scp command uniquely identifies the source
>> of the upload. The public key was previously uploaded to LLVM.
>> User authentication occurs when the user side uses the private
>> key to set up the encryption channel for the file transfer, with
>> the LLVM side using the public key for that user's private key.
>>
>> The determination of user trustworthiness is tied to the user's
>> public key and is by some method external to the use of the keys.
>> I expect that would be determined by the quality of uploads in
>> the past and perhaps to the degree that others at LLVM can vouch
>> for that user. This has the feel of a MySQL database showing the
>> user's name, public key name, upload activity and community
>> evaluations toward some degree of trustworthiness. It may be that
>> on the release page has user upvotes and downvotes for each
>> release file could be applied to help in that rating.
>>
>> At this point we need an SSH log on the LLVM side we can parse
>> that will show what keys were used with what files uploaded. This
>> parse would be done at some convenient frequency and may
>> automatically update the MySQL DB and provide activity reporting.
>> Moving of the uploaded files and updating the release page could
>> possibly be done automatically. This last part depends on setting
>> up the detail and format for that process.
>>
>> Getting the SSH log working properly seems the stretch part at
>> the moment but appears the obvious direction.
>>
>> Neil Nelson
>>
>> On 1/12/21 10:13 PM, Tom Stellard via llvm-dev 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 <mailto:llvm-dev at lists.llvm.org>
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> <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/7f2dfbc4/attachment.html>
More information about the llvm-dev
mailing list