jorgelo@, could you add some appropriate labels to this issue? 

Thanks!

Missing Component, Security_Impact, Security_Severity labels.
Missing owner.

jorgelo@, sorry to bother you again. I wonder if you know who should own this.

What is the main tiff repo? npm@ has been sending patches upstream to what he thought was the official repo. 

Sorry, by "main tiff repo" here I meant the main Chrome OS tiff package at https://cs.corp.google.com/chromeos_public/src/third_party/portage-stable/media-libs/tiff/tiff-4.0.7.ebuild.

Unless you patch the package, you have to wait for it to be fixed upstream, no?

PDF plugin is not the main component here, adding the one I think matches the description.

This bug tracks applying the non-upstreamed tiff patches that PDFium developed, on the Chrome OS copy of tiff. Portage, the Chrome OS build system, has an easy way to apply patches to pacakges, even when those patches are not upstream.

If you want to file another bug to upstream those packages, that's fine, but that's not work tracked on this bug.

Oh ok, didn't see any patches on the link in #8, so that's why I asked. The CLs for 0006, 0017 are:

https://codereview.chromium.org/2284063002
https://pdfium-review.googlesource.com/c/2355/

bugbot didn't update this, but it's been fixed here:
https://chromium-review.googlesource.com/475630

and i don't plan on backporting to M58 due to higher risk here ... these patches aren't in upstream, and they've only been tested in the pdfium build env (which means being built with clang and newer C++ standards).  Gentoo already saw some breakage that i had to fix up in the patches.

Agree with not merging upstream. But could you explain what breakage you got in Gentoo? If it is just the .patch files not applying directly, that's probably because we have additional changes... Otherwise let us know if there is something we should fix in the code.

0006-HeapBufferOverflow-ChopUpSingleUncompressedStrip.patch is pretty bad: it declares an internal func in the public header (tiffio.h) instead of the private one (tiffiop.h), and it's implemented in C++ instead of C (which all of libtiff is written in), and it puts the func definition in a source file that isn't part of libtiff which means it'd never work on vanilla libtiff.

0013-validate-refblackwhite.patch requires newer C standard by placing "int i" into the for loop, and it doesn't include math.h for the isnan func.

really should have the patches sent to upstream libtiff.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot