[Slackbuilds-users] Retire MD5 for SHA256

[Tim Dickson]

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
>> check).
> 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
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>