Always feels good to close old bugs, even if done unintentionally. In one of the projects I’m working on, I ran into the lack of SHA-512 support in glib and decided to step in. It turned out that such support was requested in a bug reported 3 years ago.
Whatever the reasons, the good news is that the next release of glib will ship with support for SHA-512 hashing in GChecksum. The implementation strictly follows the FIPS-180-2 standard.
Thanks to Emmanuele Bassi for reviewing my patch, Julian Andres Klode for merging it, and Igalia for sponsoring my dedication.
It also was the first time I pushed something to glib. Given that I reported the bug, it seemed like the right thing for me to push the fix. Thanks for your work on this.
Rationale for using 384 instead of 512 or 256:
https://plus.google.com/114471118004229223857/posts/hzoUxXhhkBf
What about SHA-3?
Mathias, thanks for the link. Thing is that in practice, SHA-512 is far more commonly used than SHA-384, at least from my experience. In fact, I don’t know any piece of software using the truncated version right now. I won’t argue about the reasons, since I’m not an expert.
So I would say that when people start coming with use cases for SHA-384 support, it will get into glib. (as you know from the bug report, the algorithm is already implemented).
foo: SHA-3 will be supported when we have real world glib apps needing it, I guess.