repos providing only md5 sums

rain1 at openmailbox.org rain1 at openmailbox.org
Tue Mar 29 00:58:22 UTC 2016


On 2016-03-29 01:02, Thomas Penteker wrote:
> Hello,
> 
> On 28.03.2016 19:50, rain1 at openmailbox.org wrote:
>> On 2016-03-23 06:38, Erich Eckner wrote:
>>> On 21.03.2016 21:36, Dutch Ingraham wrote:
>>>> On Mon, Mar 21, 2016 at 08:31:00AM +0100, Thomas Penteker wrote:
>>>>> To fill the missing link to providing integrity and 
>>>>> confidentiality, we
>>>>> should start cryptographically signing ports on the maintainer's 
>>>>> side and
>>>>> check these signatures before building/downloading anything.
>>>>> 
>>>>> 
>>>>> regards,
>>>>> Thomas
>>>> 
>>>> Yes, please.[1]
>>>> 
>>>> [1] blog.linuxmint.com/?paged=2
> (...)
>> I would like to recommend the signify tool:
>> http://www.openbsd.org/papers/bsdcan-signify.html
>> 
>> It's very high quality and simple. Could be useful for building this
>> package signing system.
> 
> I put up a proposal/implementation documentation of my efforts to bring
> signed ports to CRUX using signify. It can be found at
> https://crux.nu/Wiki/SignedPorts which also containts the steps 
> required
> to test drive the new functionality.
> 
> I'd like to move quickly as things look pretty usable and stable, also
> please comment.
> 
> best regards,
> Thomas
> _______________________________________________
> CRUX mailing list
> CRUX at lists.crux.nu
> https://lists.crux.nu/mailman/listinfo/crux

Nice to use signify and sha256, good strong primitives. A shame to have 
to manage a fork of signify, I wonder if the openbsd project would 
accept the changes to allow that program to become portable to both 
openbsd and linux?

I agree that integrity and authenticity are the important security goals 
here. Often you would think of a person having a key. The proposal here 
is that the repo itself has a key, I think that is a good idea because 
it's important that the keys be rotated instead of lasting for very long 
periods of time. This could be done in the same way as explained in the 
BSD whitepaper - A key is invalidated after 2 releases. New keys are 
included in each release which establishes a trust chain.

It might be good to have one 'master key' which signs all of the 
subkeys. Is that what core does? This lets us reduce all the trust 
chains down to one. That way the public key for that can be posted to 
various places (e.g. separate sites, included in emails, each extra way 
it is shared decreases the chance of it being substituted by an 
attacker) and we don't need to rely on HTTPS alone.

One thing sounds a little dangerous "ignoring md5sums but falling back 
to these if no .signature file is present." This might open up to a 
downgrade attack unless it is just a temporary measure for transitioning 
to signing?

Best of luck with rolling this out! It sounds like a really good 
improvement.




More information about the CRUX mailing list