Overview
Request History
DocB created request
- version 4.6.0t
see Changelog for details
tiff-CVE-2023-52356.patch removed (included in source)
jubalh declined request
http://www.libtiff.org/releases/v4.6.0t.html -> " This version fixes and restores all utilities and tool features that were removed or made unsupported in v4.6.0."
I'm sorry but for now this is not acceptable. There are so many unfixed security problems in those tools.
DocB reopened request
In a private message Lee Howard stated that he went though all reported bugs and all reported merge requests against those tools.
If you feel this is not sufficient please explain which issues have not been addressed
jubalh declined request
DocB revoked request
The package 'home:DocB:branches:network:telephony/tiff' has been removed
Changing to a fork of libtiff that simply reverts the changes the libtiff project made to discontinue unsupported tools with reported security problems is not a good idea IMHO.
The tools were always supported by some libtiff developers. They became "unsupported" in v4.6.0 because some other libtiff developers don't care about the tools and don't really want them in the package.
See also ongoing discussion in https://www.asmail.be/msg0055015786.html
Looks like they are applying security fixes for the re-implemented tools as well
Yes but it is still very much WIP. The tools are not re-implemented but just restored as they were and a couple of fixes added, if I see it right. If I remember correctly it was dozens of issues in those tools. I believe around 60. It's good that on this thread several people showed interest in helping out, so lets see where this is going. I'm thinking to write an email there soon as well with some ideas/opinions. It is a bit strange that 4.6.0t was released by Lee without noting that those tools are still mostly defective. In any case we will keep monitoring the development of this.
Michael, there were about 71 open bug reports that were marked "wontfix" when the tools were made unsupported by certain libtiff developers. I've been through every one of those bug reports. The majority of those bug reports were actually about issues within the library, itself, and were merely submitted against the tools, and those issues were already fixed by the time I looked at the matters. The developers who had marked them "wontfix" and moved to make the tools unsupported did so without bothering to check if the bug report was really about the tool in the first place. There were a very few bugs that still required fixing, and those were, indeed, fixed in v4.0.6t. Although the v4.5.1 release notes, some limited mailing list discussion, and the v4.6.0 release notes all indicate that the reasons for the tools being made unsupported was due to these bugs - understand that those developers did not undertake the effort to verify that the bugs were actually issues within the tools - and those developers did not undertake reasonable efforts to contact users of the tools and respond to the actual developers of the tools to get things figured out. Naturally, then, when the bugs are shown to be resolved and fixed, those same developers resist restoring the tools in their code repository. Therefore, users of those tools have no choice but to restore the tools in a separate code base. It may be that those libtiff developers eventually come to their senses and restore the tools in their repository, but I suspect that will not be for a long while. There is a lot of resistance to it which as you may suspect does not really have much to do with bugs or with development support but because their vision of libtiff does not include the tools and serves a different purpose from what other long-time users of libtiff need. So, ultimately the SuSE libtiff package maintainer is likely to need to decide about whether or not they want to provide SuSE users with ready access to those tools. Otherwise, users will simply go about some other method to get them. In Fedora/RedHat the tools are simply packaged separately from the library (libtiff and libtiff-tools), and I think that's a reasonable approach to letting users of the tools have access to them without requiring users of the library, alone, to install the tools.
Even so I think the current situation is not a big improvement.
Some time ago we had a problem with JasPer JPEG2000 image library, you can read about it here in case of interest: https://github.com/jasper-software/jasper/issues/208
In the end we went on forking it (because upstream was unresponsive). We fixed all the bugs and we clearly referenced them so that everybody can easily validate our work. See https://github.com/jasper-software/jasper/blob/master/NEWS.txt for version 2.0.19. This was done additionally to documenting all the details we had in the git history.
Later upstream became active again and we negotiated to merge our changes into the "old repo" and work together on that one. Our "fork" was not used by any distribution at that point, rather all of them removed jasper. Now JasPer is back in all distros, all the CVEs are fixed and the project is healthy and well maintained.
I appreciate your goal of bringing the tools back, and the time and work you have put into this. But I believe a few things could be improved (as mentioned in my mail to the mailing list).
I didn't follow the upstream discussions about the tools for too long, only started recently. So I might be lacking context. But I believe it would be best to prove how you improved them, promise to maintain them, find a few additional maintainers and then have get your changes into tiff upstream and become one of the maintainers there.
OR in case that is indeed met with too much resistance: work on a separate tiff-tools package. As Fridrich mentioned it should be quite possible. Maybe take your security improvements, take his changes to me the tools independent and coordinate with libtiff upstream what (if anything) they should change to at least help with a separate tools package. I cannot imagine that they would have anything against this.
I saw a comment in the mailing list about how hard it was to do the tools separate packages because of how closely linked with the libtiff internals they were. Normally, I don't take affirmation on their face values, so I tried to do separate tools from their state from one commit before their removal. What I learned? I managed to get the separate tools in my POC github projects https://github.com/fridrich/tiff-tools in few hours. They are pretty separable besides the fax2tiff that directly accesses the members of the "struct tiff" which is opaque in the libtiff API. So, since it was just a POC, I left that struct definition in th e the tiffiop.h header. I added a header tiff_tools_internal.h where I put all the defines that don't need to be closely bound to libtiff's internals as well as 3 function prototypes:
extern void *_TIFFCheckMalloc(TIFF *, tmsize_t, tmsize_t, const char *);
extern uint32_t _TIFFClampDoubleToUInt32(double);
extern uint32_t _TIFFMultiply32(TIFF *, uint32_t, uint32_t, const char *);
With a minimum of changes in libtiff, like getters and setters for the necessary access to the private members, exporting some of the missing SUPPORTED defines and putting the 3 helper function prototypes in the libtiff api, these things are perfectly separable.
Now, I really detect here a nice Jia Tan vibe with this 4.6.0t where the community is requested to migrate to a random fork out there. Libtiff is used in pretty many places and image format parsers are by definition security critical, since they always work with untrusted external data. So, give it a thought, whether put the effort into the separate tools would be not better use of time. But then, depends on the agenda one follows....
Jia Tan vibe? Seriously. Maybe spend some time getting to know my work in HylaFAX, libtiff, iaxmodem, and relayfaxosproj before you start drawing conclusions like that. I don't think you know me at all, so it's really unproductive to make such insinuations. I'm not requesting that the community migrate to the fork. I'm providing a fork that provides the tools to community members who need the tools. If they don't need the tools then they don't need to worry about the fork. I have no problem with there being a separate tiff-tools package, but as you've demonstrated, it's not possible without modification of the library (which, I believe, substantiates my earlier statements you've quoted as being "too hard" about it being more difficult than just fixing the bugs as has been done - since I found the same problems when I looked into it) ... and apparently something would need to be done about fax2tiff, still. Furthermore, libtiff v4.6.0 retained a couple tools including tiffcp - which would become a problem... they'd need to give those up in the library... and I'm unsure if that's what they really want to do. It's not been clear.
@fstrba, @jubalh: review reminder
I would be really happy if one could avoid reopening this one. We agreed with Michael not to integrate.
@DocB please see https://gitlab.com/libtiff/libtiff/-/merge_requests/581
@jubalh with https://gitlab.com/libtiff/libtiff/-/merge_requests/569 the changes seem to be in master branch. Can you pull the current version from git and update libtiff?
Hi Axel! Thanks for making me aware of this PR! I was monitoring the other one. I would prefer not to pull from git but wait for a new stable release. Just today Even Rouault wrote to the tiff mailing list that he plans to create 4.7.0 RC soon. So it shouldn't be too long :)