The following error occurs when using `imagemagickBig`:
$ ./result/bin/identify sample.jp2
[1] 699089 IOT instruction (core dumped) ./result/bin/identify sample.jp2
When looking at the call-trace it seems as if certain symbols, e.g.
`opj_malloc` are mixed up:
#8 0x00007f78c79ad2f5 in MagickSignalHandler.cold () from /nix/store/bqy80qiw6czqh7vsmmmivwdswp9zzjgl-imagemagick-7.1.0-29/lib/libMagickCore-7.Q16HDRI.so.10
#9 <signal handler called>
#10 0x00007f78c5a6095f in opj_malloc () from /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9
#11 0x00007f78c5a60981 in opj_calloc () from /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9
#12 0x00007f78c4f48e24 in opj_create_decompress () from /nix/store/qwalb0kjz1p9c4j48qkk6ql47ds2lnhh-openjpeg-2.4.0/lib/libopenjp2.so.7
The `opj_create_decompress()` is called from the `openjpeg`-integration
of `imagemagick` and thus shouldn't affect `ghostscript` at all.
However, `ghostscript` (`libgs.so` to be precise) also exposes e.g.
`opj_malloc`:
$ objdump -t /nix/store/wg6ly83k1k1fjiygiv1jr7li3p6dwsvq-ghostscript-with-X-9.55.0/lib/libgs.so.9.55|grep opj_malloc
0000000000205940 g F .text 000000000000002b opj_malloc
Because of that, two incompatible symbols are used in the same process
and thus the `identify`-call breaks because the wrong one is used. To
work around that I decided to use the system-wide openjpeg instead.
I'm not sure why `libgs.so` wants to expose these symbols anyways, but
with that workaround the problem is solved.
Even though it's mentioned that ghostscript's openjpeg is heavily
patched, I think that this is somewhat outdated or at least irrelevant
considering that both ArchLinux[1] and Fedora[2] use the system-wide
`openjpeg` instead.
[1] bafcb5473b/trunk/PKGBUILD (L50)
[2] e4eec13ab6/f/ghostscript.spec (_245)
upon closer inspection, `make check` does little except rebuild
everything with some different options. ghostscript has a python-based
test suite, but it looks like an unmaintained disaster zone.
so the best we can probably do for now is ensure we can render all the
provided examples.
Dynamic library name on Darwin contains only 'maj.min' eg "9.53";
the build however used $version to set rpath;
this broke on 2029ca37 when $version went from "9.52" to "9.53.3".
Add a call to 'gs' in installCheckPhase,
to break the build if dylib issues arise in the future.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
This is tagged as version 9.26a in the ghostpdl repo, but unfortunately
there are no tarballs released with that version number so far. We'll
continue calling this version 9.26 for now for simplicity's sake (and we
can switch to 9.26a and remove the patch when it's properly released).
Fixes#58262Fixes#58089
GS ships with a fork of lcms2 ("lcms2mt"), but the ABI separation
between the fork and the original seems insufficient. If libgs is linked
alongside liblcms2 (for example, this is the case with imagemagick) then
it will call into the original library instead of the fork, causing
segfaults.
Follow the example of both Arch and Debian in this regard -- they both
use the systemwide lib instead of the fork.
I previously didn't update the hash, so was still building ghostscript-9.24
(which explained why docs were still from 9.24)
The ICC profile validation patch from #47937 is included in 9.25, so we
can strip it from the list of patches.
cc @xeji
Highlights in this release include:
This release fixes problems with argument handling, some unintended results of the security fixes to the SAFER file access restrictions (specifically accessing ICC profile files), and some additional security issues over the recent 9.24 release.
CVE-2018-16802
CVE-2018-17183
Note: The ps2epsi utility does not, and cannot call Ghostscript with the -dSAFER command line option. It should never be called with input from untrusted sources.
Security issues have been the primary focus of this release, including solving several (well publicised) real and potential exploits.
PLEASE NOTE: We strongly urge users to upgrade to this latest release to avoid these issues.
As well as Ghostscript itself, jbig2dec has had a significant amount of work improving its robustness in the face of out specification files.
IMPORTANT: We are in the process of forking LittleCMS. LCMS2 is not thread safe, and cannot be made thread safe without breaking the ABI. Our fork will be thread safe, and include performance enhancements (these changes have all be been offered and rejected upstream). We will maintain compatibility between Ghostscript and LCMS2 for a time, but not in perpetuity. Our fork will be available as its own package separately from Ghostscript (and MuPDF).
The usual round of bug fixes, compatibility changes, and incremental improvements.
