Skip to content

Update go dependencies (major) - #229

Merged
openshift-merge-bot[bot] merged 1 commit into
mainfrom
konflux/mintmaker/main/major-go-deps
Aug 18, 2026
Merged

Update go dependencies (major)#229
openshift-merge-bot[bot] merged 1 commit into
mainfrom
konflux/mintmaker/main/major-go-deps

Conversation

@red-hat-konflux-kflux-prd-rh02

@red-hat-konflux-kflux-prd-rh02 red-hat-konflux-kflux-prd-rh02 Bot commented Aug 17, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
github.com/cenkalti/backoff/v4 v4.3.0 → v7.0.0 age confidence
github.com/go-openapi/jsonreference v0.21.6 → v1.0.0 age confidence
github.com/golang-jwt/jwt/v4 v4.5.2 → v5.3.1 age confidence
github.com/matttproud/golang_protobuf_extensions v1.0.1 → v2.0.0 age confidence
go.yaml.in/yaml/v2 v2.4.4 → v3.0.5 age confidence
gopkg.in/evanphx/json-patch.v4 v4.13.0 → v5.9.11 age confidence

Release Notes

cenkalti/backoff (github.com/cenkalti/backoff/v4)

v7.0.0

Compare Source

v6.0.1

Compare Source

v6.0.0

Compare Source

v5.0.3

Compare Source

v5.0.2

Compare Source

v5.0.1

Compare Source

v5.0.0

Compare Source

go-openapi/jsonreference (github.com/go-openapi/jsonreference)

v1.0.0

Compare Source

1.0.0 - 2026-07-07

Stable API pledge - no change from v0.21.6

Full Changelog: go-openapi/jsonreference@v0.21.6...v1.0.0

10 commits in this release.

Documentation
Miscellaneous tasks
Updates
People who contributed to this release

jsonreference license terms

License

golang-jwt/jwt (github.com/golang-jwt/jwt/v4)

v5.3.1

Compare Source

What's Changed

🔐 Features
👒 Dependencies

New Contributors

Full Changelog: golang-jwt/jwt@v5.3.0...v5.3.1

v5.3.0

Compare Source

This release is almost identical to to v5.2.3 but 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.3

Compare Source

What's Changed

New Contributors

Full Changelog: golang-jwt/jwt@v5.2.2...v5.2.3

v5.2.2

Compare Source

What's Changed

New Contributors

Full Changelog: golang-jwt/jwt@v5.2.1...v5.2.2

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

New Contributors

Full Changelog: golang-jwt/jwt@v5.1.0...v5.2.0

v5.1.0

Compare Source

What's Changed

New 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 the jwt-go library. This includes support for several validation options as well as a re-design of the Claims 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:

"github.com/golang-jwt/jwt/v5"

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 several ParserOption functions that can be appended to most Parse functions, such as ParseWithClaims. The most important options and changes are:

  • Added WithLeeway to support specifying the leeway that is allowed when validating time-based claims, such as exp or nbf.
  • Changed default behavior to not check the 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 the WithIssuedAt parser option.
  • Added WithAudience, WithSubject and WithIssuer to support checking for expected aud, sub and iss.
  • Added WithStrictDecoding and WithPaddingAllowed 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 interface

Complete Restructuring

Previously, the claims interface was satisfied with an implementation of a Valid() error function. This had several issues:

  • The different claim types (struct claims, map claims, etc.) then contained similar (but not 100 % identical) code of how this validation was done. This lead to a lot of (almost) duplicate code and was hard to maintain
  • It was not really semantically close to what a "claim" (or a set of claims) really is; which is a list of defined key/value pairs with a certain semantic meaning.

Since all the validation functionality is now extracted into the validator, all VerifyXXX and Valid functions have been removed from the Claims 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.

type Claims interface {
	GetExpirationTime() (*NumericDate, error)
	GetIssuedAt() (*NumericDate, error)
	GetNotBefore() (*NumericDate, error)
	GetIssuer() (string, error)
	GetSubject() (string, error)
	GetAudience() (ClaimStrings, error)
}
Supported Claim Types and Removal of StandardClaims

The two standard claim types supported by this library, MapClaims and RegisteredClaims both implement the necessary functions of this interface. The old StandardClaims struct, which has already been deprecated in v4 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 the Validate() error function. If the validator sees, that a Claims struct implements this interface, the errors returned to the Validate 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.

// MyCustomClaims includes all registered claims, plus Foo.
type MyCustomClaims struct {
	Foo string `json:"foo"`
	jwt.RegisteredClaims
}

// Validate can be used to execute additional application-specific claims
// validation.
func (m MyCustomClaims) Validate() error {
	if m.Foo != "bar" {
		return errors.New("must be foobar")
	}

	return nil
}

Changes to the Token and Parser struct

The previously global functions DecodeSegment and EncodeSegment were moved to the Parser and Token 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 options WithStrictDecoding and WithPaddingAllowed.

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 in Sign, both as a string. However, this made it necessary to have DecodeSegment and EncodeSegment global and was a less than perfect design because we were repeating encoding/decoding steps for all signing methods. Now, Sign and Verify operate on a decoded signature as a []byte, which feels more natural for a cryptographic operation anyway. Lastly, Parse and SignedString take care of the final encoding/decoding part.

In addition to that, we also changed the Signature field on Token from a string to []byte and this is also now populated with the decoded form. This is also more consistent, because the other parts of the JWT, mainly Header and Claims were already stored in decoded form in Token. Only the signature was stored in base64 encoded form, which was redundant with the information in the Raw field, which contains the complete token as base64.

type Token struct {
	Raw       string                 // Raw contains the raw token
	Method    SigningMethod          // Method is the signing method used or to be used
	Header    map[string]interface{} // Header is the first segment of the token in decoded form
	Claims    Claims                 // Claims is the second segment of the token in decoded form
	Signature []byte                 // Signature is the third segment of the token in decoded form
	Valid     bool                   // Valid specifies if the token is valid
}

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

New Contributors

Full Changelog: golang-jwt/jwt@v4.5.0...v5.0.0

matttproud/golang_protobuf_extensions (github.com/matttproud/golang_protobuf_extensions)

v2.0.0

Compare Source

Summary: Modernization of this package to Go standards in 2022, mostly
through internal cleanups.

New Features: None

The last time this package was significantly modified was 2016, which predates
cmp, subtests, the modern Protocol Buffer implementation, and numerous Go
practices that emerged in the intervening years. The new release is tested
against Go 1.19, though I expect it would work with Go 1.13 just fine.

Finally, I declared bankruptcy on the vendored test fixtures and opted for
creating my own. This is due to the underlying implementation of the generated
code in conjunction with working with a moving target that is an external data
model representation.

Upgrade Notes: This is the aborted v1.0.3 release repackaged as a new
major version 2. To use this, you will need to do or check the following:

  1. The Protocol Buffer messages you provide to this API are from the
    google.golang.org/protobuf module. Take special care to audit any
    generated or checked-in Protocol Buffer message file assets. They may need
    to be regenerated.

  2. Your code should presumably use the google.golang.org/protobuf module for
    Protocol Buffers.

  3. This is a new major version of the module, so you will need to transition
    from module github.com/matttproud/golang_protobuf_extensions to
    github.com/matttproud/golang_protobuf_extensions/v2.

v1.0.4

Compare Source

Summary: This is an emergency re-tag of v1.0.2 since v1.0.3 broke API
compatibility for legacy users. See the description of v1.0.2 for details.

v1.0.3

Compare Source

DO NOT USE: Use v1.0.4 instead. What is described in v1.0.3 will be
transitioned to a new major version.

Summary: Modernization of this package to Go standards in 2022, mostly
through internal cleanups.

New Features: None

The last time this package was significantly modified was 2016, which predates
cmp, subtests, the modern Protocol Buffer implementation, and numerous Go
practices that emerged in the intervening years. The new release is tested
against Go 1.19, though I expect it would work with Go 1.13 just fine.

Finally, I declared bankruptcy on the vendored test fixtures and opted for
creating my own. This is due to the underlying implementation of the generated
code in conjunction with working with a moving target that is an external data
model representation.

v1.0.2

Compare Source

Summary: Tagged version with Go module support.

New Features: None

End-users wanted a tagged release that includes Go module support.

yaml/go-yaml (go.yaml.in/yaml/v2)

v3.0.5

Compare Source

v3.0.4

Compare Source

v3.0.3

Compare Source

v3.0.2

Compare Source

v3.0.1

Compare Source

v3.0.0

Compare Source

evanphx/json-patch (gopkg.in/evanphx/json-patch.v4)

v5.9.11

Compare Source

What's Changed

Full Changelog: evanphx/json-patch@v5.9.10...v5.9.11

v5.9.10

Compare Source

What's Changed

New Contributors

Full Changelog: evanphx/json-patch@v5.9.0...v5.9.10

v5.9.0

Compare Source

What's Changed

Full Changelog: evanphx/json-patch@v5.8.1...v5.9.0

v5.8.1: Fix API breakage

Compare Source

This PR fixes Operation containing a reference to internal/json and breaking the ability to manually compose one. This restores that ability using a type alias.

Full Changelog: evanphx/json-patch@v5.8.0...v5.8.1

v5.8.0: Blargh Phixs and Empathyprovements

Compare Source

This release fixes a few stray panics, addresses large number accuracy, and improves performance!

What's Changed

Full Changelog: evanphx/json-patch@v5.7.0...v5.8.0

v5.7.0: The 2023 Release

Compare Source

What's Changed

New Contributors

Full Changelog: evanphx/json-patch@v5.6.0...v5.7.0

v5.6.0: Bug fixes

Compare Source

What's Changed

New Contributors

Full Changelog: evanphx/json-patch@v5.5.0...v5.6.0

v5.5.0: Better null handling

Compare Source

This incorporates a few fixes related to how nulls are handles in array's and objects.

v5.3.0: Fix zero sized document crash

Compare Source

This fixes a crash bug where submitted an empty slice as the document would panic.

v5.2.0

Compare Source

v5.1.0

Compare Source

v5.0.0: Proper Go modules release

Compare Source

This release has a proper /v5 directory, unlike the previous releases that did not have a /v4 dir. Thanks to @​BenTheElder for getting this sorted out!

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "before 6am on Monday"
  • 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.

  • If you want to rebase/retry this PR, check this box

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.

@openshift-ci
openshift-ci Bot requested review from bmeng and tiwillia August 17, 2026 04:11
@openshift-ci

openshift-ci Bot commented Aug 17, 2026

Copy link
Copy Markdown

Hi @red-hat-konflux-kflux-prd-rh02[bot]. Thanks for your PR.

I'm waiting for a openshift-online member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@openshift-ci openshift-ci Bot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Aug 17, 2026
@bmeng

bmeng commented Aug 18, 2026

Copy link
Copy Markdown
Collaborator

/ok-to-test

@openshift-ci openshift-ci Bot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Aug 18, 2026
@red-hat-konflux-kflux-prd-rh02
Update go dependencies
57931eb 
Signed-off-by: red-hat-konflux-kflux-prd-rh02 <190377777+red-hat-konflux-kflux-prd-rh02[bot]@users.noreply.github.com>
@red-hat-konflux-kflux-prd-rh02
red-hat-konflux-kflux-prd-rh02 Bot force-pushed the konflux/mintmaker/main/major-go-deps branch from 17049cc to 57931eb Compare August 18, 2026 08:12
@bmeng

bmeng commented Aug 18, 2026

Copy link
Copy Markdown
Collaborator

/lgtm
/approve

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Aug 18, 2026
@openshift-ci

openshift-ci Bot commented Aug 18, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bmeng, red-hat-konflux-kflux-prd-rh02[bot]

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 18, 2026
@openshift-merge-bot
openshift-merge-bot Bot merged commit 4f4d737 into main Aug 18, 2026
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@bmeng bmeng Awaiting requested review from bmeng
@tiwillia tiwillia Awaiting requested review from tiwillia

Assignees

@bmeng bmeng

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@bmeng