It’s been over a year since I brought this topic up; since then, the Blake2 variant in the above has been in use at my day job in internal tooling.
There have been no issues with it in use there, though our use has the benefit of fitting perfectly within how I designed the function (benefits of being fully aware of our own use case before writing it…). I was also recently asked to add a license to the above by someone interested in using it in a reproducible science case.
I believe it is the right approach for this tooling going forward, and would like to move forward with proposing it as a standard. I believe it may also have utility in other emerging use cases, such as for tools that may implement things based on pep 739: PEP 739: Static description file for build details of Python installations, as it could be used to provide a singular hash for the state of the installation as it was recorded.
@sethmlarson @brettcannon I’m aware that there are concerns on using Blake2 since it is considered by some to be less available or less accessible than an option built on SHA-3 given that not all packaging tools are written in Python. Would providing multiple native implementations that can be used as either a library or a standalone application in python, zig, go, and rust be sufficient to alleviate these concerns and unblock the use of Blake2, or are there other concerns with deriving from Blake2 that need addressing?