build(deps): bump io.jsonwebtoken:jjwt-api from 0.11.2 to 0.12.7

[dependabot]

Bumps io.jsonwebtoken:jjwt-api from 0.11.2 to 0.12.7.

Release notes

Sourced from io.jsonwebtoken:jjwt-api's releases.

0.12.7

This patch release:

• Adds a new Maven BOM! This is useful for multi-module projects. See Issue 967.

• Allows the JwtParserBuilder to have empty nested algorithm collections, effectively disabling the parser's associated feature:

  • Emptying the zip() nested collection disables JWT decompression.
  • Emptying the sig() nested collection disables JWS mac/signature verification (i.e. all JWSs will be unsupported/rejected).
  • Emptying either the enc() or key() nested collections disables JWE decryption (i.e. all JWEs will be unsupported/rejected)

  See Issue 996.

• Fixes bug 961 where JwtParserBuilder nested collection builders were not correctly replacing algorithms with the same id.

• Ensures a JwkSet's keys collection is no longer entirely secret/redacted by default. This was an overzealous default that was unnecessarily restrictive; the keys collection itself should always be public, and each individual key within should determine which fields should be redacted when printed. See Issue 976.

• Improves performance slightly by ensuring all jjwt-api utility methods that create *Builder instances (Jwts.builder(), Jwts.parserBuilder(), Jwks.builder(), etc) no longer use reflection.

  Instead,static factories are created via reflection only once during initial jjwt-api classloading, and then *Builders are created via standard instantiation using the new operator thereafter. This also benefits certain environments that may not have ideal ClassLoader implementations (e.g. Tomcat in some cases).

  NOTE: because this changes which classes are loaded via reflection, any environments that must explicitly reference reflective class names (e.g. GraalVM applications) will need to be updated to reflect the new factory class names.

  See Issue 988.

• Upgrades the Gson dependency to 2.11.0

• Upgrades the BouncyCastle dependency to 1.78.1

New Contributors

• @​sigpwned made their first contribution in jwtk/jjwt#968
• @​TheMrMilchmann made their first contribution in jwtk/jjwt#979
• @​atanasg made their first contribution in jwtk/jjwt#974

Full Changelog: jwtk/jjwt@0.12.6...0.12.7

0.12.6

This patch release:

• Ensures that after successful JWS signature verification, an application-configured Base64Url Decoder output is used to construct a Jws instance (instead of JJWT's default decoder). See jwtk/jjwt#947.
• Fixes a decompression memory leak in concurrent/multi-threaded environments introduced in 0.12.0 when decompressing JWTs with a zip header of GZIP. See jwtk/jjwt#949.
• Upgrades BouncyCastle to 1.78 via jwtk/jjwt#941
• Usees Acsiidoc as README format by @​bdemers in jwtk/jjwt#777
• Allows using GenericSecret for HmacSHA* algorithms by @​mnylen in jwtk/jjwt#935
• Enables JWE arbitrary content compression by @​mnylen in jwtk/jjwt#937

New Contributors

• @​mnylen made their first contribution in jwtk/jjwt#935

Full Changelog: jwtk/jjwt@0.12.5...0.12.6

0.12.5

This release fixes issue #916 and ensures that builders' NestedCollection changes are applied to the collection immediately as mutation methods are called, no longer requiring application developers to call .and() to 'commit' or apply a change. For example, prior to this release, the following code did not apply changes:

JwtBuilder builder = Jwts.builder();
builder.audience().add("an-audience"); // no .and() call
</tr></table> 

... (truncated)

Changelog

Sourced from io.jsonwebtoken:jjwt-api's changelog.

0.12.7

This patch release:

• Adds a new Maven BOM, useful for multi-module projects. See Issue 967.

• Allows the JwtParserBuilder to have empty nested algorithm collections, effectively disabling the parser's associated feature:

  • Emptying the zip() nested collection disables JWT decompression.
  • Emptying the sig() nested collection disables JWS mac/signature verification (i.e. all JWSs will be unsupported/rejected).
  • Emptying either the enc() or key() nested collections disables JWE decryption (i.e. all JWEs will be unsupported/rejected)

  See Issue 996.

• Fixes bug 961 where JwtParserBuilder nested collection builders were not correctly replacing algorithms with the same id.

• Ensures a JwkSet's keys collection is no longer entirely secret/redacted by default. This was an overzealous default that was unnecessarily restrictive; the keys collection itself should always be public, and each individual key within should determine which fields should be redacted when printed. See Issue 976.

• Improves performance slightly by ensuring all jjwt-api utility methods that create *Builder instances (Jwts.builder(), Jwts.parserBuilder(), Jwks.builder(), etc) no longer use reflection.

  Instead,static factories are created via reflection only once during initial jjwt-api classloading, and then *Builders are created via standard instantiation using the new operator thereafter. This also benefits certain environments that may not have ideal ClassLoader implementations (e.g. Tomcat in some cases).

  NOTE: because this changes which classes are loaded via reflection, any environments that must explicitly reference reflective class names (e.g. GraalVM applications) will need to be updated to reflect the new factory class names.

  See Issue 988.

• Upgrades the Gson dependency to 2.11.0

• Upgrades the BouncyCastle dependency to 1.78.1

0.12.6

This patch release:

• Ensures that after successful JWS signature verification, an application-configured Base64Url Decoder output is used to construct a Jws instance (instead of JJWT's default decoder). See Issue 947.
• Fixes a decompression memory leak in concurrent/multi-threaded environments introduced in 0.12.0 when decompressing JWTs with a zip header of GZIP. See Issue 949.
• Upgrades BouncyCastle to 1.78 via PR 941.
• Ensures that a JwkSet's keys list member is no longer considered secret and is not redacted by default. However, each individual JWK element within the keys list may still have redacted private or secret members as expected. See Issue 976.

0.12.5

This patch release:

• Ensures that builders' NestedCollection changes are applied to the collection immediately as mutation methods are called, no longer requiring application developers to call .and() to 'commit' or apply a change. For example, prior to this release, the following code did not apply changes:

  JwtBuilder builder = Jwts.builder();
  builder.audience().add("an-audience"); // no .and() call
  builder.compact(); // would not keep 'an-audience'

  Now this code works as expected and all other NestedCollection instances like it apply changes immediately (e.g. when calling .add(value)).

  However, standard fluent builder chains are still recommended for readability when feasible, e.g.

... (truncated)

Commits

• 77aeda0 [maven-release-plugin] prepare release 0.12.7
• 47d966f Testing latest sonatype central publishing guidelines
• 22ca29f [maven-release-plugin] rollback the release of 0.12.7
• 0487f9b [maven-release-plugin] prepare for next development iteration
• 4329125 [maven-release-plugin] prepare release 0.12.7
• 0ddc514 - Ensured JJWT_RELEASE_VERSION placeholders reference 0.12.7
• efed1cf Updated 0.12.7 change list
• ca27b12 Resolves #1010 (#1011)
• 55c7b9a Resolves #771 (#1009)
• 6e9c6a5 Bump org.bouncycastle:bcpkix-jdk18on from 1.78 to 1.78.1 (#1008)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)