[
https://issues.apache.org/jira/browse/CASSANDRA-21621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-21621:
-------------------------------------------
Description:
{{SimpleDateSerializer.dateStringToDays}} rejects a date string outside the
range the {{date}} type can hold, but
{{SimpleDateSerializer.timeInMillisToDay}} applies no range test:
{code:java}
public static int timeInMillisToDay(long millis)
{
return (int) (Duration.ofMillis(millis).toDays() - Integer.MIN_VALUE);
}
{code}
A day count is a signed 32-bit value shifted by {{Integer.MIN_VALUE}}, so a
timestamp further from the epoch than 2^31 days wraps and yields a date that
bears no relation to the input. {{timeInMillisToDay(Long.MAX_VALUE)}} returns a
day count near the year 1970.
{{SimpleDateType.fromTimeInMillis}} reaches that method, and {{TimeFcts}}
exposes it through {{toDate(timestamp)}} and through the date arithmetic of
{{TemporalType.addDuration}} and {{TemporalType.substractFrom}}. A query can
therefore build a wrong date with no error. The severity is Low because a
timestamp that far from the epoch is rare, and the whole {{timestamp}} range
beyond 2^31 days lies more than five million years from now.
The patch moves both range tests into {{timeInMillisToDay}}, and lets
{{dateStringToDays}} reach them through a private overload that keeps the
source string in the message, so the message a date string produces does not
change.
{{MaskingFunctionTester}} used {{timeInMillisToDay(Long.MAX_VALUE)}} as its
maximum {{date}} value, which is the wrap itself, so it now names the maximum
date the type supports.
Patch:
[mck/CASSANDRA-21621/5.0|https://github.com/thelastpickle/cassandra/tree/mck/CASSANDRA-21621/5.0]
Provenance:
[1032ba3047|https://github.com/datastax/cassandra/commit/1032ba30474d16f4b7309be48c0ab69c3ec34e56]
by [~jakubzytka] and [~ulises.cervino]. That commit carries the same range
test; this patch keeps the existing message format and adapts the one upstream
test that relied on the wrap.
was:
{{SimpleDateSerializer.dateStringToDays}} rejects a date string outside the
range the {{date}} type can hold, but
{{SimpleDateSerializer.timeInMillisToDay}} applies no range test:
{code:java}
public static int timeInMillisToDay(long millis)
{
return (int) (Duration.ofMillis(millis).toDays() - Integer.MIN_VALUE);
}
{code}
A day count is a signed 32-bit value shifted by {{Integer.MIN_VALUE}}, so a
timestamp further from the epoch than 2^31 days wraps and yields a date that
bears no relation to the input. {{timeInMillisToDay(Long.MAX_VALUE)}} returns a
day count near the year 1970.
{{SimpleDateType.fromTimeInMillis}} reaches that method, and {{TimeFcts}}
exposes it through {{toDate(timestamp)}} and through the date arithmetic of
{{TemporalType.addDuration}} and {{TemporalType.substractFrom}}. A query can
therefore build a wrong date with no error. The severity is Low because a
timestamp that far from the epoch is rare, and the whole {{timestamp}} range
beyond 2^31 days lies more than five million years from now.
The patch moves both range tests into {{timeInMillisToDay}}, and lets
{{dateStringToDays}} reach them through a private overload that keeps the
source string in the message, so the message a date string produces does not
change.
{{MaskingFunctionTester}} used {{timeInMillisToDay(Long.MAX_VALUE)}} as its
maximum {{date}} value, which is the wrap itself, so it now names the maximum
date the type supports.
Patch:
[mck/upstream/date-millis-range/5.0|https://github.com/thelastpickle/cassandra/tree/mck/upstream/date-millis-range/5.0]
Provenance:
[1032ba3047|https://github.com/datastax/cassandra/commit/1032ba30474d16f4b7309be48c0ab69c3ec34e56]
by Jakub Zytka and Ulises Cervino Beresi. That commit carries the same range
test; this patch keeps the existing message format and adapts the one upstream
test that relied on the wrap.
> A date built from a timestamp is not range checked
> --------------------------------------------------
>
> Key: CASSANDRA-21621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21621
> Project: Apache Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
> Reporter: Michael Semb Wever
> Priority: Normal
> Fix For: 5.0.x, 6.0.x, 7.x
>
>
> {{SimpleDateSerializer.dateStringToDays}} rejects a date string outside the
> range the {{date}} type can hold, but
> {{SimpleDateSerializer.timeInMillisToDay}} applies no range test:
> {code:java}
> public static int timeInMillisToDay(long millis)
> {
> return (int) (Duration.ofMillis(millis).toDays() - Integer.MIN_VALUE);
> }
> {code}
> A day count is a signed 32-bit value shifted by {{Integer.MIN_VALUE}}, so a
> timestamp further from the epoch than 2^31 days wraps and yields a date that
> bears no relation to the input. {{timeInMillisToDay(Long.MAX_VALUE)}} returns
> a day count near the year 1970.
> {{SimpleDateType.fromTimeInMillis}} reaches that method, and {{TimeFcts}}
> exposes it through {{toDate(timestamp)}} and through the date arithmetic of
> {{TemporalType.addDuration}} and {{TemporalType.substractFrom}}. A query can
> therefore build a wrong date with no error. The severity is Low because a
> timestamp that far from the epoch is rare, and the whole {{timestamp}} range
> beyond 2^31 days lies more than five million years from now.
> The patch moves both range tests into {{timeInMillisToDay}}, and lets
> {{dateStringToDays}} reach them through a private overload that keeps the
> source string in the message, so the message a date string produces does not
> change.
> {{MaskingFunctionTester}} used {{timeInMillisToDay(Long.MAX_VALUE)}} as its
> maximum {{date}} value, which is the wrap itself, so it now names the maximum
> date the type supports.
> Patch:
> [mck/CASSANDRA-21621/5.0|https://github.com/thelastpickle/cassandra/tree/mck/CASSANDRA-21621/5.0]
> Provenance:
> [1032ba3047|https://github.com/datastax/cassandra/commit/1032ba30474d16f4b7309be48c0ab69c3ec34e56]
> by [~jakubzytka] and [~ulises.cervino]. That commit carries the same range
> test; this patch keeps the existing message format and adapts the one
> upstream test that relied on the wrap.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
