chore(deps): update module google.golang.org/protobuf to v1.33.0 [security] - autoclosed #2297
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}
|
Coverage from tests in coverage: 49.7% of statements across all listed packagescoverage: 63.2% of statements in consensus/istanbul coverage: 41.8% of statements in consensus/istanbul/announce coverage: 55.8% of statements in consensus/istanbul/backend coverage: 0.0% of statements in consensus/istanbul/backend/backendtest coverage: 24.3% of statements in consensus/istanbul/backend/internal/replica coverage: 61.6% of statements in consensus/istanbul/core coverage: 50.0% of statements in consensus/istanbul/db coverage: 0.0% of statements in consensus/istanbul/proxy coverage: 64.2% of statements in consensus/istanbul/uptime coverage: 51.8% of statements in consensus/istanbul/validator coverage: 79.2% of statements in consensus/istanbul/validator/random |
|
renovate
bot
force-pushed
the
renovate/go-google.golang.org/protobuf-vulnerability
branch
3 times, most recently
from
058b640
to
4bc65bd
Compare
renovate
bot
force-pushed
the
renovate/go-google.golang.org/protobuf-vulnerability
branch
3 times, most recently
from
8eef3cd
to
f8debe0
Compare
renovate
bot
force-pushed
the
renovate/go-google.golang.org/protobuf-vulnerability
branch
2 times, most recently
from
c36b69d
to
f438f54
Compare
renovate
bot
force-pushed
the
renovate/go-google.golang.org/protobuf-vulnerability
branch
3 times, most recently
from
4cc4340
to
289b8be
Compare
renovate
bot
force-pushed
the
renovate/go-google.golang.org/protobuf-vulnerability
branch
from
289b8be
to
7280e24
Compare
ℹ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
renovate
bot
force-pushed
the
renovate/go-google.golang.org/protobuf-vulnerability
branch
2 times, most recently
from
f1e1288
to
1a36e17
Compare
…urity] Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
renovate
bot
force-pushed
the
renovate/go-google.golang.org/protobuf-vulnerability
branch
from
1a36e17
to
c599405
Compare
renovate
bot
changed the title
renovate
bot
deleted the
renovate/go-google.golang.org/protobuf-vulnerability
branch
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:
v1.23.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.
Infinite loop in JSON unmarshaling in google.golang.org/protobuf
CVE-2024-24786 / GHSA-8r3f-844c-mc37 / GO-2024-2611
More information
Details
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.
Severity
Unknown
References
This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).
Golang protojson.Unmarshal function infinite loop when unmarshaling certain forms of invalid JSON
CVE-2024-24786 / GHSA-8r3f-844c-mc37 / GO-2024-2611
More information
Details
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.
Severity
Moderate
References
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
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 thegithub.com/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 thegithub.com/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:
v1.24.0Compare Source
Overview
This release moves the generation of well-known types into this module.
Notable changes
New features:
Minor changes:
Bug fixes:
Centralized host for all well-known types
This release moves the generation of well-known types (e.g.,
FieldMask) into this module. Previously, some of the well-known types were generated into thegoogle.golang.org/genprotomodule. This sets the stage for a future release of this module to provide first-class support for the well-known types.As a consequence of this migration, this module incurs a weak dependency on the
google.golang.org/genprotomodule. This dependency may be dropped in the distant future, but it will persist for some time to ensure that users of this module use a sufficiently new version ofgoogle.golang.org/genproto(if they happen to depend on it) so as to avoid duplicate registration problems with regard to the well-known types.Upcoming 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 is behind base branch, 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.