On Saturday 11 April 2009 08:28:30 pm Guy K. Kloss wrote: > On Sun, 05 Apr 2009 00:39:35 i...@littlecms.com wrote: > > >The whole internet is now filled with hype about this "vulnerability", > > >and in truth this "patch" breaks littlecms functionality, and probably > > >opens some back door, so, please: > > I've been at a conference last week and talked quite a bit there with > Robert O'Callahan (Mozilla NZ). And he's told me that they have now ditched > LCMS from Mozilla due to the fact of the (in-) security patch.
The patches did break LCMS which would have broken apps using it like mozilla. But isn't this type of thing an issue for all libraries and not just LCMS? The issue is not with LCMS per say but rather with distros not doing their job to confirm with upstream that patches are valid and also not testing patches before pushing them out to users. > They rather > went the approach of re-implementing the parts of colour management that > they depend on. This of course eliminates the possibility that a patch to or issue with ONE specific external library will cause Mozilla to break but what would stop some third party "security expert" from issuing a "security" alert/patch against Mozilla or another library it uses and causing it to break when some distros starts using the patch without first confirming that upstream is in the loop and that the patch actually works? Their "solution" doesn't really fix any of the underlaying issues it only treats one of the symptoms. I checked the packaging for LCMS on my distro and they have not used this patch set. But the security alert did cause a bunch of activity in their bug tracker so they were aware of the security alert (first bug tracker entry was on 2/25) and followed up on it quickly. In the end they by passed these patches and pushed 1.18 to users which is what Marti recommended. I see that RedHat and some others did the same thing so at least some distros handled this correctly. > > For them that has got some further benefits: > > * Leaner code base and less dependencies on 3rd party libraries. > > * Potential to implement additional acceleration for rendering (e. g. > using the GPU to perform transformations). > > Too bad, after all it's quite a prominent project that's dropped it's use > of LCMS. > > Guy ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
