Documentation
¶
Overview ¶
Package fositejose holds the go-jose v3 workarounds that fosite v0.49.0 needs. ToolHive uses go-jose v4, but fosite exposes go-jose v3 in its interfaces. The package has two parts.
The key conversions between go-jose v4 and v3 copy already-parsed keys field by field, so key material is never re-parsed by go-jose v3.
The JWS guard, IsUnsafeJWS, refuses JWS input before fosite parses it with go-jose v3, which has no patched release for two advisories: GHSA-mgcc-cww5-fp2q (an embedded key in the header) and GHSA-vvm8-gf78-28g4 (unbounded JSON nesting in the header or payload).
Remove this package once fosite moves to go-jose v4.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func FromFositeKeySet ¶
func FromFositeKeySet(jwks *josev3.JSONWebKeySet) *jose.JSONWebKeySet
FromFositeKeySet copies a key set read from a fosite client into the go-jose v4 type.
func IsUnsafeJWS ¶ added in v0.62.0
IsUnsafeJWS reports whether token must be refused before fosite parses it.
fosite v0.49.0 parses client assertions and OpenID Connect request objects with go-jose v3 before it verifies their signatures, so an unauthenticated caller reaches two go-jose v3 defects that have no patched v3 release:
- GHSA-mgcc-cww5-fp2q: go-jose v3 validates an RSA key embedded in a JWS header without bounding its size, which burns CPU before fosite looks up any client. A header with a "jwk" member is unsafe. fosite never uses an embedded key, since it resolves keys from the registered client, so refusing them does not affect conforming clients.
- GHSA-vvm8-gf78-28g4: go-jose v3 decodes JSON with its own decoder, which recurses once per nesting level with no limit. A deeply nested header or payload exhausts the goroutine stack, which is a fatal error rather than a panic, so it stops the process. The header and payload must both be JSON that encoding/json accepts, and encoding/json refuses nesting deeper than 10000 levels, far below the depth that overflows go-jose v3. A JWS header and JWT claims are JSON objects, so conforming tokens pass.
The check mirrors how go-jose v3's ParseSigned reads its input: whitespace is stripped, input starting with "{" is the JSON serialization (whose unprotected headers can also carry a key), the compact form must have exactly three segments, and each segment is base64url with optional padding. Anything that cannot be decoded is reported unsafe, so a parsing difference fails closed. fosite rejects such input anyway.
Remove this once fosite moves to go-jose v4.1.6 or later.
func ToFositeKey ¶
func ToFositeKey(key *jose.JSONWebKey) *josev3.JSONWebKey
ToFositeKey copies key into the go-jose v3 type fosite expects.
func ToFositeKeySet ¶
func ToFositeKeySet(jwks *jose.JSONWebKeySet) *josev3.JSONWebKeySet
ToFositeKeySet copies jwks into the go-jose v3 type fosite expects.
Types ¶
This section is empty.
Source Files