2010/8/9 Justin Clift <jclift@xxxxxxxxxx>: > On 08/09/2010 06:56 AM, Matthias Bolte wrote: >> >> With the previous storage pool UUID source not all storage pools >> had a proper UUID, especially GSX storage pools. The mount path >> is unique per host and cannot change during the lifetime of the >> datastore. Therefore, its MD5 sum can be used as UUID. >> >> Use gnulib's crypto/md5 module to generate the MD5 sum. > > Just as a general thought, would it be preferably to use the SHA1 function > instead of the MD5 one? Every non-trivial hash function will do for the purpose of deriving a UUID from the mount path. > Asking because MD5 seems to be trending "out of favour" (as a > generalisation) compared to SHA1, after some cryptographers showed MD5 hash > collisions could be practically achieved with some types of data. (or > something along those lines) I'm aware of MD5 being considered as broken for cryptographic use cases, but this one isn't cryptographic so I don't care about the problem of crafted collisions here. The only real problem here would be when you have two datastores with different mount paths that hash to the same UUID, but I think md5 is collision-free enough so we can ignore this problem. There is another "problem" with the approach of using the mount path hash as UUID. In case of a Windows based GSX server you can use CIFS shares as datastores addressed via UNC paths like \\nas\share. If you have multiple GSX server sharing that datastore then all will have the same UUID because the have the same mount path. Actually I don't consider this as a real problem because in this case there is one datastore with one UUID shared between multiple hosts. > For all intents and purposes, I'm thinking it'll make no practical > functional difference, but figure it's worth asking. :) > gnulib also provides SHA1 and SHA256 so we could use those instead of MD5, but I think MD5 is good enough for this special use case here. Matthias -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list