Open Stack

On 7/29/19 5:52 PM, Clark Boylan wrote:
> On Mon, Jul 29, 2019, at 1:52 PM, James E. Blair wrote:
>> Hi,
>>
>> A colleague at Red Hat is working on an effort to record signatures of
>> release artifacts.  Essentially it's a way to help users verify release
>> artifacts (or determine if they have been changed) independent of PGP
>> signatures.  You can read about it here:
>> https://github.com/merklecounty/rget#rget
>>
>> It sounds like an interesting and useful effort, and I think we can
>> support it at little cost.  If we wanted to do so, I think we would need
>> to do the following things:
>>
>> 1) Generate SHA256SUMS of our release artifacts.  These could even
>> include the GPG signature files.
> 
> We'll also need to publish the sha256sums file. We are already publishing the other files so this should be easy.
> 
>>
>> 2) Run "rget submit" on the resulting files after publication.
>>
>> That's it.
> 
> There is also a step 0) install rget. Unfortunately their docs don't mention how to verify the installation of rget (self bootstrapping) though I think you would download rget, hash it before running it, then run it to get the hashes of rget and then compare? Though a modified rget could just tell you it was the unmodified version. Maybe that is why they don't bother telling you what to do there.
Actually - it turns out this is just doing a single submit to a URL, so 
it will likely be much easier to just use curl or an ansible URI call to 
do the submission step. (it's great that rget has this for folks, but in 
our case I think we don't need to use rget just to do the submission)

> We may also want to set up some sort of periodic audit of our "certs" in the certificate transparency logs. Just to ensure there are no unexpected changes.

++

>>
>> Both of those would be changes to the release publication jobs, and
>> wouldn't require any other changes to our processes.
>>
>> As mentioned in the README this is very early stages and the author,
>> Brandon Philips, welcomes both further testing and feedback on the
>> process in general.
>>
>> Thoughts?
> 
> Overall seems like a good way for people (including ourselves) to sanity check that our releases are not changing unexpectedly.
> 
>>
>> -Jim
>>
>>
> 
>