clj-commons / digest Goto Github PK

Hi! Thanks for writing this library!

I just upgraded my JVM version from java 1.8 to openjdk 11, and with that change the hashes generated by the digest/md5 function changed.

This creates a problem for me, as I use this library for generating hashes that are used to check uniqueness of images uploaded into a system. (by storing the generated hashed in a database)

Is this expected behaviour?

Thanks!

Hi!

It seems you are using the clojure logo in your tests. Sadly, said logo cannot be redistributed freely :(

https://grokbase.com/t/gg/clojure/153kzdtgk1/logo-licensing
https://groups.google.com/forum/#!topic/clojure/_o-sHr_YIwo

This mean that when I package this library in Debian, I need to repack your source code to remove it, and then replace the logo with something else.

I propose you use the Debian logo instead! It's under the GPLv3 and can be freely redistribued :) https://www.debian.org/logos/

If that works for you, I'd be happy to send a patch your way.

Cheers, and thanks for maintaining this library!

The single segment namespace digest is causing us issues here. Would it be too much to ask for digest to use something like yourorg.digest?

Currently...

The digest library generates its API at load time.

Clj-kondo will discover digest API vars when comments are not being skipped via this little trick:

But...

This did not work for cljdoc linting with clj-kondo because it disables checking comments.

Perhaps...

We could make digest even more clj-kondo friendly.

Idea 1 - Move declare

Move declare outside of comment block.
But this could get out of synch with digest API, I suppose.

Idea 2 - Create a hook

Create a custom clj-kondo hook for digest.
But since the API depends on querying available security providers, we might have the same issue as with idea 1?

Idea 3 - Generate API source

Instead of creating digest's API at load time, statically generate digest API source code.

Idea 4 - Just hand-code it

Instead of generating digest API automatically, do it by hand.
I mean, do the available providers change with new versions of Java?
And if they do, should the digest API be automatically changing?
Probably not.

Proposal

Without a deep understanding, idea 3 seems like a reasonable choice to me.
The API would be generated under a specific JVM (if that's important).
It is similar to idea 4 but perhaps a bit less prone to human error.
Thoughts?