Skip to content

Releases: lestrrat-go/jwx

v2.0.14

17 Oct 01:11
Compare
Choose a tag to compare
v2.0.14 17 Oct 2023
  [New Features]
  * [jwk] jwk.IsPrivateKey(), as well as jwk.AsymmetricKey has been added.
    The function can be used to tell if a jwk.Key is a private key of an
    asymmetric key pair.
  [Security]
  * golang.org/x/crypto has been updated to 0.14.0. The update contains a fix for HTTP/2
    rapid reset DoS vulnerability, which some security scanning softwares may flag.
    However, do note that this library is NOT affected by the issue, as it does not have
    the capability to serve as an HTTP/2 server. This is included in this release
    document so that users will be able to tell why this library may be flagged
    when/if their scanning software do so.

v2.0.13

26 Sep 09:16
be93b3f
Compare
Choose a tag to compare
v2.0.13 26 Sep 2023
[New Features]
  * [jwk] jwk.Equal has been added. Please note that this is equivalent to
  comparing the keys' thumbprints, therefore it does NOT take in consideration
  non-essential fields.

[Miscellaneous]
  * Various documentation fixes and additions.

v2.0.12

10 Aug 02:56
466c277
Compare
Choose a tag to compare
v2.0.12 - 11 Aug 2023
[Bug fixes]
  * [jwt] jwt.Serializer was ignoring JWE flags (#951)

[Miscellaneous]
  * [jwk] Check for seed length on OKP JWKs to avoid panics (#947)
  * [jws] Documentation for jws.WithKeySet()

[SECURITY] v2.0.11

14 Jun 08:18
6c41e38
Compare
Choose a tag to compare
v2.0.11 - 14 Jun 2023
[Security]
  * Potential Padding Oracle Attack Vulnerability and Timing Attack Vulnerability
    for JWE AES-CBC encrypted payloads affecting all v2 releases up to v2.0.10,
    all v1 releases up to v1.2.25, and all v0 releases up to v0.9.2 have been reported by
    @shogo82148.

    Please note that v0 versions will NOT receive fixes.
    This release fixes these vulnerabilities for the v2 series.

[SECURITY] v1.2.26

14 Jun 08:17
d9ddbc8
Compare
Choose a tag to compare
v1.2.26 - 14 Jun 2023
[Security]
  * Potential Padding Oracle Attack Vulnerability and Timing Attack Vulnerability
    for JWE AES-CBC encrypted payloads affecting all v2 releases up to v2.0.10,
    all v1 releases up to v1.2.25, and all v0 releases up to v0.9.2 have been reported by
    @shogo82148.

    Please note that v0 versions will NOT receive fixes.
    This release fixes these vulnerabilities for the v1 series.

v2.0.10

12 Jun 07:27
8840ffd
Compare
Choose a tag to compare
v2.0.10 - 12 Jun 2023
[New Features]
  * [jwe] (EXPERIMENTAL) Added `jwe.KeyEncrypter` and `jwe.KeyDecrypter` interfaces
    that works in similar ways as how `crypto.Signer` works for signature
    generation and verification. It can act as the interface for your encryption/decryption
    keys that are for example stored in an hardware device.

    This feature is labeled experimental because the API for the above interfaces have not
    been battle tested, and may need to changed yet. Please be aware that until the API
    is deemed stable, you may have to adapat our code to these possible changes,
    _even_ during minor version upgrades of this library.

[Bug fixes]
  * Registering JWS signers/verifiers did not work since v2.0.0, because the
     way we handle algorithm names changed in 2aa98ce6884187180a7145b73da78c859dd46c84.
    (We previously thought that this would be checked by the example code, but it
     apparently failed to flag us properly)

    The logic behind managing the internal database has been fixed, and
    `jws.RegisterSigner` and `jws.RegisterVerifier` now properly hooks into the new
    `jwa.RegisterSignatureAlgorithm` to automatically register new algorithm names
    (#910, #911)
[Miscellaneous]
  * Added limited support for github.com/segmentio/asm/base64. Compile your code
    with the `jwx_asmbase64` build tag. This feature is EXPERIMENTAL.

    Through limited testing, the use of a faster base64 library provide 1~5% increase
    in throughput on average. It might make more difference if the input/output is large.
    If you care about this performance improvement, you should probably enable
    `goccy` JSON parser as well, by specifying `jwx_goccy,jwx_asmbase64` in your build call.
  * Slightly changed the way global variables underneath `jwk.Fetch` are initialized and
    configured. `jwk.Fetch` creates an object that spawns wokers to fetch JWKS when it's
    first called.
    You can now also use `jwk.SetGlobalFetcher()` to set a fetcher object which you can
    control.

v2.0.9

21 Mar 03:31
fccc524
Compare
Choose a tag to compare
v2.0.9 - 21 Mar 2023
[Security Fixes]
  * Updated use of golang.org/x/crypto to v0.7.0
[Bug fixes]
  * Emitted PEM file for EC private key types used the wrong PEM armor (#875)
[Miscellaneous]
  * Banners for generated files have been modified to allow tools to pick them up (#867)
  * Remove unused variables around ReadFileOption (#866)
  * Fix test failures
  * Support bazel out of the box
  * Now you can create JWS messages using `{"alg":"none"}`, by calling `jws.Sign()`
    with `jws.WithInsecureNoSignature()` option. (#888, #890).

    Note that there is no way to call
    `jws.Verify()` while allowing `{"alg":"none"}` as you wouldn't be _verifying_
    the message if we allowed the "none" algorithm. `jws.Parse()` will parse such
    messages witout verification.

    `jwt` also allows you to sign using alg="none", but there's no symmetrical
    way to verify such messages.

v2.0.8

25 Nov 01:00
7803b82
Compare
Choose a tag to compare
v2.0.8 - 25 Nov 2022
[Security Fixes]
  * [jws][jwe] Starting from go 1.19, code related to elliptic algorithms
    panics (instead of returning an error) when certain methods
    such as `ScalarMult` are called using points that are not on the
    elliptic curve being used.

    Using inputs that cause this condition, and you accept unverified JWK
    from the outside it may be possible for a third-party to cause panics
    in your program.

    This has been fixed by verifying that the point being used is actually
    on the curve before such computations (#840)
[Miscellaneous]
  * `jwx.GuessFormat` now returns `jwx.InvalidFormat` when the heuristics
    is sure that the buffer format is invalid.

v2.0.7

15 Nov 01:58
Compare
Choose a tag to compare
v2.0.7 - 15 Nov 2022
[New features]
  * [jwt] Each `jwt.Token` now has an `Options()` method
  * [jwt] `jwt.Settings(jwt.WithFlattenedAudience(true))` has a slightly
    different semantic than before. Instead of changing a global variable,
    it now specifies that the default value of each per-token option for
    `jwt.FlattenAudience` is true.

    Therefore, this is what happens:

       // No global settings
       tok := jwt.New()
       tok.Options.IsEnabled(jwt.FlattenAudience) // false

       // With global settings
       jwt.Settings(jwt.WithFlattenedAudience(true))
       tok := jwt.New()
       tok.Options.IsEnabled(jwt.FlattenAudience) // true
       // But you can still turn FlattenAudience off for this
       // token alone
       tok.Options.Disable(jwt.FlattenAudience)

    Note that while unlikely to happen for users relying on the old behavior,
    this change DOES introduce timing issues: whereas old versions switched the
    JSON marshaling for ALL tokens immediately after calling `jwt.Settings`,
    the new behavior does NOT affect tokens that have been created before the
    call to `jwt.Settings` (but marshaled afterwards).

    So the following may happen:

      // < v2.0.7
      tok := jwt.New()
      jwt.Settings(jwt.WithFlattenedAudience(true))
      json.Marshal(tok) // flatten = on

      // >= v2.0.7
      tok := jwt.New() // flatten = off
      jwt.Settings(jwt.WithFlattenedAudience(true))
      json.Marshal(tok) // flatten = on

      // >= v2.0.7
      tok := jwt.New() // flatten = off
      jwt.Settings(jwt.WithFlattenedAudience(true))
      json.Marshal(tok) // flatten is still off

    It is recommended that you only set the global setting once at the
    very beginning of your program to avoid problems.

    Also note that `Clone()` copies the settings as well.

v2.0.6

25 Aug 13:21
9295064
Compare
Choose a tag to compare
v2.0.6 - 25 Aug 2022
[Bug fixes][Security]
  * [jwe] Agreement Party UInfo and VInfo (apv/apu) were not properly being
    passed to the functions to compute the aad when encrypting using ECDH-ES
    family of algorithms. Therefore, when using apu/apv, messages encrypted
    via this module would have failed to be properly decrypted.

    Please note that bogus encrypted messages would not have succeed being
    decrypted (i.e. this problem does not allow spoofed messages to be decrypted).
    Therefore this would not have caused unwanted data to to creep in --
    however it did pose problems for data to be sent and decrypted from this module
    when using ECDH-ES with apu/apv.

    While not extensively tested, we believe this regression was introduced
    with the v2 release.