Does it matter? Yes: there's a qualitative difference in the types of attacks that would break your system. The elephant in the room, of course, is MD5, but let's examine the qualitative difference between the attacks first.
It is almost useless to publish the bad hashes, because as an adversary I could just distribute different versions to everyone. A million downloads? A million different ISO images, uniquely tailored with a special brand of malice.
What about publishing the good hashes? This is what you should do anyway, but you're restricted to MD5. How can I break this?
I'm an evil developer, and I play the long game.
I make three versions of a software package:
- the good one does what it is advertised to do which is something useful
- the bad one does something harmful noisily, like uploading credit card data to a bad place
- the sneaky one does something harmful quietly, like slowly making your screen look blurrier and blurrier over the course of a month, or silently disabling disk encryption
There's a sneaky catch: the good one and the sneaky one collide under MD5, but the bad one does not.
I publish the good package under my name, and the curators closely scrutinize it to audit the code and confirm it does what it claims. (Yeah, right!)
I hire someone, who lives in a closet under the stairs in the Ecuadorian embassy with nothing but his cat and his colossal narcissism to entertain himself, to break into the package servers and upload the bad package on one distribution server, and the sneaky package on all the other ones.
Someone notices the network traffic from credit card uploads and raises an alarm. The curators publish the good package's hash for everyone to verify their systems.
Everyone freaks out and stampedes to upgrade the software simultaneously.
Now everyone has the sneaky software, and if they check the MD5 hash they will rest assured that it's the good package's hash.
You could say this is convoluted. True, it is convoluted: I wouldn't try to pull this plan off, but that's in part because I'm not really evil. Evil people who are dedicated will use a convoluted plan if it works. A single NUL byte buffer overflow can, through a convoluted series of steps, be turned into remote code execution.
So what do you do? In your rush to rectify the poisoned ISO image, you could commission a careful multinational study of the technical capabilities of everyone on the planet who might be your adversary, and determine their risk aversion, technical sophistication, logistical planning, and chutzpah to see whether they would be capable of pulling off any attack in this class.
But that might cost a pretty penny and it might take a bit of time.
Fortunately, there's a much cheaper way to get a high degree of confidence that you thwart any plan of this sort, without having to study how convoluted the adversary's actions might have to be and whether that level of convolution is feasible.
Don't do something stupid like using MD5. Use a modern collision-resistant hash that isn't broken instead, like SHA-256, or SHAKE128, or BLAKE2b.
If you absolutely must use MD5 and MD5 alone, you could publish $(r, \operatorname{MD5}(r \mathbin\| n \mathbin\| m))$ where $r$ is chosen uniformly at random independently for each file (maybe as the HMAC-MD5 of $m$ under a secret key), $n$ is the name of the file including the version (encoded prefix-free, maybe with a length delimiter), and $m$ is the content of the file. (Of course, if the adversary knows or can predict $r$ before they choose $m$, then it's back to the same issue as standard MD5.) But chances are, it'll be much easier for you and your users if you just use a non-broken hash. SHA-256 has been available for a decade and a half.
