"Roberto C. Sánchez" <robe...@debian.org> writes: > That sounds like a flawed assumption. The spec (I provide a working > link below) describes the format of a TIFF as being made up of an 8 byte > header and one or more images (IFDs, or image file directories).
Yes, that was my guess too, although I couldn't find any evidence. > The specification is available from the ITU and also the Library of > Congress (which in turn links to the Wayback Machine): > > https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf > https://www.loc.gov/preservation/digital/formats/fdd/fdd000022.shtml > https://web.archive.org/web/20150503034412/http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf Ok, thanks. Will have a look. > That link is outdated. I am curious where you found that link. The > debian/control lists a current URL. Google helped me find it :-) > Upstream can be found here now: > > http://libtiff.maptools.org/ > http://libtiff.maptools.org/bugs.html > http://libtiff.maptools.org/support.html Ok, thanks. Oops, looks like I was getting confused with this CVE (security tracker links to the upstream bug report) and CVE-2017-11613 (security tracker links to redhat and has no upstream BTS reference). So http://bugzilla.maptools.org/show_bug.cgi?id=2704 is the correct reference for this CVE. > Of these I dislike the third option the least. The first two have the > potential to fail silently or to just give subtly incorrect results. I > think that failing noisily with an error explaining why the failure > occurred is less bad than silently giving subtly wrong results. Yes, I tend to agree. -- Brian May <b...@debian.org>
