2008.08.29 22:53 "[Tiff] Some security fixes from RHEL", by Even Rouault

2008.09.01 16:23 "Re: [Tiff] Some security fixes from RHEL", by Ron

On Mon, Sep 01, 2008 at 01:11:50AM -0400, Tom Lane wrote:

If an application needs to be secure/stable in the face of hostile files then it should not link against libtiff.

While the above statements are undoubtedly accurate, the sentiments that they express are unhealthy for the large community that uses libtiff.

More than that: they're unhealthy for the future of TIFF itself.

What this position is basically saying is that "TIFF is unsafe for use on the internet". Well, the internet is a sufficiently large chunk of the potential application space these days that making any such restriction is effectively signing your own death warrant.

I guess the authors of Internet Explorer didn't get that memo either.

People will simply stop using TIFF in favor of other alternatives that are more widely supported by safer (or perceived-to-be-safer) software.

As maintainer of Red Hat's libtiff package, I am now seriously wondering whether I must recommend that Red Hat disable TIFF support in any application that has any internet exposure.

You should recommend they disable all internet access. It's the only way to be sure that something terrible, like having your package repository hacked and security packages trojaned won't happen one day.

My rough estimate is that the number of packages that would continue to support TIFF after such a recommendation would be zero. libtiff would become an instant pariah.

Right. Like Certificate Authorities became instant pariahs after not noticing they'd been certifying thousands of identical keys from a very small set for two full years...

I realize that hardening libtiff is likely to be a long and tedious process. But I think failing to accept that you've got to do it is a good way to kill the project.

I think failing to understand what that would take and the chances of actually succeeding against a determined attacker, and assuming that it's someone else's problem to make something suitable for _your_ desired use, is an excellent way to ensure the 'hats have a long and prosperous future.

You've been given some frank and explicit advice, and a patch to apply for the latest known exploit. If you choose to ignore the former and not apply the latter before distributing it to your users, that would be on your head -- pointing fingers at people who didn't make the same assumptions you have, but are happy to share their work with you, doesn't strike me as a terribly productive chain of thought.

On the bright side though, once you've killed off all the projects that aren't safe to process untrusted data, you should find you are left with a distribution so small that it would be quite easy to maintain single handedly -- so if this is your itch, it's probably quite doable. In the same way that libtiff is perfectly functional for people who don't want to throw random things they found on the internet through it. I'm sure if people submit patches for new bugs they'll get applied eventually if they are correct. The real beauty of free software is you can apply them any time you like, without having to wait for someone else to find the time for that.

It always seems to work much better when people offer to help rather than insist someone who already gave you so much somehow owes you more as a result.

Do svidaniya,

 Comrade Hat