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

[Ivan Gerasimov]

Gentle ping.

So, do you think it is an appropriate fix?
To emphasize:  It is proposed to start rejecting only obviously 
incorrect UUIDs, which may help the applications, as they would fail 
earlier on invalid input.

With kind regards,
Ivan


On 1/10/19 8:50 AM, Ivan Gerasimov wrote:
> 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