Skip to content
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.

Sign up for GitHub

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

Jump to bottom

chore: update go packages (major) #787

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore: update go packages (major) #787

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link

@renovate renovate bot commented Dec 16, 2024

Update Request | Renovate Bot

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
github.com/ProtonMail/gopenpgp/v2 v2.8.1 -> v3.1.0 age adoption passing confidence
github.com/golang-jwt/jwt/v4 v4.5.1 -> v5.2.1 age adoption passing confidence
github.com/grpc-ecosystem/go-grpc-middleware v1.4.0 -> v2.2.0 age adoption passing confidence
github.com/santhosh-tekuri/jsonschema/v5 v5.3.1 -> v6.0.1 age adoption passing confidence
github.com/unix4ever/yaml v0.0.0-20220527175918-f17b0f05cf2c -> v2.4.0 age adoption passing confidence

Release Notes

ProtonMail/gopenpgp (github.com/ProtonMail/gopenpgp/v2)

v3.1.0

Compare Source

What's Changed
Added
Changed

Full Changelog: ProtonMail/gopenpgp@v3.0.0...v3.1.0

v3.0.0

Compare Source

What's Changed
New simplified and unified API

GopenPGP v3 introduces a new unified API for high level OpenPGP operations. In comparison to GopenPGP v2, where similar functions were dispersed across different types and required varying implementations for the same operations, GopenPGP v3 consolidates these functions into a consistent interface. Now, operations such as Sign, Verify, Encrypt, Decrypt, and Key generation are each accessible through a unified, builder like API, simplifying integration and enhancing code readability across cryptographic workflows.

However, applications migrating from v2 to v3 will need to update their API calls, as the changes are not backward-compatible. This means that all previous API calls must be rewritten to align with the new, unified API structure. GopenPGP v3 supports the migration process by offering extensive documentation and practical examples. We recommend upgrading to v3 for the latest features and improvements, but we'll continue to support GopenPGP v2 for the time being. Our support includes ongoing bug fixes and minor feature updates to ensure stability and functionality for existing users.

For usage examples of the new API, see the README. For the full documentation, see https://pkg.go.dev/github.com/ProtonMail/gopenpgp/v3.

Profiles

GopenPGP v3 introduces the concept of profiles, enabling applications to configure OpenPGP algorithm selection based on their specific needs. For most applications, the provided preset profiles offer robust and secure defaults, eliminating the need for additional configuration.

RFC 9580 and Interoperability

GopenPGP v3 adds full support for the latest OpenPGP specification, RFC 9580. Compliance with the specification has also been significantly enhanced, as confirmed by the results in the OpenPGP interoperability test suite. These enhancements in GopenPGP v3 are possible by leveraging a new API in the go-crypto fork, which enables a range of improvements in functionality, compliance, and performance.

Go Mobile Support

GopenPGP v3 aims to be fully compatible with Gomobile to provide an API for mobile platforms. For this reason, the library defaults to a builder-like pattern, which is less commonly used in Go. All code that is only relevant for mobile platforms has been moved to the mobile module.

Extending Functionality

GopenPGP v3 introduces a streaming interface across all APIs, enabling memory efficient processing of large data.
Additionally, it extends the library's functionality with various improvements, such as:

  • Consider all signatures in a message during verification and allow inspection of each.
  • Support signing with multiple keys.
  • Support encrypting to an "anonymous recipient", where the recipient KeyID is represented as all zeros in the message.
  • Add support for the intended recipient feature as specified in RFC 9580.
  • Ensure consistent behaviour across all APIs.
  • Support generating v6 keys as specified in RFC 9580.

Full Changelog: ProtonMail/gopenpgp@v2.7.5...v3.0.0.

Changelog since v3.0.0-beta.0: ProtonMail/gopenpgp@v3.0.0-beta.0...v3.0.0.

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

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

grpc-ecosystem/go-grpc-middleware (github.com/grpc-ecosystem/go-grpc-middleware)

v2.2.0

Compare Source

What's Changed

New Contributors

Full Changelog: grpc-ecosystem/go-grpc-middleware@v2.1.0...v2.2.0

v2.1.0

Compare Source

What's Changed

New Contributors

Full Changelog: grpc-ecosystem/go-grpc-middleware@v2.0.1...v2.1.0

v2.0.1

Compare Source

What's Changed

New Contributors

Full Changelog: grpc-ecosystem/go-grpc-middleware@v2.0.0...v2.0.1

v2.0.0

Compare Source

This is the first stable release of the new v2 release branch 🎉

Many of the interceptors have been rewritten from scratch and the project has been upgraded to use the Go Protobuf v2 API.

See the project README for details and migration guide. Thanks to all contributors who made this possible! 💪🏽

What's Changed

Configuration

📅 Schedule: Branch creation - "* 0-3 * * 1" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, 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

This PR was generated by Mend Renovate. View the repository job log.

@renovate Renovate
Copy link
Author

renovate bot commented Dec 16, 2024

⚠️ Artifact update problem

Renovate failed to update artifacts 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:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: client/go.sum
Command failed: go get -d -t ./...
go: -d flag is deprecated. -d=true is a no-op
go: gopkg.in/[email protected] (replaced by github.com/unix4ever/yaml/[email protected]): parsing go.mod:
	module declares its path as: gopkg.in/yaml.v2
	        but was required as: gopkg.in/yaml.v3
File name: go.sum
Command failed: go get -d -t ./...
go: -d flag is deprecated. -d=true is a no-op
go: gopkg.in/[email protected] (replaced by github.com/unix4ever/yaml/[email protected]): parsing go.mod:
	module declares its path as: gopkg.in/yaml.v2
	        but was required as: gopkg.in/yaml.v3

@renovate renovate bot force-pushed the renovate/major-go-packages branch 6 times, most recently from b45cd01 to 9ee41e2 Compare December 20, 2024 13:27
@renovate
chore: update go packages
0cb55a4 
Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
@renovate renovate bot force-pushed the renovate/major-go-packages branch from 9ee41e2 to 0cb55a4 Compare December 20, 2024 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants