Go Jose Versions Save

An implementation of JOSE standards (JWE, JWS, JWT) in Go

v2.6.0

2 years ago

Last release from the v2 branch, includes various changes and bug fixes.

For future releases please see v3 at: http://github.com/go-jose/go-jose

v2.5.1

3 years ago

Bug Fixes

  • Fix parsing and validation of x5t and x5t#S256 headers for JWK (h/t @mangas) (#305).

v2.5.0

4 years ago

New Features

  • Add support for x5u, x5t, and x5t#S256 headers for JWK (#242).
  • Add support for RFC 7638 canonical kid for JWK (#269).

Bug Fixes

  • Add error checking in jose-util to avoid nil referencing (#250).
  • Documentation improvements (#274, #280, #289).

v2.4.1

4 years ago

Bug Fixes

  • Fixes a bug introduced in v2.4.0 that could cause a panic on invalid inputs (#282).
  • Improves performance of parsing payloads with a lot of whitespace (#279).

v2.4.0

4 years ago

New Features

  • Add support for the b64 header parameter (#230).
  • Add functions to handle detached signatures (#234).
  • Expose an interface for opaque key encryption/decryption (#261, #257).

Bug Fixes

  • Fixes a issue with ECDSA on P-521, whereby the generated shared secret derived for encryption was computed incorrectly (#267, #245).
  • Fixes salt length for new RSA-PSS messages to be equal to the hash length, as required by RFC 3447 (#232).
  • Don't include the kid header in a JWT if the key id is an empty string (#227).

v2.3.1

5 years ago

Fixes a bug in the serialization of ED25519 keys to JWK (JSON), where X/D values ended up being switched for one another in the serialized output (see #224). Reading a serialized private key would also end up switching the X/D values for another, so keys that were serialized/deserialized with old versions of go-jose would work fine (values should end up in the correct place again). However, sharing a private key with another library would have caused problems. If you have private keys that were previously serialized to JWK using this library, the X/D values will be incorrect and will need to be switched in the JSON serialization before the key can be deserialized with an updated version of go-jose.

v2.3.0

5 years ago

New Features

  • Add support for unwrapping JSON Web Key Set in the jwt sub-package. This means the key passed to Claims or Decrypt can now be a set of keys (of type *jose.JSONWebKeySet), and the key will be selected automatically based on the key id in the header of the token.

Bug Fixes

  • Improves handling of exp, iat and nbf claims. This means proper handling for zero dates (#214), don't error if optional exp and nbf claims are missing from the token (#220), and perform an extra check on iat if it is present (#217). Note that expiration in tokens is optional per standard, if you want to require expiration or other claims to be absolutely present in a token be sure to check the claim is present.

Note this release also drops support for Go 1.5 and Go 1.6, we now require Go 1.7 or later.

v2.2.2

5 years ago

Exports the random reader used for internal randomness to make deterministic tests possible (#212). This allows consumers of the library to add tests that can compare known inputs/outputs deterministically.

v2.2.1

5 years ago

This release adds stricter checks (#210) for handling JWKs with elliptic keys. As per RFC 7518, Section 6.2.1.2 to 6.2.2.1 the length of this octet strings for X/Y/D values in JWKs MUST be the full size of a coordinate for the curve specified in the "crv" parameter. As a result, invalid JWKs that were previously accepted (e.g. a JWK where the padding was missing on X/Y coordinates) will now be rejected when parsing them.

v2.2.0

5 years ago

Bug Fixes

  • Check that key size when matches cipher for DIRECT encryption mode (issue #204, fix in #205)
  • Fix auth tag length for A192CBC-HS384, A256CBC-HS512 to match spec (issue #206, fix in #207)

Note: We bumped the minor version in this release because the changes in #207 fixes a compatibility issue with the implementations of the A192CBC-HS384 and A256CBC-HS512 ciphers. The library didn't correctly follow the JOSE specification (RFC 7518) when encrypting and as a result ciphertexts produced with square/go-jose were incompatible with other JOSE implementations. Ciphertexts produced from other libraries with those ciphers would still decrypt correctly. If you were encrypting with A192CBC-HS384 and A256CBC-HS512 using old versions of this library there might be compatibility concerns when upgrading.