[Slackbuilds-users] MD5 hash sums

T3 slider t3slider at gmail.com
Thu Aug 23 05:45:44 UTC 2018

On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy <lists at osh.id.au> wrote:

> For an
> attacker to change the upstream source archive without changing the MD5
> requires a 2nd preimage attack, which as far as I understand is not
> computationally feasible at present. This is different to a much simpler
> collision attack, where the attacker generates two _new_ archives with
> new (and matching) MD5s.

The download files do not necessarily have to be tar archives, and in some
cases (generally those with multiple download files and therefore multiple
checksums), individual files can be included for download. Intentional PDF
collisions have been around for ages (see
https://www.mscs.dal.ca/~selinger/md5collision/ ), so if a SlackBuild
includes some documentation as a download link, and the upstream server has
since been compromised, a user could definitely be stuck with a malicious
file even if the SlackBuild maintainer did everything right and verified
upstream signatures. It is probably more difficult to generate tarballs
with collisions but I'm guessing it isn't quite as difficult as we're
pretending it is, and it's irrelevant since unzipped files can be passed as
download links.

Simply put, this is bad security. Anyone who disagrees doesn't understand
the problem. Can't we just add an optional sha256sum in the .info file and
maintainers can gradually add these checksums to their SlackBuilds,
targeting some point in the future that these fields will be required (and
possibly the md5s retired)?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20180823/d641dd2a/attachment.html>

More information about the SlackBuilds-users mailing list