feature: Bump go-jose and require signing algorithms in auth #4349
Conversation
github-actions
bot
added
area/auth
dependencies
| - PS384 | ||
| - PS512 | ||
|
|
||
| Default `signingalgorithms`: |
There was a problem hiding this comment.
NOTE: these are the same as the available ones; I decided to keep them as is because god knows what token servers our users are doing; from what I've seen the end users don't understand them that well -- we should strive to make this as b/w compact as possible and iterate based on user feedback
There was a problem hiding this comment.
Isn't 3.0.0 a chance to break compat?
Is there a default list from go-jose that has been more vetted than ours?
There was a problem hiding this comment.
Is there a default list from go-jose that has been more vetted than ours?
Actually there isn't no, I did look for it indeed.
registry/auth/token/fuzz_test.go
Outdated
| _, _ = token.VerifySigningKey(verifyOps) | ||
| }) | ||
| } | ||
| //func FuzzToken1(f *testing.F) { |
There was a problem hiding this comment.
This has been commented out I'm not exactly sure what signing algorithm I should pass into NewToken. Maybe @AdamKorcz could help here
There was a problem hiding this comment.
Any ideas @AdamKorcz ?
There was a problem hiding this comment.
Does it matter? Can't we just pick a common one?
There was a problem hiding this comment.
Does it matter? Can't we just pick a common one?
That would be fine. Or have all in a slice and have the fuzzer decide which one. The f.Fuzz call could be f.Fuzz(func(t *testing.T, data []byte, algEnum uint) {, and the fuzzer could select the alg from the slice like this: alg := algSlice[algEnum%len(algSlice)]
There was a problem hiding this comment.
Actually decided to KISS it and went with a couple of randomly picked ones.
|
PTAL @squizzi @Jamstah @thaJeztah |
This bumps go-jose to the latest available version: v4.0.3. This slightly breaks the backwards compatibility with the existing registry deployments but brings more security with it. We now require the users to specify the list of token signing algorithms in the configuration. We do strive to maintain the b/w compat by providing a list of supported algorithms, though, this isn't something we recommend due to security issues, see: * go-jose/go-jose#64 * go-jose/go-jose#69 As part of this change we now return to the original flow of the token signature validation: 1. X2C (tls) headers 2. JWKS 3. KeyID Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
milosgajdos
force-pushed
the
bump-go-jose-x2c-check
branch
from
d57a82e
to
52d6821
Compare
|
Squash, waiting for CI to pass, merging after it does |
This bumps the
go-josedependency to the latest available version: v4.0.3.Unfortunately this slightly breaks the backwards compatibility with existing registry deployments but brings in more security with it.
We now require the users to specify the list of token signing algorithms in the registry config. We do strive to maintain the b/w compatibility by providing a list of default signing algorithms, though, this isn't something we recommend due to security issues, see:
As part of this change, we now return to the original flow of the token signature validation as the last updates seems to have caused some unexpected surprises to some users (#4299):
TODO