libtiff: 4.1.0 -> 4.2.0

[orivej]

Motivation for this change

Regular update. Changelog: http://www.simplesystems.org/libtiff/v4.2.0.html

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[mweinelt]

Can we enable libdeflate support?

Added support for optional building against libdeflate for faster Zip/Deflate compression/decompression.

We now have 2 kinds of builds with the Zip/Deflate codec:

zlib only
zlib + libdeflate

Speed improvements in the 35%-50% range can be expected when libdeflate is used. Compression level up to 12 is now supported (capped to 9 when zlib is used). Still requires zlib for situations where libdeflate cannot be used (that is for scanline access, since libdeflate has no streaming mode)

Pseudo-tag TIFFTAG_DEFLATE_SUBCODEC=DEFLATE_SUBCODEC_ZLIB/DEFLATE_SUBCODEC_LIBDEFLATE is added to control which subcodec (zlib or libdeflate) should be used (it defaults of course to libdeflate, when it is available). This is mostly aimed at being used on the writing side, to be able to reproduce output of previous libtiff versions at a binary level, in situations where this would be really needed. Or as a safety belt in case there would be unforeseen issues with using libdeflate. It can be used to know when libdeflate is available at runtime (DEFLATE_SUBCODEC_LIBDEFLATE will be the default value in that situation).

Of course, deflate codestreams produced by libdeflate can be read by zlib, and vice-versa.

[orivej]

Good idea! Done.

I have noticed that none of the propagatedBuildInputs need to be propagated (their headers are not included by installed libtiff headers, and libtiff does not install static libraries), but unpropagating them may reduce the set of libraries available to dependent projects and possible break their build, so I have not moved them to buildInputs in this PR.

[mweinelt]

Please undo this change. Having the inputs one on each line is better for diff and merges.

[orivej]

I undid this change because it reduces the diff in this PR, but having args on one line is not better for review since GitHub displays line edits well (highlighting the changed part), and has no meaningful impact on merges since conflicts are rare and are not likely caused just by the changed args. The formatting of the args affects readability, and for me (and I think in general) one arg per line makes it worse by drawing attention from the important parts of the definition to the trivial (and duplicated in its body).

[FRidh]

and has no meaningful impact on merges since conflicts are rare and are not likely caused just by the changed args.

Often merging the master and staging branches I have a different experience here. Its very annoying having to check the lists of arguments when there are many arguments. Here there aren't many, but solving merge conflicts when you have a whole block of arguments is not fun.

[mweinelt]

Fixes two security vulnerabilities in libtiff before 4.2.0. We therefore need to backport those fixes.

• CVE-2020-35523
  https://gitlab.com/libtiff/libtiff/-/merge_requests/160

  An integer overflow flaw was found in libtiff that exists in the tif_getimage.c file. This flaw allows an attacker to inject and execute arbitrary code when a user opens a crafted TIFF file. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

• CVE-2020-35524
  https://gitlab.com/libtiff/libtiff/-/merge_requests/159

  A heap-based buffer overflow flaw was found in libtiff in the handling of TIFF images in libtiff's TIFF2PDF tool. A specially crafted TIFF file can lead to arbitrary code execution. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

[mweinelt]

Fixes backported in #116280