Please drop and block jhead

[Seth Arnold]

Hello, I find the code quality of the jhead package very troubling. Upstream seems uninterested in fixing grossly negligent code issues:

https://github.com/Matthias-Wandel/jhead/issues/74
https://github.com/Matthias-Wandel/jhead/issues/75

Often times security fixes are of dubious quality:

https://github.com/Matthias-Wandel/jhead/commit/ec67262b8e5a4b05d8ad6898a09f1dc3fc032062
https://github.com/Matthias-Wandel/jhead/commit/a8e4cc2454ec0d08dc823c8edc20e402f4c856fb#commitcomment-98193945

(FWIW I think the "EDITOR can be malicious" was a silly CVE that shouldn't have been assigned but the code quality here is still pretty low.)

Please consider dropping jhead from our devel release and blocking automatic import from Debian.

Thanks

[Mark Esler (eslerm)]

Digging through past issues and the developers comments, I'd like to echo Seth's sentiment.

https://github.com/Matthias-Wandel/jhead/issues/60

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Steve Langasek (vorlon)]

$ reverse-depends src:jhead
Reverse-Recommends
==================
* cthumb (for jhead)
* dvd-slideshow (for jhead)
* mapivi (for jhead)

Reverse-Depends
===============
* jigl (for jhead)
* zoph (for jhead)

Packages without architectures listed are reverse-dependencies in: amd64, arm64, armhf, i386, ppc64el, s390x
$ reverse-depends src:jhead -a source
No reverse dependencies found
$

The reverse-dependencies need to be addressed first before jhead can be removed. Should they also be removed, or ported to another implementation, or?

[Mark Esler (eslerm)]

jigl hasn't been updated since 2003 http://xome.net/projects/jigl/download.html

zoph is quite active https://gitlab.com/zoph-project/zoph
they use jhead to rotate images based on EXIF data

[George-Andrei Iosif (iosifache)]

Hello,

I research the current Jhead usage in the packages mentioned by @vorlon (only the versions present in Mantic):

- cthumb-4.2 (Reverse-Recommends)
    - General-purpose image analysis in cthumb:1238: jhead <image>
    - Date extraction in cthumb:1487: jhead $picname | grep "Date/Time"
    - Rotation in cthumb:1704

        my $cmd = "mogrify -rotate \"$destRotate\" -geometry \"${destWidth}x${destHeight}>\" -quality
        [..]
        my $new_cmd = "jhead -cmd '$cmd &i' $dest";

- dvd-slideshow-0.8.6.1 (Reverse-Recommends)
    - Taken time extraction in dir2slideshow:688: taken='jhead "$file" | grep 'Date/Time' | awk -F': ' '{print $2}''
    - Modified time extraction: modified='jhead "$file" | grep 'File date' | awk -F': ' '{print $2}'
- mapivi-1.2+svn356 (Reverse-Recommends)
    - Image autorotation in mapivi.pl:14444: $command = "jhead -autorot \"$dpic\" ";
    - Clearing the rotation flag in mapivi.pl:14453: $command = "jhead -norot \"$dpic\" ";
- jigl-2.0.1+20060126 (Reverse-Depends), in which all snippets above are followed by: jhead -cmd "jpegtran $cmdStr -outfile &o &i" $fileStr
    - Image flip using jpegtran, in rotate:92: set cmdStr = "-flip $argv[2]"
    - Image rotation using jpegtran, in rotate:120: set cmdStr = "-rotate $argv[2]"
    - Image transpose using jpegtran, in rotate:126: set cmdStr = "-transpose $argv[2]"
    - Image transverse using jpegtran, in rotate:132: set cmdStr = "-transverse"
- zoph-1.0.1 (Reverse-Depends)
    - Image rotation in base.inc.php: $cmd = "jhead -autorot " . escapeshellarg($file);

A replacement package/combination of packages needs to be capable of:

- General-purpose processing/manipulation of the Exif data (including taken/modified date, and Orientation);
- Image rotation; and
- jpegtran or mogrify invocation with a backup mechanism (i.e. no in-place modification, but over a temporary copy).

For Exif parsing, there already are packages like exiv2, exif, and exiftool. For the last two, jpegtran and mogrify could be called directly in the dependents' code, by only implementing the mentioned backup mechanism (if needed).

[Steve Langasek (vorlon)]

This bug is still marked incomplete because no one has proposed an answer to this question:

> Should they also be removed, or ported to another implementation, or?