* `protoc`: Included in zips alongside binary
* Java: Generated classes have been added to the Maven `util` artifact
* Ruby: Generated classes have been added to gems
* CMake: `.proto` files are included in installation
PiperOrigin-RevId: 957382561
In Java, it seems like the existing behavior is that we allow
single-element arrays to be parsed into a non-repeated field.
In `public final class JsonArray extends JsonElement implements Iterable<JsonElement>`:
```
@Override
public String getAsString() {
return getAsSingleElement().getAsString();
}
```
TBH I don't know if this behavior is necessarily _desired_, but here is
a unit test to validate this behavior so that we don't accidentally
break it without intending to.
PiperOrigin-RevId: 947320631
- Apply a fast path to Uint64 parse where we try to parse it directly before falling back to the BigDecimal path. This optimization is preexisting on int64 and int32 and uint32 but was missed on Uint64
- Avoid doing out.append(value.subSequence(start, end)) which forces an intermediate copy the string, instead use the out.append(value, start, end)
PiperOrigin-RevId: 937290790
Because JsonFormat uses GSON to parse JSON it has a variety of
leniencies, e.g. allowing keys and values to skip quotes:
```
{hello: world}
```
These behaviours are not part of the ProtoJSON format but they are
behaviours that JsonFormat's parser has. It's possible someone in the
wild depends upon these unknowingly. This adds explicit tests for these
behaviours to make sure that they are not accidentally lost in future.
Closes#27622
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/27622 from petedmarsh:json-format-lienent-tests edebd543cd
PiperOrigin-RevId: 933849754
This still retains the reflection path for these types so that it will continue to handle DynamicMessage printing correctly.
PiperOrigin-RevId: 928689274
- Use a lookup table for the replacement characters in the ascii range (which is all of the characters that gson escapes except for exactly 2).
- Stream the escapes out ourselves instead of going through gson.toJson(val.toString()) which goes through a lot of heavy gson machinery and makes several copies of the string.
We exactly match the choices that gson made for escapes here to make this an implementation detail change with no observable difference.
PiperOrigin-RevId: 928654085
This only changes the sort order in an obscure edge case of map-keys which sort differently in Utf8 and Utf16, meaning a mix of certain characters that are "very high code point but still single char" and "utf16 surrogate pairs".
PiperOrigin-RevId: 922768203
JsonFormat used 'reader.setLenient(false)' to try to get spec JSON behavior out of GSON. However, this mode was still not actually spec JSON. In ~2024 GSON deprecated setLenient(), made that behavior LEGACY_STRICT and added a new level STRICT which is intended to be spec.
Switching unilaterally would be a breaking change for Protobuf: this change just adds the option for users to ask us to use GSON in strict mode. At a later date we will consider flipping the default of this (letting people opt into LEGACY_STRICT if they want to).
PiperOrigin-RevId: 921432331
## Summary
`BigDecimal(String)` has O(N²) time complexity for N-digit strings on JDK versions before 18 ([JDK-8291514](https://bugs.openjdk.org/browse/JDK-8291514)). Five JSON parser methods — `parseInt32`, `parseInt64`, `parseUint32`, `parseUint64`, and `parseDouble` — pass user-controlled strings directly to `new BigDecimal()` without length validation.
A single JSON numeric value with 1,000,000 digits takes ~13 seconds to parse on JDK 17. This can be used to DoS any service that parses protobuf JSON messages with numeric fields from untrusted input.
### Benchmark (JDK 17, x86-64 Linux)
| Digits | BigDecimal construction time |
|--------|-----|
| 1,000 | 1.8 ms |
| 10,000 | 6.3 ms |
| 100,000 | 133 ms |
| 1,000,000 | **13.1 seconds** |
### Fix
Added a `parseBigDecimal()` helper that rejects strings longer than 1000 characters before constructing `BigDecimal`. This is generous — valid protobuf numeric values never exceed ~350 characters (Double.MAX_VALUE in non-scientific notation is ~309 digits).
### Affected JDK versions
- JDK 8, 11, 17 (all current LTS releases): **Vulnerable** — no built-in string length limit in BigDecimal
- JDK 18+: JDK itself limits BigDecimal string input to 1100 characters by default (JDK-8291514), but the protobuf-level check is still worthwhile as defense-in-depth
### Test
Added `testParserRejectOverlyLongNumericStrings` covering all 5 affected field types.
Closes#26908
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/26908 from MindflareX:fix/java-bigdecimal-length-check a461d0edc6
PiperOrigin-RevId: 904988136
This fixes as issue where extension names were incorrectly printed using their short name which prevents parsing and can lead to ambiguous or duplicate json keys.
This feature is gated by a boolean options printingFullyQualifiedExtensionNames and printingShortExtensionNames for testing. These methods are held back from the public API for now.
PiperOrigin-RevId: 875322649
This change adds base tests case for printing proto2 extensions. It highlights a known issue with parsing extensions as short names and duplicated field names.
PiperOrigin-RevId: 873022900
The pyi generator now includes Kythe annotations for:
* Extension field constants (e.g., `EXTENSION_FIELD`).
* Field number constants (e.g., `STRING_FIELD_FIELD_NUMBER`).
* `Create` methods in generated Stubby client classes.
These annotations allow the Python indexer to link these generated symbols back to their definitions in the `.proto` files.
PiperOrigin-RevId: 852971617
The annotations will be handled in a subsequent change.
The change to use java.lang.String.split() instead of Guava's Splitter does introduce behavior changes in the case of handling of degenerate/malformed FieldMask paths (paths like `a///`). The handling of malformed paths shape are already arbitrary and inconsistent between the different methods in this file, and callers should not construct such paths. In a future change we may consider validating and throwing an IllegalArgumentException on such malformed paths more explicitly.
https://github.com/protocolbuffers/protobuf/issues/21173
PiperOrigin-RevId: 795126095
Existing FieldMaskUtil#trim method behavior remains the same: unset primitive fields specified in the field mask will be explicitly set to their default values after trimming.
PiperOrigin-RevId: 754114689
Otherwise, protobuf_maven_dev may provide a different version from a transitive dep, which can result in the wrong version being selected (e.g. when used for bazel-generated maven artifacts).
Also updates protobuf_util_bundle to use protobuf_maven instead of protobuf_maven_dev which is probably more appropriate since its control the deps in the pom.xml file for maven users (though this is functionally the same rn).
Fixes https://github.com/protocolbuffers/protobuf/issues/20710
PiperOrigin-RevId: 738887165
