v2.0.21

v2.0.21 07 Mar 2024

[Security]

• [jwe] Added jwe.Settings(jwe.WithMaxDecompressBufferSize(int64)) to specify the
  maximum size of a decompressed JWE payload. The default value is 10MB. If you
  are compressing payloads greater than this and want to decompress it during
  a call to jwe.Decrypt, you need to explicitly set a value large enough to
  hold that data.

  The same option can be passed to jwe.Decrypt to control this behavior on
  a per-message basis.

• [jwe] Added documentation stating that jwe.WithMaxBufferSize option will be
  renamed in future versions, i.e. v3

v1.2.29

v1.2.29 07 Mar 2024

[Security]

• [jwe] Added jwe.Settings(jwe.WithMaxDecompressBufferSize(int64)) to specify the
  maximum size of a decompressed JWE payload. The default value is 10MB. If you
  are compressing payloads greater than this, you need to explicitly set it.

  Unlike in v2, there is no way to set this globally. Please use v2 if this is required.

v2.0.20

v2.0.20 20 Feb 2024

[New Features]

• [jwe] Added jwe.Settings(WithMaxBufferSize(int64)) to set the maximum size of
  internal buffers. The default value is 256MB. Most users do not need to change
  this value.
• [jws] Allow jws.WithCompact() and jws.WithJSON() to be passed to jws.Parse() and
  jws.Verify(). These options control the expected serialization format for the
  JWS message.
• [jwt] Add jwt.WithCompactOnly() to specify that only compact serialization can
  be used for jwt.Parse(). Previously, by virtue of jws.Parse() allowing either
  JSON or Compact serialization format, jwt.Parse() also alloed JSON serialization
  where as RFC7519 explicitly states that only compact serialization should be
  used. For backward compatibility the default behavior is not changed, but you
  can set this global option for jwt: jwt.Settings(jwt.WithCompactOnly(true))

[Miscellaneous]

• Internal key conversions should now allow private keys to be used in place of
  public keys. This would allow you to pass private keys where public keys are
  expected.

v2.0.19

v2.0.19 09 Jan 2024
[New Features]
  * [jws] Added jws.IsVerificationError to check if the error returned by `jws.Verify`
    was caused by actual verification step or something else, for example, while fetching
    a key from datasource

[Security Fixes]
  * [jws] JWS messages formated in full JSON format (i.e. not the compact format, which
    consists of three base64 strings concatenated with a '.') with missing "protected"
    headers could cause a panic, thereby introducing a possiblity of a DoS.

    This has been fixed so that the `jws.Parse` function succeeds in parsing a JWS message
    lacking a protected header. Calling `jws.Verify` on this same JWS message will result
    in a failed verification attempt. Note that this behavior will differ slightly when
    parsing JWS messages in compact form, which result in an error.

v1.2.28

v1.2.28 09 Jan 2024
[Security Fixes]
  * [jws] JWS messages formated in full JSON format (i.e. not the compact format, which
    consists of three base64 strings concatenated with a '.') with missing "protected"
    headers could cause a panic, thereby introducing a possiblity of a DoS.

    This has been fixed so that the `jws.Parse` function succeeds in parsing a JWS message
    lacking a protected header. Calling `jws.Verify` on this same JWS message will result
    in a failed verification attempt. Note that this behavior will differ slightly when
    parsing JWS messages in compact form, which result in an error.

v2.0.18

v2.0.18 03 Dec 2023
[Security Fixes]
  * [jwe] A large number in p2c parameter for PBKDF2 based encryptions could cause a DoS attack,
    similar to https://nvd.nist.gov/vuln/detail/CVE-2022-36083.  All users who use JWE via this
    package should upgrade. While the JOSE spec allows for encryption using JWE on JWTs, users of
    the `jwt` package are not immediately susceptible unless they explicitly try to decrypt
    JWTs -- by default the `jwt` package verifies signatures, but does not decrypt messages.
    [GHSA-7f9x-gw85-8grf]

v1.2.27

v1.2.27 - 03 Dec 2023
[Security]
  * [jwe] A large number in p2c parameter for PBKDF2 based encryptions could cause a DoS attack,
    similar to https://nvd.nist.gov/vuln/detail/CVE-2022-36083.  All users should upgrade, as
    unlike v2, v1 attempts to decrypt JWEs on JWTs by default.
    [GHSA-7f9x-gw85-8grf]

[Bug Fixes]
  * [jwk] jwk.Set(jwk.KeyOpsKey, <jwk.KeyOperation>) now works (previously, either
     Set(.., <string>) or Set(..., []jwk.KeyOperation{...}) worked, but not a single
     jwk.KeyOperation

v2.0.17

v2.0.17 20 Nov 2023
[Bug Fixes]
  * [jws] Previously, `jws.UnregisterSigner` did not remove the previous signer instance when
    the signer was registered and unregistered multiple times (#1016). This has been fixed.

[New Features]
  * [jwe] (EXPERIMENTAL) `jwe.WithCEK` has been added to extract the content encryption key (CEK) from the Decrypt operation.
  * [jwe] (EXPERIMENTAL) `jwe.EncryptStatic` has been added to encrypt content using a static CEK.
    Using static CEKs has serious security implications, and you should not use
    this unless you completely understand the risks involved.

v2.0.16

v2.0.16 31 Oct 2023
[Security]
  * [jws] ECDSA signature verification requires us to check if the signature
    is of the desired length of bytes, but this check that used to exist before
    had been removed in #65, resulting in certain malformed signatures to pass
    verification.

    One of the ways this could happen if R is a 31 byte integer and S is 32 byte integer,
    both containing the correct signature values, but R is not zero-padded.

       Correct = R: [ 0 , ... ] (32 bytes) S: [ ... ] (32 bytes)
       Wrong   = R: [ ... ] (31 bytes)     S: [ ... ] (32 bytes)

    In order for this check to pass, you would still need to have all 63 bytes
    populated with the correct signature. The only modification a bad actor
    may be able to do is to add one more byte at the end, in which case the
    first 32 bytes (including what would have been S's first byte) is used for R,
    and S would contain the rest. But this will only result in the verification to
    fail. Therefore this in itself should not pose any security risk, albeit
    allowing some illegally formated messages to be verified.

  * [jwk] `jwk.Key` objects now have a `Validate()` method to validate the data
    stored in the keys. However, this still does not necessarily mean that the key's
        are valid for use in cryptographic operations. If `Validate()` is successful,
    it only means that the keys are in the right _format_, including the presence
    of required fields and that certain fields have proper length, etc.

[New Features]
  * [jws] Added `jws.WithValidateKey()` to force calling `key.Validate()` before
    signing or verification.

  * [jws] `jws.Sign()` now returns a special type of error that can hold the
    individual errors from the signers. The stringification is still the same
    as before to preserve backwards compatibility.

  * [jwk] Added `jwk.IsKeyValidationError` that checks if an error is an error
    from `key.Validate()`.

[Bug Fixes]
  * [jwt] `jwt.ParseInsecure()` was running verification if you provided a key
    via `jwt.WithKey()` or `jwt.WithKeySet()` (#1007)

v2.0.15

v2.0.15 19 20 Oct 2023
[Bug fixes]
  * [jws] jws.Sign() now properly check for valid algorithm / key type pair when
    the key implements crypto.Signer. This was caused by the fact that when 
    jws.WithKey() accepted keys that implemented crypto.Signer, there really
    is no way to robustly check what algorithm the crypto.Signer implements.

    The code has now been modified to check for KNOWN key types, i.e. those
    that are defined in Go standard library, and those that are defined in
    this library. For example, now calling jws.Sign() with jws.WithKey(jwa.RS256, ecdsaKey)
    where ecdsaKey is either an instance of *ecdsa.PrivateKey or jwk.ECDSAPrivateKey
    will produce an error.

    However, if you use a separate library that wraps some KMS library which implements
    crypto.Signer, this same check will not be performed due to the fact that
    it is an unknown library to us. And there's no way to query a crypto.Signer
    for its algorithm family.