apachesolr_site_hash() calls md5() twice

Trying to attach the patch again. It was attached before I submitted :\

@robertDouglass it won't need to be reindexed as the key is only generated once and then stored in the variable table.

@pwolanin the key generation code isn't a black box it is available as PHP source code in a public repository and distributed unencoded. There is no (psuedo) random value used so the key is reproducible. There is, at most, only 16^32 possible combinations outputted from the first call of md5(), so you are hashing a subset, then taking a sub set of that string as the final value, leaving you with less than 12^32 possible keys. The second md5() provides no benefit in generating unique or more secret keys. If the aim is "to reduce any possible information leakage about the private key", then introducing some randomness to the seed, such as mt_rand() or time() would better achieve this goal. Reopening as the current code doesn't fulfil its stated purpose.

@Scott Reynolds yes, but the key is only generated once then stored, so changing the key generation algorithm has no impact on existing users as their current key will remain unchanged and so not necessitate reindexing.

@Damien Tournoud I'm happy to do it either way, so long as it doesn't involve calling md5(md5()).

I'll wait for followup comments before rerolling.

uiniqid() only appends the the microseconds on *nix, under windows you only get the hexadecimal value, so you have 1 second windows for race conditions under windows. The risk of collisions under *nix are reduced, but to remove the risk (almost) completely on either platform, you could use the following:

$hash = substr(md5(uniqid($base_url), TRUE), 0, 12);

You end up with a unique key that has a random and a known component and the format remains unchanged from current implementation.

@Damien Tournoud

@skwashd: no, the hex part is the part that contains the time. The rest is controlled by the $more_entropy parameter, and the risk of collision is unbelievably small already.

OK, I was wrong. Did some RTFMing and leant something today.

Uniqueness is really not that big a worry. This value is only useful if you are running a multisite search or doing some reindexing tricks, and typically even those people will have just a few sites.

I have ~2100 production drupal sites using an pair of apache solr servers. Although I don't plan provision additional sites any time soon, I'd like to avoid the potential for race conditions when having aegir deploying 20 sites at a time.

reverting field changes