v1.5.3

Full Changelog: v1.5.2...v1.5.3

v2.0.0 Preview 2

Merge pull request #53 from aidantwoods/v2-package-path

Add v2 in path for v2 alpha

v2.0.0 Preview

Alpha release of v2.0.0. Adds support for custom token types to be used, so that users of this library can manually manage (de)serialisation of token claims and footer.

What's Changed

• Add support for custom token types through generics by @aidantwoods in #39

Full Changelog: v1.5.2...v2.0.0-alpha

v1.5.2

What's Changed

• Bump golang.org/x/crypto from 0.11.0 to 0.17.0 by @dependabot in #50

Full Changelog: v1.5.1...v1.5.2

v1.5.1

What's Changed

• Use json.RawMessage to delay serialisation/deserialisation by @aidantwoods in #48

Full Changelog: v1.5.0...v1.5.1

v1.5.0

What's Changed

• Add constructors to allow constructing keys from standard Go objects by @aidantwoods in #43
• Update dependencies by @aidantwoods in #45

Full Changelog: v1.4.0...v1.5.0

v1.4.0

This is an fairly large internal change around how results + errors are being represented. There should be no change to any consumer facing behaviour from the public API perspective.

What's Changed

• doc: update README by @Claude-Zq in #26
• Result type by @aidantwoods in #19
• No longer force unwrap footer result by @aidantwoods in #41

New Contributors

• @Claude-Zq made their first contribution in #26

Full Changelog: v1.3.0...v1.3.1

v1.3.0

What's Changed

• Raise min permitted version of Go to 1.18 by @aidantwoods in #23
• Bump yaml dependency by @aidantwoods in #24

Full Changelog: v1.2.1...v1.3.0

v1.2.1

What's Changed

• Create SECURITY.md by @aidantwoods in #17
• Only run push trigger for main by @aidantwoods in #18
• Add pkg description by @aidantwoods in #20
• Update deps and notice about Go version support by @aidantwoods in #21

Full Changelog: v1.2.0...v1.2.1

v1.2.0

What's Changed

• Update ci.yml by @ilyabrin in #9
• Validate ed25519 private keys during import by @aidantwoods in #8
• Add sentinel error types by @aidantwoods in #12

New Contributors

• @ilyabrin made their first contribution in #9

Full Changelog: v1.1.3...v1.2.0

Sentinel Errors

Introduces two specialisations on errors that may be returned: TokenError and RuleError. Note that some errors will still be returned by the library that are in neither of these specialisations, and so you should still fallback to general error handling (not assume one of these will always be returned).

A TokenError will be returned if the token is outright invalid in some way, whether that be due to formatting, a cryptographic issue, or some other issue which renders the token invalid.

A RuleError will be returned if a token fails one of the specified rules, but is otherwise valid (including cryptographically).

Distinguishing between these two error types is not mandatory: it is perfectly safe to just handle a general error without inspecting it. Being able to inspect an error may be useful for some use cases, for example if a different handling action is desired depending on whether the token was invalid or whether a rule failure occurred. Note that if you do look for one of these errors, you should additionally include code to handle general errors as a fallback: you should expect new errors that do not fall into either of these two categories to be returned in the future.