chore(deps): update module github.com/golang-jwt/jwt/v4 to v5#1475
chore(deps): update module github.com/golang-jwt/jwt/v4 to v5#1475red-hat-konflux[bot] wants to merge 1 commit into
Conversation
|
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
073b47a to
deb8473
Compare
bde8291 to
7e9efa4
Compare
8e4deb1 to
55055a7
Compare
55055a7 to
87e3791
Compare
87e3791 to
c2e734f
Compare
3283d00 to
a6ab83d
Compare
a6ab83d to
79ea319
Compare
a4c2da5 to
79ea319
Compare
ReviewFindingsCritical
Labels: Renovate bot dependency update PR should carry the dependencies label. Previous runReviewFindingsCritical
Previous run (2)ReviewFindingsCritical
Previous run (3)ReviewFindingsCritical
High
|
| github.com/go-task/slim-sprig/v3 v3.0.0 // indirect | ||
| github.com/go-viper/mapstructure/v2 v2.4.0 // indirect | ||
| github.com/golang-jwt/jwt/v4 v4.5.2 // indirect | ||
| github.com/golang-jwt/jwt/v5 v5.3.1 // indirect |
There was a problem hiding this comment.
[critical] api-contract
The PR changes the indirect dependency from github.com/golang-jwt/jwt/v4 to github.com/golang-jwt/jwt/v5, but the direct consumer github.com/bradleyfalzon/ghinstallation/v2 explicitly imports github.com/golang-jwt/jwt/v4. In Go, v4 and v5 are entirely different module paths. Replacing the v4 module entry with v5 does not satisfy the v4 import — the build will fail.
Suggested fix: Do not remove the jwt/v4 indirect dependency unless ghinstallation/v2 is upgraded to a version that imports jwt/v5. Check whether a newer ghinstallation/v2 exists that depends on jwt/v5; if so, upgrade both together. If not, revert this change.
| github.com/go-task/slim-sprig/v3 v3.0.0 // indirect | ||
| github.com/go-viper/mapstructure/v2 v2.4.0 // indirect | ||
| github.com/golang-jwt/jwt/v4 v4.5.2 // indirect | ||
| github.com/golang-jwt/jwt/v5 v5.3.1 // indirect |
There was a problem hiding this comment.
[high] pattern-violation
The PR modifies only go.mod but does not update go.sum, vendor/modules.txt, or the vendor directory. go.sum still contains checksums for jwt/v4 only. vendor/modules.txt still lists jwt/v4 v4.5.2. The vendored source is unchanged. The vendor directory is inconsistent with go.mod.
Suggested fix: After resolving the v4-vs-v5 consumer compatibility issue, run 'go mod tidy && go mod vendor' and commit the resulting changes to go.sum, vendor/modules.txt, and the vendor directory.
|
🤖 Finished Retro · ✅ Success · Started 12:00 PM UTC · Completed 12:08 PM UTC |
Retro: PR #1475 — Renovate jwt/v4→v5 dependency bump (autoclosed)What happened: Renovate bot opened a PR to bump Review quality: The review agent performed well, correctly identifying both the critical module path incompatibility and the missing vendor directory updates. Both findings were accurate and actionable. Waste identified:
All improvement opportunities are already covered by existing open issues:
No new proposals filed — all identified improvements have existing tracking issues. |
|
🤖 Finished Review · ✅ Success · Started 2:39 PM UTC · Completed 2:46 PM UTC |
| github.com/go-task/slim-sprig/v3 v3.0.0 // indirect | ||
| github.com/go-viper/mapstructure/v2 v2.4.0 // indirect | ||
| github.com/golang-jwt/jwt/v4 v4.5.2 // indirect | ||
| github.com/golang-jwt/jwt/v5 v5.3.1 // indirect |
There was a problem hiding this comment.
[critical] logic-error
The PR changes the go.mod entry from github.com/golang-jwt/jwt/v4 v4.5.2 to github.com/golang-jwt/jwt/v5 v5.3.1, but this is an incomplete and inconsistent change that will break the build. In Go modules, v4 and v5 are entirely different module paths. The vendored dependency github.com/bradleyfalzon/ghinstallation/v2 explicitly imports github.com/golang-jwt/jwt/v4 (in vendor/github.com/bradleyfalzon/ghinstallation/v2/sign.go and appsTransport.go). Since jwt/v4 is an indirect dependency pulled in by ghinstallation/v2, it cannot be replaced with jwt/v5 unless ghinstallation/v2 itself is upgraded to a version that depends on jwt/v5. Furthermore: (1) go.sum still only contains checksums for jwt/v4, not jwt/v5; (2) vendor/modules.txt still references jwt/v4; (3) the vendor/ directory contains jwt/v4 source files, not jwt/v5. The PR only modifies go.mod and none of the other files that must change in concert, so go mod verify, go mod vendor, and the build itself will all fail.
Suggested fix: Do not merge this PR as-is. The correct approach is either: (a) upgrade github.com/bradleyfalzon/ghinstallation/v2 to a version that itself depends on jwt/v5, then run go mod tidy && go mod vendor to update all generated files consistently; or (b) if no such version of ghinstallation/v2 exists, reject this major-version bump entirely since the transitive consumer still requires v4.
|
🤖 Finished Retro · ✅ Success · Started 2:45 PM UTC · Completed 2:52 PM UTC |
Retro: PR #1475 (golang-jwt v4→v5 dependency bump)This is the 3rd retro run on this PR. The previous retro (2026-06-20) already concluded that all identified improvements are tracked by existing issues. This retro confirms that assessment — no new proposals are warranted. Timeline
Waste observed
All improvements already tracked
No new proposals filed — all improvements are already tracked upstream. |
|
🤖 Finished Review · ✅ Success · Started 6:44 PM UTC · Completed 6:50 PM UTC |
| github.com/go-task/slim-sprig/v3 v3.0.0 // indirect | ||
| github.com/go-viper/mapstructure/v2 v2.4.0 // indirect | ||
| github.com/golang-jwt/jwt/v4 v4.5.2 // indirect | ||
| github.com/golang-jwt/jwt/v5 v5.3.1 // indirect |
There was a problem hiding this comment.
[critical] build breakage / module inconsistency
The PR replaces the go.mod requirement for github.com/golang-jwt/jwt/v4 v4.5.2 with github.com/golang-jwt/jwt/v5 v5.3.1. In Go modules, v4 and v5 are distinct module paths. The vendored dependency ghinstallation/v2 hard-codes imports of jwt/v4 (sign.go:6, appsTransport.go:12). Removing the v4 require breaks this transitive dependency. Additionally, go.sum contains only v4 checksums, vendor/modules.txt references only v4, and no vendor/github.com/golang-jwt/jwt/v5/ directory exists. The PR changes only go.mod with none of the required corresponding updates to go.sum or vendor/. This will fail go mod verify, go mod vendor, and the build.
Suggested fix: Do not merge as-is. Either: (a) upgrade ghinstallation/v2 to a version that depends on jwt/v5, then run go mod tidy && go mod vendor and include all resulting changes; or (b) keep jwt/v4 until upstream ghinstallation migrates. All of go.mod, go.sum, and vendor/ must be updated consistently.
Signed-off-by: red-hat-konflux <126015336+red-hat-konflux[bot]@users.noreply.github.com>
|
🤖 Finished Review · ✅ Success · Started 10:30 PM UTC · Completed 10:37 PM UTC |
| github.com/go-task/slim-sprig/v3 v3.0.0 // indirect | ||
| github.com/go-viper/mapstructure/v2 v2.4.0 // indirect | ||
| github.com/golang-jwt/jwt/v4 v4.5.2 // indirect | ||
| github.com/golang-jwt/jwt/v5 v5.3.1 // indirect |
There was a problem hiding this comment.
[critical] API contract violation
This PR changes go.mod to require github.com/golang-jwt/jwt/v5 but the only consumer of this dependency is the vendored github.com/bradleyfalzon/ghinstallation/v2 library, which explicitly imports github.com/golang-jwt/jwt/v4 (see vendor/github.com/bradleyfalzon/ghinstallation/v2/sign.go:6 and appsTransport.go:12). In Go modules, /v4 and /v5 are distinct module paths. Simply swapping the go.mod entry from v4 to v5 will not satisfy ghinstallation/v2 v4 import -- the build will fail because jwt/v4 is no longer declared as a dependency. Additionally, go.sum, vendor/modules.txt, and the vendored jwt/v4 source directory are not updated in this diff, meaning go mod tidy / go mod vendor was not run. This PR as-is will break compilation.
Suggested fix: The jwt/v4 to jwt/v5 migration cannot be done by changing go.mod alone. Either (1) upgrade ghinstallation/v2 to a version that depends on jwt/v5 and then run go mod tidy && go mod vendor, or (2) if no such version exists, keep jwt/v4 until the upstream library migrates. Do not manually swap the module path in go.mod without ensuring all transitive consumers are compatible.
This PR contains the following updates:
v4.5.2→v5.3.1Warning
Some dependencies could not be looked up. Check the warning logs for more information.
Release Notes
golang-jwt/jwt (github.com/golang-jwt/jwt/v4)
v5.3.1Compare Source
What's Changed
🔐 Features
WithNotBeforeRequiredparser option and add test coverage by @equalsgibson in #456NewWithClaims()by @equalsgibson in #459ParseUnverifiedby @slickwilli in #414👒 Dependencies
New Contributors
Full Changelog: golang-jwt/jwt@v5.3.0...v5.3.1
v5.3.0Compare Source
This release is almost identical to to
v5.2.3but now correctly indicates Go 1.21 as minimum requirement.What's Changed
Full Changelog: golang-jwt/jwt@v5.2.3...v5.3.0
v5.2.3Compare Source
What's Changed
New Contributors
Full Changelog: golang-jwt/jwt@v5.2.2...v5.2.3
v5.2.2Compare Source
What's Changed
jwt.Parseexample to usejwt.WithValidMethodsby @mattt in #425New Contributors
Full Changelog: golang-jwt/jwt@v5.2.1...v5.2.2
v5.2.1Compare Source
What's Changed
New Contributors
Full Changelog: golang-jwt/jwt@v5.2.0...v5.2.1
v5.2.0Compare Source
What's Changed
NewValidatorby @oxisto in #349New Contributors
Full Changelog: golang-jwt/jwt@v5.1.0...v5.2.0
v5.1.0Compare Source
What's Changed
ErrInvalidTypeinstead ofjson.UnsupportedTypeErrorby @oxisto in #316New Contributors
Full Changelog: golang-jwt/jwt@v5.0.0...v5.1.0
v5.0.0Compare 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
v4branch alive in the approach we have taken here.~@oxisto, on behalf of @golang-jwt/maintainers
Version
v5contains a major rework of core functionalities in thejwt-golibrary. This includes support for several validation options as well as a re-design of theClaimsinterface. 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
validatorstruct 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 severalParserOptionfunctions that can be appended to mostParsefunctions, such asParseWithClaims. The most important options and changes are:WithLeewayto support specifying the leeway that is allowed when validating time-based claims, such asexpornbf.iatclaim. 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 theWithIssuedAtparser option.WithAudience,WithSubjectandWithIssuerto support checking for expectedaud,subandiss.WithStrictDecodingandWithPaddingAllowedoptions 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
ClaimsinterfaceComplete Restructuring
Previously, the claims interface was satisfied with an implementation of a
Valid() errorfunction. This had several issues:Since all the validation functionality is now extracted into the validator, all
VerifyXXXandValidfunctions have been removed from theClaimsinterface. 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
StandardClaimsThe two standard claim types supported by this library,
MapClaimsandRegisteredClaimsboth implement the necessary functions of this interface. The oldStandardClaimsstruct, which has already been deprecated inv4is 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
ValidPreviously, users could override the
Validmethod 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
ClaimsValidatorinterface has been introduced. This interface consists of theValidate() errorfunction. If the validator sees, that aClaimsstruct implements this interface, the errors returned to theValidatefunction 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
TokenandParserstructThe previously global functions
DecodeSegmentandEncodeSegmentwere moved to theParserandTokenstruct 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 optionsWithStrictDecodingandWithPaddingAllowed.In order to do that, we had to adjust the way signing methods work. Previously they were given a base64 encoded signature in
Verifyand were expected to return a base64 encoded version of the signature inSign, both as astring. However, this made it necessary to haveDecodeSegmentandEncodeSegmentglobal and was a less than perfect design because we were repeating encoding/decoding steps for all signing methods. Now,SignandVerifyoperate on a decoded signature as a[]byte, which feels more natural for a cryptographic operation anyway. Lastly,ParseandSignedStringtake care of the final encoding/decoding part.In addition to that, we also changed the
Signaturefield onTokenfrom astringto[]byteand this is also now populated with the decoded form. This is also more consistent, because the other parts of the JWT, mainlyHeaderandClaimswere already stored in decoded form inToken. Only the signature was stored in base64 encoded form, which was redundant with the information in theRawfield, 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
Signaturefield as well as developers of custom signing methods should be affected.What's Changed
StandardClaimsin favor ofRegisteredClaimsby @oxisto in #235v5Pre-Release by @oxisto in #234DecodeSegementtoParserby @oxisto in #278Verify&Signto detail why string is not an advisable input for key by @dillonstreator in #249v5release by @oxisto in #291New Contributors
Full Changelog: golang-jwt/jwt@v4.5.0...v5.0.0
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
To execute skipped test pipelines write comment
/ok-to-test.Documentation
Find out how to configure dependency updates in MintMaker documentation or see all available configuration options in Renovate documentation.