[Slackbuilds-users] Retire MD5 for SHA256
dickson.tim at googlemail.com
Fri Aug 10 13:24:55 UTC 2018
my 2cents worth...
if it aint broke...
well, the argument is that it is broke, but... using hash collisions
means either the source can be compromised, in which case it is not
reliable, or the compromise is done on the network, in which case the
network is not reliable.
If either network or source are not reliable, then the expected
checksum - whatever method used could simply be set to match the
interfered-with source code, so the attacker would not need to "crack"
the checksum, they could just make what was visible match their version
of the compromised source.
In other words, as a basic download file corruption check, md5 is simple
and convenient; any other assumptions about security depend on other
variables far more than the type of checksum used.
On 10/08/2018 08:24, B Watson wrote:
> On 8/10/18, David O'Shaughnessy <lists at osh.id.au> wrote:
>> I understand that MD5 is useful for checking for unintentionally
>> corrupted downloads, but it seems to leave open the possibility for a
>> subsequently maliciously altered archive (i.e., one that uses hash
>> collisions to produce the same MD5, but which would fail a GPG signature
> This comes up from time to time... I personally am not opposed to it,
> theoretically it's a good idea, but it'd be a good bit of work for
> everyone (admins, maintainers, even users would be impacted).
> What might be feasible: have each maintainer GPG sign the source files
> and include detached signatures (.asc) in the SlackBuild directory.
> Would require a way for users to get the maintainers' public keys,
> but there are public keyservers (and we could do the 'web of trust'
> thing by signing each others' pub keys).
> The .info file format wouldn't have to change at all. We'd just start
> having one or more small .asc files included with the builds. Automated
> tools could check for them and verify the signatures after the download.
> If there's no signature, it would just say so, and continue the build.
> Doing it this way puts the burden on the individual SlackBuild maintainers
> instead of adding *yet more* work to the admins' workload, and it'd stay
> backwards compatible...
> Now that I think of it, this isn't at all my idea, someone on IRC was
> talking about it. Are you the same person? If so, congratulations, you
> sold me on the idea well enough that now I'm trying to sell it back to
> you :)
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
More information about the SlackBuilds-users