[tialaramex]

In practice today this requires that the bad actor collaborates with the real distributor.

MD5 fails to _collision_. A collision is when you can find two different things with the same hash. But being able to collide the hash is NOT the same as being able to find a second pre-image, which is what you'd need in order to get "phony files that appear to check out" if the person who originally issued the MD5 checksums didn't collaborate with you.

[kilburn]

There have been practical demonstrations of using padding in several formats to generate valid files that collision with an original one, but with entirely different contents.

This means that it is possible that someone could download the real image, introduce some rootkit, and then tinker that (for instance, by adding a hidden file with carefuly crafted content) until the resulting md5 is the same as that of the original image. Then hack the server and upload the modified image in place of the original one, and everyone who installs Dragonfly is now their minion.

If you use a stronger hash (which is not harder for anyone than using md5), then this attack vector becomes impossible. So... even if it is a remote possibility, just use the stronger hash because it is just a dominant strategy (it has upsides, yet 0 downsides).

[temprature]

There have been no practical demonstrations of colliding the MD5 of an arbitrary file (ie. pre-image attack), only situations where two files are created specifically with the intended purpose of creating a collision. This is precisely what the post you replied to said but you seem to have not understood that there's a distinction.

Yes, it is possible that the DragonFly developers could collude to create two ISOs with the same MD5, one good and one malicious. No, it is not possible that random, evil ne'erdowells could replace the ISO with one with the same MD5, unless the DragonFly developers have conspired with them to make that possible.

If you don't trust the DragonFly developers not to collide the MD5s, you probably shouldn't trust them with the code running in your kernel anyway.