Summary: | kde-base/libkdcraw-4.10.3 includes invalid icc profiles, can't be written by libpng-1.6 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Francesco Riosa <vivo75> |
Component: | Current packages | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | krinpaus, vivo75 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://projects.kde.org/projects/kde/kdegraphics/libs/libkdcraw/repository/revisions/ca2274e40d065e12123f6d32db3c6fe153e621a2 | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=319267 | ||
Whiteboard: | fixed in 4.10.5, was: media-libs/libpng-1.6.x unable to use some libkdcraw-4.10.2 profiles | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 464760 | ||
Attachments: | debug area 50003 digikam-50003.log |
Description
Francesco Riosa
2013-04-22 12:40:11 UTC
We cannot do much about this... Please file a bug on bugs.kde.org and link to it here for tracking. Which digikam version is this? oops, this is from git, forgot to mention it before. BTW the problem is still present with libpng-1.6.2, will look soon at it and try a patch temporary workarond rename /usr/share/apps/libkdcraw/profiles/srgb-d65.icm the program will complain but save the png replacing /usr/share/apps/libkdcraw/profiles/srgb-d65.icm with /usr/share/apps/libkdcraw/profiles/srgb.icm work. Both files are from kde-base/libkdcraw-4.10.2 the size seem to be correctly reported (3rd and 4th byte in file) 0x1B0A == 6922 -rw-r--r-- 1 root root 6922 1 mar 08.01 /usr/share/apps/libkdcraw/profiles/srgb-d65.icm iccexamin (and opening the files with an hex editor) seem to confirm both profiles are ok, so not a bug for libkdcraw. the bug seem to be in libpng being overzealous, see the following function from png.c png_icc_check_length(png_const_structrp png_ptr, png_colorspacerp colorspace, png_const_charp name, png_uint_32 profile_length) { if (profile_length < 132) return png_icc_profile_error(png_ptr, colorspace, name, profile_length, "too short"); if (profile_length & 3) return png_icc_profile_error(png_ptr, colorspace, name, profile_length, "invalid length"); return 1; } I don't know where the test (profile_length & 3) come from but it's failing, the function is undocumented and the git repository of libpng seem to be a dump for tarballs so my debugging stop here waiting for instructions Opened libpng bug with information from here for completeness: Table 17 — Profile header fields of section 7.2 in http://www.color.org/specification/ICC1v43_2010-12.pdf describes the first 128 bytes of an icc file ICC profiles are required to have a length which is a multiple of 4, so the profile in question is broken. (See 7.1.2(c) in the spec and "NOTE 1" that follows it then read 7.2.2 - the length includes the pad bytes.) I believe there was (and maybe is) an app that was writing text strings at the end of the profile and, if the text string was not a multiple of 4 in length, it would produce a bad profile. Those profiles are easy to fix - just pad the string with \0 - but other bugs where the profile length is calculated wrong may result in serious errors. (libpng does go on to validate the length, but when the length is detectably broken at the start it simply rejects the profile.) This is a benign error on read and the profile will be ignored (along with any other colorspace information in the PNG) but on write it gets converted into an application error - we don't want to write PNGs with detectably broken profiles, something else may crash! The KDE upstream need to fix the profile, it should be easy. Back to team then... :] profiles not aligned to 4 byte (~2100 pkg installed, not complete): 154323 app-office/calligra (/usr/share/color/icc/krita/lcmsxyzi.icm) 827 app-office/calligra (/usr/share/color/icc/krita/scRGB.icm) 154326 app-office/calligra (/usr/share/color/icc/krita/lcmslabi.icm) 28202 media-libs/lcms (/usr/share/lcms/profiles/sRGBSpac.icm) 6922 kde-base/libkdcraw (/usr/share/apps/libkdcraw/profiles/srgb-d65.icm) another note all these profiles have been created by lcms 2.1.0 and 2.3.0 under some microsoft platform. lcms 2.4.0 is released and it would interesting to see if it also generate (or translate) profiles which are not aligned. Marti M. hope you can see this Hi, that's Marti, the author of lcms. I've taken a look on that and those bogus profiles comes from diverse origins. The "2.1" and "2.3" version stamp you see in the profile does *not* refer to littlecms library, but to the ICC spec they are supposed to follow. Current ICC spec is 4.3, so go figure how old those profiles are. I can identify lcmslab and lcmsxyz as being prototypes created by myself about 15 years ago, in the old days of lcms 1.1 I would just discard those profiles as they are actually useless. For the remaining ones, I searching in my profile collection I can find same file names but with size multiple of 4. I wonder if any spare bytes have been added by I don't know which magic process. Otherwise, the check is fine but probably too restrictive for untrusted environments and too permissive if you want to take security into account. The profile header contains the expected length, I would check that field and probably the MD5 id if you want to make sure the profile have not been stamped. Gentooers what about the following plan? 1) fix profiles from lcms:0, put them in $FILESDIR, or even better remove them at all at install phase. Most (but far from all) application use lcms:2 nowadays it should be lcms-1.19-r1 (current and stable is 1.19-r0) 2) app-office/calligra should be fixed upstream by next release but media-libs/libpng-1.6* could become stable before them. Profiles should be fixed right now, without waiting for upstream with a temporary solution. Sadly some profiles are big and don't fit well^W at all in $FILESDIR. This leaves us two option, first is to provide an additional package, second is to fix them on the fly: in case you decide to fix on the fly at install phase here there is a short snipper of bash code that can help: # pad an icc profile to 4bytes PROFILENAME="srgb-d65.icm" oldsize=$(stat --printf='%s' "${PROFILENAME}") newsize=$(( (oldsize +3 ) / 4 * 4 )) if [[ $oldsize != $newsize ]] ; then # first pad the file for i in $(seq $(( newsize - oldsize)) ) ; do echo -ne \\00 >> "${PROFILENAME}" done # then replace the size in the header (the first 4 bytes) hexnewsize=$(printf '%08X\n' ${newsize}) hexnewsize=$(echo ${hexnewsize} | sed -e 's:..:\\x\0:g') sed -e '1s:^....:'${hexnewsize}':' -i "${PROFILENAME}" fi be warned that sed MUST support the sintax 's/..../\x0D\x0A\x4D\x53\x48/' all gentoo provided should but please check 3) kde-base/libkdcraw same as calligra but without the size problem, the only profile affected is small Safer version, use dd instead of sed and replace original file only after all operations are done, an even safer version would die() on errors pad_icc() { local PROFILENAME="$1" local oldsize=$(stat --printf='%s' "${PROFILENAME}") local newsize=$(( (oldsize +3 ) / 4 * 4 )) local hexnewsize if [[ $oldsize != $newsize ]] ; then hexnewsize=$(printf '%08X\n' ${newsize}) hexnewsize=$(echo ${hexnewsize} | sed -e 's:..:\\x\0:g') # write the new size (4 byte file) echo -ne ${hexnewsize} > "${PROFILENAME}".new # now append the original profile w/o the first 4 byte dd if="${PROFILENAME}" ibs=4 skip=1 >> "${PROFILENAME}".new # then pad to the wanted size for i in $(seq $(( newsize - oldsize)) ) ; do echo -ne \\00 >> "${PROFILENAME}".new done # finally move to the original mv "${PROFILENAME}".new "${PROFILENAME}" fi } pad_icc profiles/srgb-d65.icm libkdcraw should be fixed in next version, calligra/krita has a bug open@ https://bugs.kde.org/show_bug.cgi?id=319579 Francesco, how about you push your libkdcraw commit into KDE/4.10 branch too? Then it would be fixed in 4.10.5 ... humm, no expert in backporting, but if the git cherry pick magic has been done right it would be commit "92a57e163222ef9ee072964eb5cad92d9567a24d" in KDE/4.10 (In reply to Francesco Riosa from comment #17) > humm, no expert in backporting, but if the git cherry pick magic has been > done right it would be commit "92a57e163222ef9ee072964eb5cad92d9567a24d" in > KDE/4.10 this is fixed now? can we close the bug? *libkdcraw-4.10.5 (02 Jul 2013) 02 Jul 2013; Johannes Huber <johu@gentoo.org> +libkdcraw-4.10.5.ebuild: Version bump KDE SC 4.10.5 libpng 1.6.3 going stable in 4 weeks (In reply to Samuli Suominen from comment #18) > (In reply to Francesco Riosa from comment #17) > > humm, no expert in backporting, but if the git cherry pick magic has been > > done right it would be commit "92a57e163222ef9ee072964eb5cad92d9567a24d" in > > KDE/4.10 > > this is fixed now? can we close the bug? > > *libkdcraw-4.10.5 (02 Jul 2013) > > 02 Jul 2013; Johannes Huber <johu@gentoo.org> +libkdcraw-4.10.5.ebuild: > Version bump KDE SC 4.10.5 > It should be fixed, yes. > libpng 1.6.3 going stable in 4 weeks It is very likely that 4.10.5 will be stabilised before then so there shouldn't be any problems. yes |