On Tue, Jul 17, 2012 at 11:52 AM, Pascal Bleser
As long as it is very clear to everyone that MD5 hashes can be manipulated (quite easily, actually), then it's fine, but just don't confuse it for an authoritative source :)
But indeed, in this case, the X.509 of the HTTPS connection already provides an authenticity verification (as long as those are indeed verified, including on the hostname).
Pascal (or anyone), Ignoring the X.509 certificate: I find it much more troublesome that in most situations the hash comes from the same source as the package/data file. In those situations it is trivial to change the payload file, then just recalculate the hash and update it in the metadata file/source. Thus if the hash value itself can't be robustly trusted, there is no reason to worry about collision attacks which require far more resources than an attacker just updating the hash value to match his altered/infected payload file. My impression is that the proposed solution makes no effort to "sign" the metadata, thus if a attacker is able to access the distribution infrastructure to manipulate the payload, they could manipulate the metadata. Thus, other than the X.509 cert I argue that the whole proposed integrity mechanism as I understand it is broken from a authentication perspective no matter what hash is used, MD5 or otherwise. Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org