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

[Ivan Gerasimov]

Hi Roger!


On 1/10/19 8:04 AM, Roger Riggs wrote:
> 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).
>
That's my point:  While going fully strict may break some applications 
out there, rejecting only obviously incorrect input will likely affect 
only those applications with a bug.

It can be thought as a first step toward full conformance to the RFC.
For now, reject only the most incorrect inputs, and leave the final 
step, if desired, to JDK-8165199 
<https://bugs.openjdk.java.net/browse/JDK-8165199>.

With kind regards,
Ivan

> 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!
>>>>
>>>
>>
>
>

-- 
With kind regards,
Ivan Gerasimov