RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3]

Harshitha Onkar honkar at openjdk.org
Sat Jan 18 00:04:42 UTC 2025


On Tue, 14 Jan 2025 17:57:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>>The cooked approach doesn't work for ICC_Profile header data. In case header data is updated using the cooked approach we run into IAE- cannot write tag data for both invalid as well as valid header field values.
>> 
>> maybe If the cooked approach always throws an exception and the current approach via "cmsSet" just ignores all errors means we are doing something wrong? Can we ask lcms maintainers why the validation is not done for this methods?
>> 
>> for example for the next method is it assumed that the client code should check the content of Table 10, and reject all incorrect values?:
>> 
>> **void cmsSetColorSpace(cmsHPROFILE hProfile, cmsColorSpaceSignature sig);**
>> 
>> Sets the color space signature in profile header, using ICC convention.
>> Parameters:
>> hProfile: Handle to a profile object
>> sig: any cmsColorSpaceSignature from Table 10
>> Returns:
>> *None*
>> 
>> https://www.littlecms.com/LittleCMS2.16%20API.pdf
>
> probably the answer will be that not all profiles are used for transformation, and just to read some of its properties it is not necessary to reject unexpected data such as intent/etc.

@mrserb 
The location mentioned in LCMSTransform involves creating a new color space transform using 2 or more profiles and DOES NOT  involve creating or updating a profile. Moreover LCMSTrandorm throws CMMException for invalid rendering intents so this case won't be an issue.

> maybe If the cooked approach always throws an exception and the current approach via "cmsSet" just ignores all errors means we are doing something wrong? Can we ask lcms maintainers why the validation is not done for this methods?

We are choosing to add these validation checks to jdk irrespective for whether lcms validates or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1920884736


More information about the client-libs-dev mailing list