-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: update go (major) #1346
Open
freiheit-kuberpult-upgrader
wants to merge
1
commit into
main
Choose a base branch
from
renovate/major-go
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
chore: update go (major) #1346
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
⚠ Artifact update problemRenovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is. ♻ Renovate will retry this branch, including artifacts, only when one of the following happens:
The artifact failure details are included below: File name: go.sum
|
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
3 times, most recently
from
March 12, 2024 01:04
7cc6b4a
to
cd0bcab
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
2 times, most recently
from
March 19, 2024 12:50
7cb1d28
to
84254a9
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
2 times, most recently
from
March 26, 2024 01:05
09f6e35
to
3197e84
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
2 times, most recently
from
April 17, 2024 12:51
665444c
to
7a353f2
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
4 times, most recently
from
April 26, 2024 12:50
b6828aa
to
382104e
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
3 times, most recently
from
May 21, 2024 12:51
69c7788
to
1cefafd
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
from
May 22, 2024 12:51
1cefafd
to
6308c94
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
from
July 23, 2024 12:53
6308c94
to
0057038
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
from
August 7, 2024 01:04
0057038
to
87d17ae
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
from
September 16, 2024 01:05
87d17ae
to
d5c6f14
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
2 times, most recently
from
November 8, 2024 12:56
d6fbefb
to
96b09a2
Compare
freiheit-kuberpult-upgrader
force-pushed
the
renovate/major-go
branch
from
November 9, 2024 01:06
96b09a2
to
cb7d570
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v2.1.0
->v3.3.5
v0.0.0-20230923063757-afb1ddc0824c
->v1.1.2
v4.5.0
->v5.2.1
v1.4.0
->v2.1.0
v0.26.11
->v11.0.0+incompatible
Release Notes
ProtonMail/go-crypto
v1.1.2
Compare Source
v1.1.1
Compare Source
v1.1.0
Compare Source
golang-jwt/jwt
v5.2.1
Compare Source
What's Changed
New Contributors
Full Changelog: golang-jwt/jwt@v5.2.0...v5.2.1
v5.2.0
Compare Source
What's Changed
NewValidator
by @oxisto in https://github.com/golang-jwt/jwt/pull/349New Contributors
Full Changelog: golang-jwt/jwt@v5.1.0...v5.2.0
v5.1.0
Compare Source
What's Changed
ErrInvalidType
instead ofjson.UnsupportedTypeError
by @oxisto in https://github.com/golang-jwt/jwt/pull/316New Contributors
Full Changelog: golang-jwt/jwt@v5.0.0...v5.1.0
v5.0.0
Compare Source
🚀 New Major Version
v5
🚀It's finally here, the release you have been waiting for! We don't take breaking changes lightly, but the changes outlined below were necessary to address some of the challenges of the previous API. A big thanks for @mfridman for all the reviews, all contributors for their commits and of course @dgrijalva for the original code. I hope we kept some of the spirit of your original
v4
branch alive in the approach we have taken here.~@oxisto, on behalf of @golang-jwt/maintainers
Version
v5
contains a major rework of core functionalities in thejwt-go
library. This includes support for several validation options as well as a re-design of theClaims
interface. Lastly, we reworked how errors work under the hood, which should provide a better overall developer experience.Starting from v5.0.0, the import path will be:
For most users, changing the import path should suffice. However, since we intentionally changed and cleaned some of the public API, existing programs might need to be updated. The following sections describe significant changes and corresponding updates for existing programs.
Parsing and Validation Options
Under the hood, a new
validator
struct takes care of validating the claims. A long awaited feature has been the option to fine-tune the validation of tokens. This is now possible with severalParserOption
functions that can be appended to mostParse
functions, such asParseWithClaims
. The most important options and changes are:WithLeeway
to support specifying the leeway that is allowed when validating time-based claims, such asexp
ornbf
.iat
claim. Usage of this claim is OPTIONAL according to the JWT RFC. The claim itself is also purely informational according to the RFC, so a strict validation failure is not recommended. If you want to check for sensible values in these claims, please use theWithIssuedAt
parser option.WithAudience
,WithSubject
andWithIssuer
to support checking for expectedaud
,sub
andiss
.WithStrictDecoding
andWithPaddingAllowed
options to allow previously global settings to enable base64 strict encoding and the parsing of base64 strings with padding. The latter is strictly speaking against the standard, but unfortunately some of the major identity providers issue some of these incorrect tokens. Both options are disabled by default.Changes to the
Claims
interfaceComplete Restructuring
Previously, the claims interface was satisfied with an implementation of a
Valid() error
function. This had several issues:Since all the validation functionality is now extracted into the validator, all
VerifyXXX
andValid
functions have been removed from theClaims
interface. Instead, the interface now represents a list of getters to retrieve values with a specific meaning. This allows us to completely decouple the validation logic with the underlying storage representation of the claim, which could be a struct, a map or even something stored in a database.Supported Claim Types and Removal of
StandardClaims
The two standard claim types supported by this library,
MapClaims
andRegisteredClaims
both implement the necessary functions of this interface. The oldStandardClaims
struct, which has already been deprecated inv4
is now removed.Users using custom claims, in most cases, will not experience any changes in the behavior as long as they embedded
RegisteredClaims
. If they created a new claim type from scratch, they now need to implemented the proper getter functions.Migrating Application Specific Logic of the old
Valid
Previously, users could override the
Valid
method in a custom claim, for example to extend the validation with application-specific claims. However, this was always very dangerous, since once could easily disable the standard validation and signature checking.In order to avoid that, while still supporting the use-case, a new
ClaimsValidator
interface has been introduced. This interface consists of theValidate() error
function. If the validator sees, that aClaims
struct implements this interface, the errors returned to theValidate
function will be appended to the regular standard validation. It is not possible to disable the standard validation anymore (even only by accident).Usage examples can be found in example_test.go, to build claims structs like the following.
Changes to the
Token
andParser
structThe previously global functions
DecodeSegment
andEncodeSegment
were moved to theParser
andToken
struct respectively. This will allow us in the future to configure the behavior of these two based on options supplied on the parser or the token (creation). This also removes two previously global variables and moves them to parser optionsWithStrictDecoding
andWithPaddingAllowed
.In order to do that, we had to adjust the way signing methods work. Previously they were given a base64 encoded signature in
Verify
and were expected to return a base64 encoded version of the signature inSign
, both as astring
. However, this made it necessary to haveDecodeSegment
andEncodeSegment
global and was a less than perfect design because we were repeating encoding/decoding steps for all signing methods. Now,Sign
andVerify
operate on a decoded signature as a[]byte
, which feels more natural for a cryptographic operation anyway. Lastly,Parse
andSignedString
take care of the final encoding/decoding part.In addition to that, we also changed the
Signature
field onToken
from astring
to[]byte
and this is also now populated with the decoded form. This is also more consistent, because the other parts of the JWT, mainlyHeader
andClaims
were already stored in decoded form inToken
. Only the signature was stored in base64 encoded form, which was redundant with the information in theRaw
field, which contains the complete token as base64.Most (if not all) of these changes should not impact the normal usage of this library. Only users directly accessing the
Signature
field as well as developers of custom signing methods should be affected.What's Changed
StandardClaims
in favor ofRegisteredClaims
by @oxisto in #235v5
Pre-Release by @oxisto in https://github.com/golang-jwt/jwt/pull/234DecodeSegement
toParser
by @oxisto in https://github.com/golang-jwt/jwt/pull/278Verify
&Sign
to detail why string is not an advisable input for key by @dillonstreator in https://github.com/golang-jwt/jwt/pull/249v5
release by @oxisto in https://github.com/golang-jwt/jwt/pull/291New Contributors
Full Changelog: golang-jwt/jwt@v4.5.0...v5.0.0
v4.5.1
Compare Source
Security
Unclear documentation of the error behavior in
ParseWithClaims
in <= 4.5.0 could lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned byParseWithClaims
return both error codes. If users only check for thejwt.ErrTokenExpired
usingerror.Is
, they will ignore the embeddedjwt.ErrTokenSignatureInvalid
and thus potentially accept invalid tokens.This issue was documented in GHSA-29wx-vh33-7x7r and fixed in this release.
Note:
v5
was not affected by this issue. So upgrading to this release version is also recommended.What's Changed
ParseWithClaims
fromv5
branch. This fixes GHSA-29wx-vh33-7x7r.Full Changelog: golang-jwt/jwt@v4.5.0...v4.5.1
kubernetes/client-go
v1.5.0
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Renovate Bot.