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:
> 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.
>>>> Yes, please.
>>>>  blog.linuxmint.com/?paged=2
>> I would like to recommend the signify tool:
>> 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
> to test drive the new functionality.
> I'd like to move quickly as things look pretty usable and stable, also
> please comment.
> best regards,
> CRUX mailing list
> CRUX at lists.crux.nu
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
Best of luck with rolling this out! It sounds like a really good
More information about the CRUX