R: kimageformats and JPEG XR

Albert Astals Cid aacid at kde.org
Sat Apr 11 10:26:25 BST 2026


El divendres, 10 d’abril del 2026, a les 20:42:01 (Hora d’estiu d’Europa 
central), Miranda, Mirco va escriure:
> Albert Astals Cid <aacid at kde.org> wrote:
> >  A) Make it clear it is dangerous and rename the option to
> >  KIMAGEFORMATS_WITH_KNOWN_CRASHES_JXR to make it clear you should not
> >  enable it unless you know what you are doing
> I would say to do this in any case. Maybe it's also better to add a nice
> warning in the readme.md in the part related to JXR. As soon as I have a
> moment I'll do it.
> 
> In my libjxr fork, I fixed many issues found with OSS-Fuzz ​on
> KImageFormats. I tested every library change with the JXR conformance suite
> (https://www.itu.int/rec/T-REC-T.834-201001-S) only on images supported by
> our JXR plugin.
> 
> I currently have 7 open issues in OSS-Fuzz (not marked as a security issue
> by OSS-Fuzz): - One out of memory (not a problem) -> I could also add an
> API to limit the memory that can be used by the library. - Three memory
> leaks that only occur when images are corrupted (it would be nice to fix
> them). - One invalid enum (not a problem).
> - One abort: based on my experience with OSS-Fuzz, it's best to fix this.
> - One stack overflow: also needs fixing.
> 
> > B) Since there's no "hope" the upstream ever fixes the issues we should
> > just remove the code, what's the point of having code that will never be
> > "good"
> JXR and WDP are currently supported by Windows 11, I think it would be a
> shame not to have them.
> > C) Upstream is dead, BUT our own Mirco Miranda has a fork with lots of
> > security fixes so we should ask distributions to build from his fork...
> > D) Just copy the sources of Mirco's fork to kimageformats itself and use
> > those instead of an external lib.
> I don't know... C) is definitely the most generic (and perhaps most
> correct),

Done now

https://mail.kde.org/pipermail/distributions/2026-April/001677.html

Let's see if it's any successful and I hope it doesn't create much work on 
you.

Cheers,
  Albert

> but D) would allow us to focus only on our plugin.
> 
> If I really have to say it all... to do things properly with C) a project
> dedicated to libjxr on OSS-Fuzz that uses all the images of the JXR
> conformance suite should be created... I don't know if I have the strength
> to do it :)
> 
> 
> Mirco Miranda
> Software Engineering Supervisor
> Technical Dept
> phone+39 0536836422
> System Ceramics SpA
> Via Ghiarola Vecchia, 73    41042    Fiorano Modenese (MO)  Italy
> phone +39 0536 836111    email  info at systemceramics.com
> www.systemceramics.com
> Coesia companies
> ACMA – ATLANTIC ZEISER – CERULEAN – CIMA – CITUS KALIX – COMAS – EMMECI –
> FLEXLINK – G.D. – GDM – GF – HAPA – MGS – MOLINS – NORDEN – R.A. JONES –
> ROTZINGER TRANSVER – SASIB – SYSTEM CERAMICS – TRITRON - VOLPAK Disclaimer
> ​The information in this email and any attachments may contain proprietary
> and confidential information that is intended for the addressee(s) only. If
> you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, retention or use of the contents of this
> information is prohibited. When addressed to our clients or vendors, any
> information contained in this e-mail or any attachments is subject to the
> terms and conditions in any governing contract
> ________________________________
> Da: Albert Astals Cid <aacid at kde.org>
> Inviato: Venerdì, 10 Aprile, 2026 16:40
> A: kde-frameworks-devel at kde.org <kde-frameworks-devel at kde.org>
> Cc: Miranda, Mirco <mirco.miranda at systemceramics.com>
> Oggetto: kimageformats and JPEG XR
> 
> KIMAGEFORMATS_JXR is disabled by default. The CMakeLists. txt file says #
> JXR plugin disabled by default due to security issues
> option(KIMAGEFORMATS_JXR "Enable plugin for JPEG XR format" OFF) The
> problem is that upstream jxrlib aka Microsoft
> 
> 
> KIMAGEFORMATS_JXR is disabled by default.
> 
> The CMakeLists.txt file says
> 
> # JXR plugin disabled by default due to security issues
> option(KIMAGEFORMATS_JXR "Enable plugin for JPEG XR format" OFF)
> 
> The problem is that upstream jxrlib aka Microsoft is dead and there is no
> "hope" they will fix the issues.
> 
> Some distributions enable KIMAGEFORMATS_JXR.
> 
> I was thinking we could:
>  A) Make it clear it is dangerous and rename the option to
> KIMAGEFORMATS_WITH_KNOWN_CRASHES_JXR to make it clear you should not enable
> it unless you know what you are doing
>  B) Since there's no "hope" the upstream ever fixes the issues we should
> just remove the code, what's the point of having code that will never be
> "good" C) Upstream is dead, BUT our own Mirco Miranda has a fork with lots
> of security fixes so we should ask distributions to build from his fork at
> https://urldefense.com/v3/__https://github.com/mircomir/jxrlib__;!!Mxbk5DQ!
> qWYvPAXcnQlcBSnQul9cX1sF1zjy24Qo2oRCvSBaDaNGuiqSiIzZLbwcAZJACsyEAdeiFr8xWQWk
> _nADfoCj$ D) Just copy the sources of Mirco's fork to kimageformats itself
> and use those instead of an external lib.
> 
> I think that C) is ideal but maybe puts more pressure on Mirco that he would
> like about being "upstream" for jxrlib.
> 
> What do you all think?
> 
> Cheers,
>   Albert






More information about the Kde-frameworks-devel mailing list