<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font size="-1">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.</font></p>
<p><font size="-1">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.<br>
</font></p>
<p><font size="-1">Neil Nelson<br>
</font></p>
<div class="moz-cite-prefix"><font size="-1">On 1/13/21 1:49 AM,
Diana Picus wrote:</font></div>
<blockquote type="cite"
cite="mid:CAFYwA24X6MCiXfPvy6B4wP_DAS7f72Bi+Pw1=93L5ZaL3OEGMQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 13 Jan 2021 at
08:22, Neil Nelson via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">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">
<div>
<p><font size="-1">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.</font></p>
<p><font size="-1">To automate the use of the hash value
we might upload that value</font><font size="-1"><font
size="-1"> in a file </font>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.</font></p>
</div>
</blockquote>
<div>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?</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p><font size="-1">Neil Nelson<br>
</font></p>
<div><font size="-1">On 1/13/21 12:00 AM, Neil Nelson via
llvm-dev wrote:</font><br>
</div>
<blockquote type="cite">
<p><font size="-1">Not sure exactly what automatically
signing means. Here is my recent upload command.</font></p>
<p><font size="-1">scp -i ~/.ssh/id_rsa_llvm.pub
clang+llvm-11.0.1-x86_64-linux-gnu-ubuntu-20.10.tar.xz
<a
href="mailto:testers@releases-origin.llvm.org:/home/testers"
target="_blank" moz-do-not-send="true">testers@releases-origin.llvm.org:/home/testers</a></font></p>
<p><font size="-1">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</font></p>
<p><font size="-1">id_rsa_nnelson.pub</font></p>
<p><font size="-1">Or possibly some identifier instead
of nnelson assigned by LLVM.</font></p>
<p><font size="-1">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.</font></p>
<p><font size="-1">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.<br>
</font></p>
<p><font size="-1">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.</font></p>
<p><font size="-1">Getting the SSH log working properly
seems the stretch part at the moment but appears the
obvious direction.</font></p>
<p><font size="-1">Neil Nelson</font></p>
<div><font size="-1">On 1/12/21 10:13 PM, Tom Stellard
via llvm-dev wrote:</font><br>
</div>
<blockquote type="cite">Hi, <br>
<br>
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. <br>
<br>
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. <br>
<br>
Implementing these changes, will help streamline the
release process and 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" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
<br>
</blockquote>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>