when new release?

[filipatbnp]

last release 0 11 5 is one year old (on Apr 28, 2022)

when new release?

[Azahe]

Personally, at our company we have lost hope it will ever happen, any significant improvement of this library seems to be blocked by the promise of prioritizing (delaying it to) version 1.0 which has (not exactly clear to me) scope that seems to be beyond maintainers available time.

What was the final straw for us was support of PKCS11 as a private key store (for using with HSM). We considered adding support ourselves but given current state of the codebase with the looming threat of loosing this with 1.0 upgrade (or having to implement it in two versions) we decided it would be faster to migrate our code to use: https://mvnrepository.com/artifact/com.nimbusds/nimbus-jose-jwt - which was actually quite simple, and it seems to just work (and has support of PKCS11) - its api is a little cruder (i.e. not fluent) but quite intuitive - I didn't need to read any docs to rewrite the code correctly.

[lhazlewood]

The 1.0 release has been challenging to say the least, because we're doing our best to still support existing behavior but enable the massive amount of cryptography work required for JWE, while still allowing total 'plugability' for custom algorithms and extensions. We're essentially feature complete now, but documentation is always difficult to get 'just right'. We pride ourselves on quality docs, and they always take time. Additionally, we're entirely volunteer-based - we can only do this outside of our normal work duties/responsibilities.

But don't lose hope! I know it's frustrating, but we've put an immense amount of work into this - there's no way we're going to just let that go stale, it'd be a waste of years worth of work.

So, the work is done, we're working on docs now, and that's all that's left. I hope that gives @Azahe some hope!

support of PKCS11 as a private key store (for using with HSM)

Can you elaborate on this? What wasn't working for you on the 0.11.x version? Lots of people use JJWT with HSMs, so I'm not sure what this means.

[lhazlewood]

@Azahe can you please indicate how you weren't able to support PKCS11 keys or HSMs using JJWT? There are a lot of people that use HSMs with JJWT, so I don't understand what problems you may have had. Please elaborate.

[Azahe]

We encountered seemingly the same thing that was attempted to be fixed in #704 - jjwt failing in the key length validation due to mismatched interface

It was happening for SignatureAlgorithm.RS256 using google cloud hsm.
I would have to put some effort to produce an example but it happened in SignatureAlgorithm.RS256#assertValid method (entry point was through DefaultJwtBuilder#signWith(Key key, SignatureAlgorithm alg)), else branch at line 420 - the key was not instance of RSAKey (as it was instance of sun.security.pkcs11.P11Key#P11PrivateKey).
Hacking around it was more effort than switching libraries.

Are there any publicly available examples of jjwt working with pkcs11/hsm that you could point me to?

[lhazlewood]

@Azahe how are you using Google Cloud HSM? They don't have a JCA provider, no?

[Azahe]

We are using SunPKCS11 provider (standard one I believe) and configure it as explained in: https://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html and https://github.com/GoogleCloudPlatform/kms-integrations/blob/master/kmsp11/docs/user_guide.md

which essentially boils down to something like:

Provider cryptoProvider = Security.getProvider("SunPKCS11");
cryptoProvider = cryptoProvider.configure("path/to/kms.cfg");
Security.addProvider(cryptoProvider);
// ... using provider to create key store to get key
KeyStore keystore = KeyStore.getInstance("PKCS11", cryptoProvider);
// ... then again using provider for signature access - but this might be unnecessary
Signature signature = Signature.getInstance("SHA256withRSA", cryptoProvider);

plus making sure config is accessible/correct and setting env variable KMS_PKCS11_CONFIG (pointing to the location of libkms-config.yml, which configures libkmsp11.so linked in kms.cfg)

[lhazlewood]

This is helpful thanks! As for publicly-referenced JJWT + PKCS11/HSM examples, I don't know of any - I just know of people who use them asking questions and saying things were working for them. Not helpful for this thread, I know, but I'd love to work with someone who'd help us create some examples! And even better, set something like this up for our CI environment.

[lhazlewood]

@Azahe , good news - the huge amount of work in the jwe branch was just merged to master.

We will attempt a release in the next week or two.

[yuedaxia76]

Have you confirmed the release date yet. Looking forward to release .

[OrangeBean]

any hope for release?

[lhazlewood]

'Real' (paid) work got in the way, I hope to be able to do this as soon as possible 😉

[olegbonar]

Very intrigued to see this released too

[lhazlewood]

A huge amount of work has been done on the upcoming release, and we're awfully close. I'm closing this since it doesn't represent active work for the JJWT codebase, but I hope (pray? 😅 ) that it'll be out in the next week or two at the latest.

[hertg]

@lhazlewood I saw that there are just tags but no releases on Github at this time. Would it be possible for you to also create a release after you published to Maven? I'm watching this repositories releases to get notified about new versions.

Thanks for your work. Looking forward to the JWK support.

[lhazlewood]

@hertg do you know if there's a way this can be automated? Ideally I'd rather not add another manual step to the release process, but we can certainly discuss how best to go about this.

[hertg]

@lhazlewood There is. I usually use the softprops/action-gh-release Github Action to automatically create Github Releases when I push tags. Here's an example from a project of mine: https://github.com/leftwm/leftwm-layouts/blob/ec4280dabebe2850ee39bb96808b2914c48abc9f/.github/workflows/publish.yml#L39-L43

Note

The body_path and prerelease arguments are optional, that's just a personal preference of mine. I usually have a CHANGELOG.md file in the repository which contains the release notes for the next release only.

With this configuration it will create a Github Release when I push a tag and use the contents of CHANGELOG.md as the release notes. The prerelease as I defined it will automatically mark the Github Release as "Prerelease" if the tag version contains -rc. (e.g. v1.2.0-rc.1).

I have some other projects where it also automatically adds the compiled binaries as attachments to the Github Release. That's probably more than what you're looking for, but just in case you're interested here's the link for that.

[lhazlewood]

Ooh, that's very nice, thank you for the references! I'll create a new issue to track this work - thank you!

[lhazlewood]

0.12.0 has been released! #848