[Buildroot] [PATCH] ser2net: Add a hash file

Gustavo Zacarias gustavo at zacarias.com.ar
Wed Oct 8 10:11:12 UTC 2014


On 10/08/2014 06:37 AM, Markos Chandras wrote:

>>>> Why having all those hashes?
>>>
>>> Why not? Those are all the hashes supported in Buildroot. The more we 
>>> have the better.
>>
>> I disagree: more hashes means more work to do when bumping the package.
>> Either one strong hash, or two weaker hashes should be sufficient IMO.
>>
>> Something to be discussed at the meeting maybe?
> 
> I am curious, what's the point of supporting more than one hash types?
> Why not support only the strongest one?

Normally you want to use upstream-provided hashes and they're not of the
same class for security.
You've got basically 3 kinds of security:
1) Upstream releases new version/software with hashes.
2) Upstream releases tarball signed (pgp).
3) Upstream just releases.

1 and 2 can intersect which is great.
Announcements ideally go into a mailing list hence the chance of
compromising that is far lower than a hash file or note in the web page
(which can be the same hosting site/server as the tarball).
If you use a signed pgp that reduces the chance of website compromise
since ideally the key is stored elsewhere as well.
If the hash/signature is on a mailing list archive the same happens
(another site, harder to get all the pieces together).
If the release is using a weak hash (md5, sha1) for which there are
possible collissions using two hashes makes it extremely difficult to
collide in a useful way.
(re)computing the hash for a bump/package requires that people check the
signature and we trust that they did it right (did anyone recheck
besides Baruch with openssh?) instead of just sha256sum(ing) the file
and sticking that result.
I think i've covered most of the cases here :)
Regards.




More information about the buildroot mailing list