[MIR] libheif

Bug #1827442 reported by Steve Langasek on 2019-05-02
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libde265 (Ubuntu)
libheif (Ubuntu)
Ubuntu Security Team
x265 (Ubuntu)

Bug Description

Available on all architectures in universe from bionic forward.

This is a new build-dependency added to imagemagick in Debian unstable. It implements support for decoding ISO/IEC 23008-12:2017 HEIF files, which are not otherwise supported by any libraries in Ubuntu main.

One vulnerability was reported this year against libheif 1.4.0 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11471). Debian currently has libheif 1.3.2. According to the upstream issue at https://github.com/strukturag/libheif/issues/123 the vulnerability was first introduced in an unreleased, git-only version of libheif (post-1.4.0), and found and fixed by the upstream community prior to finding its way into a tagged release. It is not clear to me that the vulnerability in question applies to 1.3.2.

This is a media file parser, so is security-sensitive because it will be processing complex untrusted input.

[Quality assurance]
Packaging is lintian-clean using modern dh(1) patterns and shows no problematic bug history in Debian or Ubuntu.

Package runs make check at build time (debhelper), but has no build-time tests or autopkgtests available.

Also depends on x265 and libde265 which are in universe.

Package would be maintained by Ubuntu Foundations Team.

Steve Langasek (vorlon) on 2019-05-02
description: updated
Changed in libheif (Ubuntu):
status: Incomplete → New

I've had a look, certainly seems fine packaging-wise; but should be looked at by the Security Team.

Changed in libheif (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Steve Langasek (vorlon) wrote :

I just noticed via https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg that libde265 wants to pull in:
 - qtbase-opensource-src (qt4)
  - qtchooser
  - double-conversion
  - qtsvg-opensource-src
  - qttranslations-opensource-src
 - libsd1.2
 - *ffmpeg*
  - zeromq3
   - norm
   - libpgm
  - libdc1394-22
  - libbs2b
  - x264
  - lilv
   - sratom
   - serd
   - sord
  - zvbi
  - libva
   - intel-vaapi-driver
   - intel-media-driver
    - intel-gmmlib
   - libset-scalar-perl
  - codec2
  - chromaprint
  - twitter-bootstrap3
  - libgsm
  - crystalhd
  - libopenmpt
  - game-music-emu
  - libvidstab
  - rubberband
  - aom
  - xvidcore
  - openjpeg2
  - libbluray
   - libaacs
    - libbdplus
  - openal-soft
   - sndio
  - shine
  - flite
  - libmysofa
  - libass

Sooo that's a huge pile of work and it's not justifiable in terms of reducing delta on the imagemagick package. I'm going to reupload imagemagick to drop the libheif build-dependency. Security feedback on the suitability of libheif is still welcome but is a low priority.

Seth Arnold (seth-arnold) wrote :

Wow, that's a pretty significant chain of deps. Thanks for pruning this one.

I had started in on libheif but not much beyond inspecting a few Coverity results. (More in the spirit of learning Coverity than inspecting libheif, I must be honest.)

I passed along the Coverity results to upstream on https://github.com/strukturag/libheif/issues/128 -- hopefully it'll be useful to them.


Joachim Bauch (fancycode) wrote :

libde265-0 actually pulls in a lot less dependencies:

The dependencies on Qt, SDL, swscale are being pulled in by the examples:

libheif only depends on libde265-0 and thus doesn't pull in the whole list of dependencies mentioned in #2

Steve Langasek (vorlon) wrote :

Joachim, thanks for bringing this to my attention. I've gone ahead and added libde265-examples to the exclusion list for main, and readded the libheif build-dep to imagemagick in order to revisit this MIR.

Seth, can this go back in the queue for security team review?

Seth Arnold (seth-arnold) wrote :

Thanks Joachim, Steve, I've removed the comment in trello saying this is on hold.


Amr Ibrahim (amribrahim1987) wrote :

Just a question, I thought build-dependencies need not be in main any more to build packages in main. It was announced some time ago on ubuntu-devel. Am I wrong?

Steve Langasek (vorlon) wrote :

It's correct that packages do not have to be in main merely for being build dependencies. But most libraries that are build dependencies are linked against during build and become runtime dependencies.

Balint Reczey (rbalint) wrote :

This MIR keeps imagemagick out of the release pocket in the devel release.

Changed in imagemagick (Ubuntu):
status: New → Invalid
tags: added: update-excuse
Seth Arnold (seth-arnold) wrote :

Apparently this is useful for photos from iPhones.

Changed in imagemagick (Ubuntu):
status: Invalid → Fix Released
Changed in imagemagick (Ubuntu):
status: Fix Released → Won't Fix
Launchpad Janitor (janitor) wrote :

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

Changed in libde265 (Ubuntu):
status: New → Confirmed
Changed in libheif (Ubuntu):
status: New → Confirmed
Changed in x265 (Ubuntu):
status: New → Confirmed
no longer affects: imagemagick (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.