This repository has been archived by the owner on Nov 17, 2024. It is now read-only.
fix(deps): update module google.golang.org/protobuf to v1.33.0 [security] #209
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
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?s=60&v=4){kind=small}
ℹ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
|
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
v1.24.0->v1.33.0GitHub Vulnerability Alerts
CVE-2024-24786
The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set.
Release Notes
protocolbuffers/protobuf-go (google.golang.org/protobuf)
v1.33.0Compare Source
v1.32.0Compare Source
Full Changelog: protocolbuffers/protobuf-go@v1.31.0...v1.32.0
This release contains commit protocolbuffers/protobuf-go@bfcd647, which fixes a denial of service vulnerability by preventing a stack overflow through a default maximum recursion limit. See https://github.com/golang/protobuf/issues/1583 and https://github.com/golang/protobuf/issues/1584 for details.
v1.31.0Compare Source
Notable changes
New Features
Minor performance improvements
Bug fixes
v1.30.0Compare Source
Announcement
In the previous two releases, v1.29.0 and v1.29.1, we associated the tags with the wrong commits and thus the tags do not reference any commit in this repository. This tag, v1.30.0, refers to an existing commit again. Sorry for the inconvenience.
Notable changes
New Features
v1.29.1Compare Source
Notable changes
Bug fixes
v1.29.0Compare Source
Overview
This version introduces a new package
protodelimto marshal and unmarshal size-delimited messages.It also brings the implementation up to date with the latest protobuf features.
Notable changes
New Features
Alignment with protobuf
Documentation improvements:
Minor performance improvements
Breaking changes
v1.28.1Compare Source
This release contains protoc-gen-go binaries for arm64.
Notable changes since v1.28.0:
v1.28.0Compare Source
Overview
The release provides a new unmarshal option for limiting the recursion depth when unmarshalling nested messages to prevent stack overflows. (
UnmarshalOptions.RecursionLimit).Notable changes
New features:
Documentation improvements:
Updated supported versions:
UnmarshalOption RecursionLimit
The new
UnmarshalOptions.RecursionLimitlimits the maximum recursion depth when unmarshalling messages. The limit is applied for nested messages. When messages are nested deeper than the specified limit the unmarshalling will fail. If unspecified, a default limit of 10,000 is applied.In addition to the configurable limit for message nesting a non-configurable recursion limit for group nesting of 10,000 was introduced.
Upcoming breakage changes
The default recursion limit of 10,000 introduced in the release is subject to change. We want to align this limit with implementations for other languages in the long term. C++ and Java use a limit of 100 which is also the target for the Go implementation.
v1.27.1Compare Source
Notable changes since v1.27.0:
v1.27.0Compare Source
Overview
The release provides new functionality for iterating through a message using protobuf reflection. There are some minor changes to the code generator.
Notable changes
New features:
Bug fixes:
Generator changes
Reflectively ranging over a message
The new
reflect/protorangepackage supports recursively ranging through all populated fields of a message. There are many use cases for such a feature. See the examples for inspiration.Upcoming breakage changes
This release removes generation of the
ExtensionRangeArraymethod, as originally announced since the v1.20.0 release on March 2nd, 2020. Our analysis of the entire public module proxy found no static usages of this method. This method is pseudo-internal to the implementation and we expect removal of it to have no material impact. If something is broken by this change, please file an issue and we can consider re-generating this method in a patch release.There are no new upcoming breaking changes to announce in this release.
v1.26.0Compare Source
Overview
This release reduces dependencies on other modules, enforces strict behavior with generated Go packages and name conflicts, expands support for aberrant message types, and provides minor new features in protobuf reflection.
Notable changes
New features:
Behavior changes:
Bug fixes:
Performance optimizations:
Reduced dependencies
Go code generated by
protoc-gen-gono longer have a hard dependency on thegh.neting.cc/golang/protobufmodule. In previous releases, the generator would emit a reference to theProtoPackageIsVersion4constant to statically enforce that a sufficiently new version of the older module was being linked in. In the last year, most of the Go ecosystem has moved to Go modules, where we can rely on Go modules to enforce a minimum version constraint on the older protobuf module. While there continues to be a cyclic dependency between thegh.neting.cc/golang/protobufandgoogle.golang.org/protobufmodules, the cyclic dependency was briefly broken and re-added to clear out the infinitely growing list ofgo.sumentries.The module dependency on the
google.golang.org/genprotomodule has been removed. Any program that depends on bothgoogle.golang.org/protobufandgoogle.golang.org/genprotomust use at least versioncb27e3aafrom May 26th, 2020. There is a runtime check at program initialization that panics when too old of a version of thegenprotomodule is being linked into the binary.The well-known types provided by this module are built from v3.15.3 of the protobuf toolchain.
Require Go import path
As mentioned in the v1.20.0 release from March 2nd, 2020, the Go generator will require that the Go import path be specified for all
.protofiles being generated and their transitive dependencies. Since v1.20.0, every occurrence of a.protofile missing a Go import path has resulted in a warning being printed to standard error that this will eventually become a fatal error. The Go import path is normally specified by declaring ago_packageoption in the.protofile. Alternatively, this can be specified at compile-time with aMflag passed on the command line. See the developer documentation for more information on thego_packageoption andMflag.Fatal namespace conflicts
As mentioned in the v1.20.0 release from March 2nd, 2020, the Go protobuf runtime will fatally fail if it detects the registration of duplicate names. Since v1.20.0, every occurrence of a conflict has resulted in a warning being printed to standard error that this will eventually become a fatal error. See the developer documentation for more information about what a namespace conflict is and how to resolve it.
While it is preferable that the source of the conflict be fixed, the fatal error can be immediately worked around in one of two ways:
This will cause the runtime to use the conflict handling behavior from v1.25.0 and earlier, which is to simply warn about them.
Support for aberrant message types
This project's compatibility document specifies that we only guarantee runtime compatibility with messages generated by
protoc-gen-go. Use of this module's runtime with any other custom message type will have mixed results, ranging from panics, to unspecified behavior, to working correctly. The proper way for custom message types to perfectly work with this module is for the custom type to implement theprotoreflect.ProtoMessageinterface, which allows a given message implementation to self-describe how its contents should be introspected.Since some widely depended upon modules have custom message types not generated by
protoc-gen-go, we expand support in this module's runtime to be able to handle those aberrant message types. This change should reduce the probability that using one of those modules with this module results in a panic and instead have reasonably correct behavior.This support is not covered by this project's compatibility guarantee and may be modified or removed in a future version of this module without notice. Custom types must move to supporting protobuf reflection to ensure long-term compatibility.
Upcoming breakage changes
This release makes some potentially disruptive changes that have been announced since the v1.20.0 release on March 2nd, 2020. Not all breaking changes mentioned in the v1.20.0 have been made and may still take effect in a later version of this module.
There are no new upcoming breaking changes to announce in this release.
v1.25.0Compare Source
Overview
This release provides specialized support for well-known types.
Notable changes
New features:
Minor changes:
Bug fixes:
Specialized support for well-known types
This release provides specialized support for well-known types by directly generating methods and functions into the generated package for certain well-known types that improve the usability of such types. The additionally generated APIs are listed below.
Package
anypb: New, MarshalFrom, UnmarshalTo, UnmarshalNew, Any.MessageIs, Any.MessageName, Any.MarshalFrom, Any.UnmarshalTo, Any.UnmarshalNewPackage
timestamppb: Now, New, Timestamp.AsTime, Timestamp.IsValid, Timestamp.CheckValidPackage
durationpb: New, Duration.AsDuration, Duration.IsValid, Duration.CheckValidPackage
structpb: NewStruct, Struct.AsMap, Struct.MarshalJSON, Struct.UnmarshalJSON, NewList, ListValue.AsSlice, ListValue.MarshalJSON, ListValue.UnmarshalJSON, NewValue, NewNullValue, NewBoolValue, NewNumberValue, NewStringValue, NewStructValue, NewListValue, Value.AsInterface, Value.MarshalJSON, Value.UnmarshalJSONPackage
fieldmaskpbNew,, Union,, Intersect,, FieldMask.IsValid,, FieldMask.Append,, FieldMask.Normalize,Package
wrapperspbBool, Int32, Int64, UInt32, UInt64, Float, Double, String, BytesUpcoming breakage changes
There are no new upcoming breaking changes to announce in this release.
As a reminder, the following have already been announced and may take effect in the near future:
Configuration
📅 Schedule: Branch creation - "" (UTC), 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.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.