New package: Hashing v0.0.1

[JuliaRegistrator]

• Registering package: Hashing
• Repository: https://github.com/erich-9/Hashing.jl
• Created by: @erich-9
• Version: v0.0.1
• Commit: feefd6606b9ecec4942db98afccfcea163da3e42
• Reviewed by: @erich-9
• Reference: erich-9/CryptographicHashFunctions.jl@feefd66#commitcomment-141188686
• Description: Fast cryptographic hash functions for Julia

[github-actions]

Your new package pull request does not meet the guidelines for auto-merging. Please make sure that you have read the General registry README and the AutoMerge guidelines. The following guidelines were not met:

• Package name similar to 3 existing packages.
  1. Similar to Meshing. Damerau-Levenshtein distance 2 is at or below cutoff of 2. Normalized visual distance 1.03 is at or below cutoff of 2.50.
  2. Similar to Caching. Damerau-Levenshtein distance 2 is at or below cutoff of 2. Normalized visual distance 2.36 is at or below cutoff of 2.50.
  3. Similar to Hashids. Damerau-Levenshtein distance 2 is at or below cutoff of 2.

Note that the guidelines are only required for the pull request to be merged automatically. However, it is strongly recommended to follow them, since otherwise the pull request needs to be manually reviewed and merged by a human.

After you have fixed the AutoMerge issues, simply retrigger Registrator, which will automatically update this pull request. You do not need to change the version number in your Project.toml file (unless of course the AutoMerge issue is that you skipped a version number, in which case you should change the version number).

If you do not want to fix the AutoMerge issues, please post a comment explaining why you would like this pull request to be manually merged. Then, send a message to the #pkg-registration channel in the Julia Slack to ask for help. Include a link to this pull request.

Since you are registering a new package, please make sure that you have also read the package naming guidelines: https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines

---

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment. You can edit blocking comments, adding [noblock] to them in order to unblock auto-merging.

[LilithHafner]

Thanks for the package! It would be much easier to tell what this package is for and how to use it if it had documentation.

[noblock]

[gdalle]

Congrats on the registration! I agree with Lilith, and I would also suggest changing the name to something more specific. A package as generic as Hashing.jl might make people believe it is related to hash tables, and therefore possibly part of Julia's standard library.

[erich-9]

Thanks for the comments!

The package is intended to be usable in place of SHA.jl where performance matters. It also extends the functionality.

I just finished writing the first version of the documentation. I hope it clarifies why I believe the name to be well chosen.

[noblock]

[gdalle]

[noblock]
Indeed the documentation is a welcome addition. To someone like me, unfamiliar with cryptography, Hashing.jl still sounds too closely related to standard library objects like sets or dicts, implemented with hash tables. How about CryptographicHashing.jl? Longer package names are almost never a bad thing

[erich-9]

Yes, I also considered this name before registration. But in my opinion it's too bulky for such a basic package (just think of collecting the non-cryptographic hash functions you mentioned in a package named NonCryptographicHashing.jl).

Anyway, I think you have a point and maybe there's a less ambiguous name (choosing the current one, I was in particular influenced by the name of the comparable Python package hashlib).

Taking the Rust crate hashes as an inspiration for the name Hashes.jl would probably not resolve ambiguities... But then there's the closely related crate digest, which defines the traits implemented by the (cryptographic) hash algorithms. So what do you think of Digests.jl? It'll probably make the package somewhat harder to find, since people nowadays speak of hashes instead of digests. But that's fine with me.

[LilithHafner]

If it were up to me (which it's not) I would call it CryptographicHashFunctions.jl or CryptographicHashing.jl, both of which would autocomplete after "]add Cryptog", whereas Hasing.jl would autocomplete after "]add Hashin".

I like packages that, when possible, tell me a pretty complete story about themselves from the name alone.

The story I would tell about this package is

It provides pretty much all the cryptographic hash functions you could want, and does so at high performance using _jll libraries that link to external libraries that use platform dependent hardware acceleration.

From that, "high performance" is not something that should imo be included in the name, otherwise every other package would be HighPerforamnceBlah.jl (though well done, this is much faster than SHA.jl on my hardware). The fact that it uses _jll libraries is an implementation detail. In theory someone could contribute faster or similarly performant implementations written in Julia and it would not be breaking to switch to thoes, hence that should not belong in the name. That leaves "cryptographic hash functions", so I would call it CryptographicHashFunctions.jl and only ever type Cryptog[tab] because I'm lazy and my editors and Pkg both autocomplete.

Separately, this is a pretty nice package (from the very limited poking at it that I've done) and when folks search for "cryptographic hash functions in Julia", I want this to come up. The name CryptographicHashFunctions.jl is a great match for that search query. Searching "hashing in julia" on Brave, the top seven answers are related to the Base.hash function, which is understandable because that is a much more common usage of the word "hash" than cryptographic usage (most programming is not in adversarial contexts). The fact that the this package's hash functions have nice cryptographic properties (except for MD4/MD5/etc.) is a key feature of this package that sets it apart from Base.hash. I think that should be reflected in the name.

(I don't think Digests.jl is an improvement.)

[noblock]

[erich-9]

Thanks for the detailed and helpful opinion. You convinced me and I'll call it CryptographicHashFunctions.jl after all. As it happens, it'll then be a direct descendant of SHA.jl via the following chain of Wikipedia quasi-synonyms (which I'm not going to follow to the end): SHA ➔ SecureHashAlgorithms ➔ SecureHashFunctions ➔ CryptographicHashFunctions ➔ CHF

This pull request can thus be closed. I'll open a new one for the renamed package.

[goerz]

Closed in favor of https://github.com/erich-9/CryptographicHashFunctions.jl