Skip to content

Update module google.golang.org/protobuf to v1.33.0 [SECURITY] - #100

Merged
bootjp merged 1 commit into
mainfrom
renovate/go-google.golang.org/protobuf-vulnerability
Mar 16, 2024
Merged

Update module google.golang.org/protobuf to v1.33.0 [SECURITY]#100
bootjp merged 1 commit into
mainfrom
renovate/go-google.golang.org/protobuf-vulnerability

Conversation

@renovate

@renovaterenovateBot commented Mar 13, 2024

Copy link
Copy Markdown
Contributor

Mend Renovate

This PR contains the following updates:

PackageChangeAgeAdoptionPassingConfidence
google.golang.org/protobufv1.32.0 -> v1.33.0ageadoptionpassingconfidence

GitHub 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.0

Compare Source


Configuration

📅 Schedule: Branch creation - "" in timezone Asia/Tokyo, 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.


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

This PR has been generated by Mend Renovate. View repository job log here.

@renovaterenovateBot changed the title Update module google.golang.org/protobuf to v1.33.0 [SECURITY]Update module google.golang.org/protobuf to v1.33.0 [SECURITY] - autoclosedMar 16, 2024
@renovaterenovateBot closed this Mar 16, 2024
@renovate
renovateBot deleted the renovate/go-google.golang.org/protobuf-vulnerability branch March 16, 2024 10:23
@renovaterenovateBot changed the title Update module google.golang.org/protobuf to v1.33.0 [SECURITY] - autoclosedUpdate module google.golang.org/protobuf to v1.33.0 [SECURITY]Mar 16, 2024
@renovaterenovateBot reopened this Mar 16, 2024
@renovate
renovateBot restored the renovate/go-google.golang.org/protobuf-vulnerability branch March 16, 2024 10:31
@renovate
renovateBotforce-pushed the renovate/go-google.golang.org/protobuf-vulnerability branch from 69b3ceb to 62479f6CompareMarch 16, 2024 10:32
@renovate
renovateBotforce-pushed the renovate/go-google.golang.org/protobuf-vulnerability branch from 62479f6 to caac0b1CompareMarch 16, 2024 10:41
@bootjp
bootjp merged commit aff49da into mainMar 16, 2024
@bootjp
bootjp deleted the renovate/go-google.golang.org/protobuf-vulnerability branch March 16, 2024 11:06
bootjp added a commit that referenced this pull request Apr 30, 2026
Two P1 follow-ups from Codex.
#100 Codex P1 -- overbroad fast path.
The previous len(raw)*3 > 240 fast path tripped for any input
longer than 80 bytes, including pure-ASCII keys whose 1:1 encoded
form would have fit fine. That converted reversible keys into
ErrShaFallbackNeedsKeymap unnecessarily. Replaced with:
1. len(raw) > maxSegmentBytes -> SHA fallback (1:1 lower bound;
no encoding can fit).
2. percentEncodeBounded: stream-encodes with an in-loop overflow
check so the partial allocation is bounded to maxSegmentBytes
even on adversarial inputs that DO need escaping. Returns
("", false) on overflow so the caller takes the SHA path
without seeing the partial output.
TestEncodeSegment_LongUnreservedASCIIEncodesAsIs locks the
correct 200-byte-ASCII round-trip.
#146 Codex P1 -- b64. prefix collision.
A user STRING key like "b64.foo" was returned as-is by
EncodeSegment (all unreserved) and then misclassified by
DecodeSegment as a binary segment, decoding the base64 to "foo"
instead of round-tripping. EncodeSegment now promotes any input
whose percent-encoded form starts with the binary prefix to a
real SHA fallback, parallel to the existing SHA-shape collision
check, so KEYMAP.jsonl carries the original bytes.
TestEncodeSegment_KeyStartingWithBinaryPrefixIsPromotedToFallback
covers it.
The previous huge-input OOM-guard property (no all-at-once
3*len(raw) allocation) is preserved by percentEncodeBounded; the
existing TestEncodeSegment_HugeInputDoesNotMaterialiseFullExpansion
still passes.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@bootjp