A user reports on IRC (dastore @ freenode), requesting ETA on update to the tiff port. User reports: tiff-4.0.6_2 is vulnerable: CVE: CVE-2016-5102 4.0.6_2 appears to be the latest version in the tree committed by feld with comment: An additional CVE is not yet addressed, but upstream indicates they are removing the gif2tiff utility as the mitigation in the upcoming 4.0.7. Given the upstream mitigation for gif2tiff removal in 4.0.7 is known, I propose we remove it in our port until the future release, given the outstanding vulnerability, and no other mechanism to mitigate.
I considered this, but I don't know if it's the right thing to do. Someone out there might be using gif2tiff in a safe environment and need it to work. By removing it from the port and MFH to quarterly we are *removing* features -- especially from quarterly, the stable branch -- and this feels... wrong. I would like others to weigh in on this. One of the MySQL ports was still vulnerable to a MITM attack that upstream said they're never going to patch and we didn't remove that version of MySQL from the ports tree or leave it marked vulnerable indefinitely. Instead what I did was add a warning as a pkg-message to let users know. Maybe that's a better remediation? I don't know... I wish I knew how long before the next tiff release. Just braindumping right now, still need coffee. :-)
Another user report: https://lists.freebsd.org/pipermail/freebsd-ports-bugs/2016-July/343622.html Option: pkg-message Pro: Provides a user with a mitigation option Con: Only shown once (on upgrade) Con: User might miss it Option: remove gif2tiff Pro: Mitigates vulnerability Pro: Matches upstream mitigation Con: Removes feature (but next version will remove it anyway) The time to next release is less material than say, our confidence that that will actually remove gif2tiff. If there's a chance they wont, in favour of doing something else, or they haven't been explicit about their decision to do so, we might be better off being incremental: 1) Inform users now of the option they have. pkg-message, but also, do this in the vuxml message too if we can. 2) As soon as gif2tiff is removed upstream, remove it here and in stable in anticipation of the next release If we're confident they will remove it, we heads up freebsd-ports, remove it, add a pkg-message saying it's been removed and why (ensuring users have context) We may optionally provide a user with an OPT-IN way to restore functionality if they need it. Perhaps we can: 1) Split out gif2tiff into another port/package 2) Make it vulnerable too (in vuxml) 3) Add a reference to graphics/tiff-gif2tiff in pkg-message) Optional: A non-default OPTION in graphics/tiff to include the binary (maybe this just does or doesn't do a ${RM} in the port after it builds), that the sub-port (graphics/tiff-tiff2giff) enables I need more coffee too now
Another user reporting no tiff update on IRC: fengshaun │ looks like tff-4.0.5_2 is vulnerable, but the ports tree doesn't have a newer version
We should make a decision sooner rather than later.
Created attachment 173094 [details] patch tiff to remove gif2tiff and its docs
I've attached a patch that works and would allow us to update the vuxml entry to make this port no longer vulnerable. However, I'm not comfortable with committing this absent portmgr approval as this is a functionality change of the tiff port and portmgr specifically maintains graphics/tiff due to widespread breakage an update/functionality change can cause. An exp-run to make sure no ports that depend on tiff expect gif2tiff to exist would be wise.
I disagree with this kind of fix. I'd rather have a message that says that tiff has had several vulnerabilities in the past, and will probably have several vulnerabilities in the future, install and use at your own risk..
According to http://bugzilla.maptools.org/show_bug.cgi?id=2552 someone is working on a fix for gif2tiff.
Another user asking about what's happening: https://lists.freebsd.org/pipermail/freebsd-questions/2016-August/272932.html The bug referenced by Kurt in comment 8 was closed WONTFIX, with comment that the utility would be removed. I see no alternative courses of action mentioned. Assign to ports-secteam for a decision
The vuxml entry has been cancelled after consideration of the impact and upstream's response. https://svnweb.freebsd.org/ports?view=revision&revision=419692