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



_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Reply via email to