neuro-sig / NeuroFedora

#543 Unbundle TIFF library from IV
Closed: Invalid by gui1ty. Opened by gui1ty.

Closed: Invalid
Reopen Issue

As discussed in our last meeting, I made a gentle start with attempting to remove the bundled TIFF library from IV.

There's an issue for that upstream: https://github.com/neuronsimulator/iv/issues/3

My WIP is on GitHub: https://github.com/penguinpee/iv/tree/unbundle_tiff

I tried building against the local libtiff (4.4.0), but didn't get anywhere. I suspect the two versions are too divergent. Build bails out with:

In file included from /home/sandro/devel/iv/src/include/InterViews/enter-scope.h:28,
                 from /home/sandro/devel/iv/src/include/InterViews/resource.h:32,
                 from /home/sandro/devel/iv/src/include/InterViews/color.h:42,
                 from /home/sandro/devel/iv/src/lib/InterViews/tiff.cpp:30:
/home/sandro/devel/iv/src/include/InterViews/iv.h:29:23: error: ‘ivTIFFRaster’ has not been declared
   29 | #define _lib_iv(name) iv##name
      |                       ^~
/home/sandro/devel/iv/src/include/InterViews/_defines.h:290:20: note: in expansion of macro ‘_lib_iv’
  290 | #define TIFFRaster _lib_iv(TIFFRaster)
      |                    ^~~~~~~
/home/sandro/devel/iv/src/lib/InterViews/tiff.cpp:154:9: note: in expansion of macro ‘TIFFRaster’
  154 | Raster* TIFFRaster::load(const char* filename, bool) {
      |         ^~~~~~~~~~
/home/sandro/devel/iv/src/lib/InterViews/tiff.cpp: In function ‘ivRaster* load(const char*, bool)’:
/home/sandro/devel/iv/src/lib/InterViews/tiff.cpp:155:20: error: ‘TIFFRasterImpl::TIFFRasterImpl()’ is private within this context
  155 |     TIFFRasterImpl impl;
      |                    ^~~~
/home/sandro/devel/iv/src/lib/InterViews/tiff.cpp:151:1: note: declared private here
  151 | TIFFRasterImpl::TIFFRasterImpl() {}
      | ^~~~~~~~~~~~~~
/home/sandro/devel/iv/src/lib/InterViews/tiff.cpp:155:20: error: ‘TIFFRasterImpl::~TIFFRasterImpl()’ is private within this context
  155 |     TIFFRasterImpl impl;
      |                    ^~~~
/home/sandro/devel/iv/src/lib/InterViews/tiff.cpp:152:1: note: declared private here
  152 | TIFFRasterImpl::~TIFFRasterImpl() {}
      | ^~~~~~~~~~~~~~
/home/sandro/devel/iv/src/lib/InterViews/tiff.cpp:156:21: error: ‘ivRaster* TIFFRasterImpl::load(const char*)’ is private within this context
  156 |     return impl.load(filename);
      |            ~~~~~~~~~^~~~~~~~~~
/home/sandro/devel/iv/src/lib/InterViews/tiff.cpp:82:13: note: declared private here
   82 |     Raster* load(const char* filename);
      |             ^~~~
gmake[2]: *** [src/lib/CMakeFiles/interviews.dir/build.make:1718: src/lib/CMakeFiles/interviews.dir/InterViews/tiff.cpp.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: Leaving directory '/home/sandro/devel/iv/build'
gmake[1]: *** [CMakeFiles/Makefile2:150: src/lib/CMakeFiles/interviews.dir/all] Error 2
gmake[1]: Leaving directory '/home/sandro/devel/iv/build'
gmake: *** [Makefile:136: all] Error 2

I also took a look at the CVE and the fix upstream applied. It looks like the CVE doesn't apply to libtiff < 4.x. This is further supported by the CVE's description:

A stack overflow was discovered in the _TIFFVGetField function of Tiffsplit v4.4.0. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted TIFF file parsed by the "tiffsplit" or "tiffcrop" utilities.

Also none of the rhel releases appear to be affected including the compat-libtiff3 libraries.

Seeing the amount of effort it would take porting iv to libtiff 4.x, I would suggest leaving the package as is and closing the bug with a comment that iv is not affected by CVE-2022-34526.

Metadata Update from @gui1ty:
- Issue tagged with: S: Next meeting

Yeh, i worried this was quite a difficult task, which is why I never undertook it.

Given the limited usage of NEURON as a very very specific tool, and that it's a scientific tool that doesn't really involve/use any personal user data, nor connect to the internet etc., I'd think even if the CVEs did apply, it isn't too much to worry about.

I don't think I ever mailed the -devel list about a libtiff replacement btw. I did do a quick web search back then and didn't find anything that would be any less work to migrate to than updating libtiff IIRC.

So +1 to closing.

(PS: it's possible no CVEs apply to libtiff because the ancient version used by NEURON hasn't been checked for them).

(PS: it's possible no CVEs apply to libtiff because the ancient version used by NEURON hasn't been checked for them).

I had a quick look at the code, the upstream fix has been applied to. The function _TIFFCheckFieldIsValidForCodec is not present in tif_dirinfo.c. The file in iv is much shorter (~300 lines) than upstream's version (~1,350 lines).

I'm pretty confident the CVE doesn't apply to that ancient version. Shall I go ahead and close the associated bug(s) as well?

Metadata Update from @gui1ty:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

Yes, I think if the CVEs don't apply, they can be closed.

This ticket has been migrated to the forgejo instance. Please find the new ticket here
https://forge.fedoraproject.org/neuro/NeuroFedora//issues/543
Metadata

S: WIP T: Software

None
None
Low
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.