A SHA1 collision was widely disclosed recently.
Our only use of plain SHA1 was removed in D17619, but we still make use of HMAC-SHA1 via PhabricatorHash::digest(). This isn't currently broken, and HMAC is designed to resist collisions, but it would be good to move away from it. However, doing so involves some considerations:
- Do ~all installs have SHA256, or are we going to run into issues where SHA256 isn't available?
- The security.hmac-key option is currently kind of a pile of garbage. In practice, it's just a hard-coded value for every Phabricator install. It would be much better to make this value unique per-install during setup. Ideally, we'd generate keys into some table and use a different, randomly generated key for each class of hash.
- We should probably rename PhabricatorHash::digest() to oldBadDigest() or similar, rather than suffer the curse of digest2pro_improved().
- We have ~40 callsites and these need to be individually audited and upgraded. Many probably present no security risk on SHA1, and many are ephemeral or can be transitioned easily, but some will be a pain to dig out.
- The introduction of D17625 puts some time pressure on this: we save a migration if we sneak a fancyNewDigest() in before anyone uploads any files to installs with the new integrity check code. Otherwise we need to keep code to validate the old hashes around.