RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format

Roger Riggs Roger.Riggs at oracle.com
Thu Jan 10 16:04:45 UTC 2019


Hi,

If we're going to break some apps that use non-conforming strings,
perhaps we should go fully strict and make sure they are all fixed at 
the same time.
(Unless we have some stats on the distribution of non-conforming apps 
that mitigates that).

Roger


On 01/10/2019 02:27 AM, Ivan Gerasimov wrote:
> Hi Joe!
>
> From what I see, the discussion was about possibility to only accept 
> input strings with precisely sized parts, i.e. that matches
> "\p{XDigit}{8}- \p{XDigit}{4}- \p{XDigit}{4}- \p{XDigit}{4}- 
> \p{XDigit}{12}".
>
> And I'm proposing to only reject input with too large individual 
> parts, i.e. accept any input that matches
> " \p{XDigit}{1,8}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- 
> \p{XDigit}{1,12}".
>
> Currently, if one part is too large, we already "clip" it, using only 
> lower bits, so behavior looks buggy.
>
> Instead, it seems better to report the issue throwing an exception.
>
> With kind regards,
> Ivan
>
> On 1/9/19 11:08 PM, Joe Darcy wrote:
>> Hi Ivan,
>>
>> How does this bug relate to the recent discussion of "JDK-8165199: 
>> UUID.fromString(str) compliance checking?":
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html 
>>
>>
>> Cheers,
>>
>> -Joe
>>
>> On 1/9/2019 3:23 PM, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> String representation of UUID should conform to RFC4122 
>>> <https://tools.ietf.org/html/rfc4122>, i.e. each its part has to be 
>>> of the fixed size.
>>>
>>> Unfortunately, the UUID.fromString() method does not keep up to this 
>>> requirement:
>>> - First, it permits the leading zeroes of any part to be omitted;
>>> - Second, it permits some of the UUID parts to be larger then 
>>> allowed.  In such a case, the value is effectively clipped with & 
>>> 0x..FFFF.
>>> While some existing application may depend on the former case -- 
>>> i.e. be able to parse UUID with stripped leading zeroes, the later 
>>> case is likely to be an error.
>>>
>>> In the past, the check on the input has already been strengthened 
>>> with JDK-8006627 <https://bugs.openjdk.java.net/browse/JDK-8006627>.
>>>
>>> I propose we go further and make UUID.fromString() to reject such 
>>> string representations that contain too large individual parts.
>>>
>>> If people agree on the proposal, I'll file CSR to fix the change of 
>>> behavior.
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216407
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8216407/00/webrev/
>>>
>>> Thanks in advance!
>>>
>>
>



More information about the core-libs-dev mailing list