[BUG] Validation of message with `com.google.protobuf.Timestamp` fails with `java.time.DateTimeException` if seconds/nanos exceed `Instant` bounds

[viliket]

Description

Validation of com.google.protobuf.Timestamp fails with java.time.DateTimeException when the timestamp's seconds or nanoseconds values exceed the bounds that can be represented by Java's Instant class. This occurs when attempting to validate protobuf messages containing timestamps with extreme values like Long.MAX_VALUE for seconds, which cannot be converted to a valid Instant object.

The underlying issue is in ProtoAdapter class:

https://github.com/bufbuild/protovalidate-java/blob/97b4e2d604e82087abce63f6ec522989a6ec5178/src/main/java/build/buf/protovalidate/ProtoAdapter.java#L93-L104

Similar issue seems to also affect com.google.protobuf.Duration if using extreme nanos values due to the ProtoAdapter implementation linked above.

Steps to Reproduce

1. Define a protobuf message with a google.protobuf.Timestamp field:

syntax = "proto3";
package acme.foo.v1;
import "buf/validate/validate.proto";

message Foo {
  google.protobuf.Timestamp bar = 1;
}

2. Create a protobuf message instance with timestamp seconds set to Long.MAX_VALUE:

Foo message = Foo.newBuilder()
    .setBar(Timestamp.newBuilder().setSeconds(Long.MAX_VALUE))
    .build();

3. Attempt to validate the message using protovalidate: ValidationResult result = validator.validate(message);
4. Observe the java.time.DateTimeException being thrown during validation

Expected Behavior

The validation should provide a clear validation error indicating the timestamp is out of bounds instead of throwing uncaught java.time.DateTimeException

Actual Behavior

A java.time.DateTimeException is thrown when the validator attempts to convert the protobuf timestamp to a Java Instant object, causing the entire validation process to fail with an unhandled exception rather than a proper validation error.

Screenshots/Logs

java.time.DateTimeException: Instant exceeds minimum or maximum instant
	at java.base/java.time.Instant.create(Instant.java:414)
	at java.base/java.time.Instant.ofEpochSecond(Instant.java:334)
	at build.buf.protovalidate.ProtoAdapter.scalarToCel(ProtoAdapter.java:98)
	at build.buf.protovalidate.ProtoAdapter.toCel(ProtoAdapter.java:65)
	at build.buf.protovalidate.ObjectValue.value(ObjectValue.java:65)
	at build.buf.protovalidate.ValueEvaluator.evaluate(ValueEvaluator.java:74)
	at build.buf.protovalidate.FieldEvaluator.evaluate(FieldEvaluator.java:121)
	at build.buf.protovalidate.MessageEvaluator.evaluate(MessageEvaluator.java:41)

Environment

• Protovalidate Version: v1.0.1

Possible Solution

The protovalidate ProtoAdapter class or some other part of logic before it should:

• Add bounds checking before attempting to convert protobuf timestamps to Java Instant objects or protobuf durations to Java Duration objects.
• Or catch DateTimeException (timestamp to Instant case) / ArithmeticException (duration case) during protobuf to Java instance conversion and convert it to a proper validation error

[viliket]

Tested also with google.protobuf.Duration. This throws ArithmeticException (TimestampRules is a Protobuf message that has within field that is a google.protobuf.Duration):

import build.buf.validate.TimestampRules;

...

TimestampRules message = TimestampRules.newBuilder()
	.setWithin(com.google.protobuf.Duration.newBuilder().setSeconds(Long.MAX_VALUE).setNanos(Integer.MAX_VALUE).build())
				.build();

validator.validate(message);

Stack trace:

java.lang.ArithmeticException: long overflow

	at java.base/java.lang.Math.addExact(Math.java:931)
	at java.base/java.time.Duration.ofSeconds(Duration.java:249)
	at build.buf.protovalidate.ProtoAdapter.scalarToCel(ProtoAdapter.java:102)
	at build.buf.protovalidate.ProtoAdapter.toCel(ProtoAdapter.java:65)
	at build.buf.protovalidate.ObjectValue.value(ObjectValue.java:65)
	at build.buf.protovalidate.ValueEvaluator.evaluate(ValueEvaluator.java:74)
	at build.buf.protovalidate.FieldEvaluator.evaluate(FieldEvaluator.java:121)
	at build.buf.protovalidate.MessageEvaluator.evaluate(MessageEvaluator.java:41)

[timostamm]

Thanks for the report, Vili.

I don't think it's sufficient to change protovalidate's ProtoAdapter. There will be other places in cel-java where the same conversion happens.

We enable the cel-java option evaluateCanonicalTypesToNativeValues - for example here. This change was made in https://github.com/bufbuild/protovalidate-java/pull/345.

It might be a solution to disable this option.

[timostamm]

It might be a solution to disable this option.

The next cel-java release will enable the option by default. It's deprecated and will be removed in the future. This doesn't look like a viable solution.