Moving forward

[CImrie]

We planned to merge this in to the stdlib in #2 but haven't heard more about it in some time (presume core members don't have much free time).

I am happy to start moving this package forward or work to getting it into crystal-community. I noticed that @stakach forked the package for use in crystal-community/jwt (e.g. the stakach/openssl_ext) package.

Given that we want it to work with different versions of OpenSSL (and likely LibSSL too), we should probably look at setting up an automated build process so that we can run the specs automatically against the different versions and latest version of Crystal (since it can change frequently).

@stakach do you have any thoughts on this?

[watzon]

Moving to crystal-community is a great idea imo. It would be great to get it integrated into the stdlib though seeing as the existing cryptography is already using OpenSSL. Is there a PR open?

[CImrie]

Thanks for the input @watzon. My tendency at the moment would be to set up a build pipeline to monitor it's working with the latest crystal version, then develop support for different OpenSSL and LibSSL versions (that are fully tested and working). I'm limited for time so welcome any contributions from the community for this.

While it does make sense to go into the stdlib, I'm not sure it's high enough quality for a PR submission yet. If we can support the different versions reliably I think the crystal maintainers would be more welcoming to the PR.

[stakach]

I think we should actually look at https://github.com/crystal-extras/openssl_ext fork which has many improvements and implements ECDSA support.

I think moving this lib to crystal-community and merging both my commits and the crystal-extras fork commits makes a lot of sense. We can improve things collaboratively with the core team from there, however I have a feeling they'd prefer to keep it as a separate lib.

[stakach]

I've merged all of the crystal-extras fork into my fork and updated JWT too.