R: kimageformats and JPEG XR

[Miranda, Mirco]

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), 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20260410/e4319686/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image438435.png
Type: image/png
Size: 25560 bytes
Desc: image438435.png
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20260410/e4319686/attachment-0001.png>