Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#64655 - [security] [jasper] consider dropping - unmaintained

Attached to Project: Arch Linux
Opened by Gunnar Bretthauer (Taijian) - Tuesday, 26 November 2019, 14:10 GMT
Last edited by freswa (frederik) - Sunday, 26 July 2020, 14:35 GMT
Task Type Feature Request
Category Security
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No



According to this upsteam issue ( jasper is no longer being actively maintained and open issues and security vulnerabilities are no longer being addressed. I would therefore ask Arch maintainers to remove jasper dependencies whereever possible, in order to reduce the possible attack surface of users' systems (many projects that currently depend on jasper can have this dependency disabled at compile time). Because jasper provides what is in many respects a niche feature, this would not remove core funtionality in almost all cases. Users depending on this feature could then still recompile with the respective switch flicked on.

One widely pulled in package affected by this is gdk-pixbuf2. Maintainers there are aware of this issue with jasper, but point out that jasper support is default disabled ( Maybe Arch could follow the default setting in such cases in the interest of security.

There seems to be an emerging consensus among distros that this is the smart way to approach jasper - according to the aforementioned issue, so far Debian, Ubuntu, and Gentoo have already dropped jasper from their repos because of security concerns, and OpenSUSE is in the process of doing so.
This task depends upon

Closed by  freswa (frederik)
Sunday, 26 July 2020, 14:35 GMT
Reason for closing:  Fixed
Additional comments about closing:  2.0.17
Comment by freswa (frederik) - Thursday, 20 February 2020, 12:54 GMT
Do we want to remove jasper? If yes, we should probably create a todo with these packages:
Comment by Gunnar Bretthauer (Taijian) - Thursday, 20 February 2020, 13:04 GMT
Well, here are some comments:

* gimp:
does not actually depend on jasper anymore since 2018-08-13 as commit replaced jasper with openjpeg. The Arch package just missed that change somehow...

* libraw:

* qt5-imageformats:

* jasper-doc:
probably no longer needed when jasper gets dropped?
Comment by Gunnar Bretthauer (Taijian) - Thursday, 20 February 2020, 13:33 GMT
Additional comment regarding opencv:

- jasper support can be disabled at compile time with -DWITH_JASPER=OFF
- upstream has already disable jasper at runtime by default; re-enabling it requires setting a special enviroment variable:
- threre is apparently an imcomplete PR to replace jasper with openjpeg:

So it can probably just be removed?
Comment by freswa (frederik) - Thursday, 20 February 2020, 14:27 GMT
Open PRs:

Comment by Gunnar Bretthauer (Taijian) - Tuesday, 25 February 2020, 16:15 GMT
Another update:

community/libicns should be able to just switch to openjpeg as the code treats them as interchangeable at compile time according to
Comment by Gunnar Bretthauer (Taijian) - Tuesday, 25 February 2020, 19:05 GMT
Another update:

community/openimageio has not depended on jasper since commit in 2011! They switched to openjpeg at that point. See also here:
Comment by Gunnar Bretthauer (Taijian) - Monday, 02 March 2020, 20:25 GMT
Aaand openimageio has dropped jasper as a dependency. So, one down...
Comment by Andreas Radke (AndyRTR) - Friday, 24 April 2020, 10:12 GMT
I've pushed gimp 2.10.18-6 using openjpeg2 to testing.
Comment by Gunnar Bretthauer (Taijian) - Friday, 08 May 2020, 23:13 GMT
Update: extra/opencv has merged a patch for version 4.3.0 [1] that enables openjpeg2 support for jpeg200 type images and actually prefers this new codepath over jasper. Unfortunately, extra/opencv has not picked up on this change. Is there any way to get the maintainers to switch out the known, broken implementation (jasper) for the new, actively maintained one preferred by upstream (openjpeg2)?

Comment by Gunnar Bretthauer (Taijian) - Friday, 08 May 2020, 23:42 GMT
extra/gegl can be build without jasper by the magic of meson autoconfigure.
Jasper is fully optinal at build time - either it is present and will then be compiled in, or it's not, in which case it will be skipped. See:
Comment by Gunnar Bretthauer (Taijian) - Monday, 11 May 2020, 17:37 GMT
To summarize after the last set of changes:

Packages that can switch to openjpeg2 but haven't done so yet:
- community/libicns (change would be picked up automatically at compile-time)

Packages that can drop jasper without any further config changes needed (compile-time detection automagick):
- extra/gegl
- extra/graphicsmagick
- extra/qt5-imageformats
- community/devil
- community/openscenegraph

Packages that need extra PKGBUILD changes to drop jasper:
- extra/dcraw (replace '-ljasper' with '-DNO_JASPER' in gcc options)
- extra/libraw (add '--enable-jasper=no' to compile options)
- community/ziproxy (replace '--with-jasper' with '--with-jasper=no' in ./configure options)

Packages that could be dropped afterwards:
- extra/jasper
- extra/jasper-doc
Comment by Gunnar Bretthauer (Taijian) - Wednesday, 01 July 2020, 20:03 GMT
Another new development:

There is now a new fork of jasper at [1] by a group of people who aim to fix the existing CVEs and do some general maintenance. There is no release yet, because they are apparently trying to work with the old maintainer of jasper to integrate their fixes into the original codebase, but if that does not work out, they might make their own release [2].

If this new release should materialize, maybe the Arch version of jasper should switch to the updated source?