Re: [Tiff] www.libtiff.org is restored
On 4/9/24 8:49 AM, Michael Vetter via Tiff wrote: Now "http://www.libtiff.org/; leads to the latest libtiff HTML pages, and the same server/directory which already provides "http://www.simplesystems.org/libtiff/;. With some differences though. The biggest probably being that http://www.libtiff.org advertises a version 4.6.0t with all the tools restored. If I see it right it doesn't fix all the CVEs in those tools though. Which CVEs have not been addressed? I was only instructed to address a specific list of bug reports. If the CVEs were not in those bug reports, then there may be others yet to address. I believe this can be quite confusing to potential users of tiff. Wouldn't it have been better to first fix the CVEs and then create a new release? Or at least add a note/warning? Yes, it was certainly confusing to have the tools suddenly removed from the 4.6.0 release. The 4.6.0t changelog (http://libtiff.org/releases/v4.6.0t.html) doesn't give much insight either with entries like: Fix some issues in library found through fuzzing. Prevent some out-of-memory attacks. The git logs are available from the git repositories. It's a lot to summarize in the ChangeLog in a productive way. Maybe this helps the people who would like to bring the tools back and want to take the route of creating a separate tools package. The tools shouldn't need to be brought back in the first place. But if you want to develop a separate tools package, then I don't object to it. Thanks, Lee. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
[Tiff] www.libtiff.org is restored
> Now "http://www.libtiff.org/; leads to the latest libtiff HTML pages, and the > same server/directory which already provides > "http://www.simplesystems.org/libtiff/;. With some differences though. The biggest probably being that http://www.libtiff.org advertises a version 4.6.0t with all the tools restored. If I see it right it doesn't fix all the CVEs in those tools though. I believe this can be quite confusing to potential users of tiff. Wouldn't it have been better to first fix the CVEs and then create a new release? Or at least add a note/warning? Especially after the situation with `xz` people are more cautious of what sources they take. Having a kind of fork (https://gitlab.com/faxguy/libtiff-tools meaning libtiff + tools restored) on a website called http://libtiff.org/ (which sounds quite official) that are shipped in a tarball with almost the same name (plus a tiny `t`) is suboptimal in my opinion. The 4.6.0t changelog (http://libtiff.org/releases/v4.6.0t.html) doesn't give much insight either with entries like: > Fix some issues in library found through fuzzing. > Prevent some out-of-memory attacks. It would be good to have the links to the corresponding issues there. Or the CVE names, if applicable. Some of these can be found in https://gitlab.com/faxguy/libtiff-tools. But people need to really look for them. It is rather obscure for people quickly checking the site. And they most likely will not understand what is fixed and what is vulnerable compared to 4.6.0. It would also be great if fixed issues could be linked from the original bugreport in the main upstream repo though I didn't check if this was maybe done in some cases. I think I saw Lee Howard comment on some of the issues but am not sure if it were all. > Unfortunately, the demoted tools do not only use tiffconf.h. Some of them > rely heavily on libtiff internals. It wouldn't be a simple process to > separate the tools from the rest of libtiff. My colleague Fridrich took a quick look at it and created a POC: https://github.com/fridrich/tiff-tools He copied the few strictly necessary internal macros/prototypes from tiffiop.h into tiff_tools_internal.h. Now only fax2tiff cannot work with the opaque TIFF (struct tiff) type. Maybe some getters and setters exposing the necessary members could be implemented. Maybe this helps the people who would like to bring the tools back and want to take the route of creating a separate tools package. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On Sat, Feb 3, 2024 at 10:14 AM Bob Friesenhahn via Tiff wrote: > Lee Howard has managed to acquire the libtiff.org domain (with great > effort and expense to himself). That's amazing! I had long given hope on this, thank you restoring some justice to the internet, Lee! :) -Edward ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On 2/4/24 8:00 PM, William Bader wrote: Is it more complicated than trying to build the utilities with just the public header files to see what breaks, and then moving some declarations or wrappers to access them to a public header? I gave that a go a few months ago, and it didn't end well. It's certainly possible that I didn't do it right, but I found myself copying functions out of the C/C++ code, etc. before I concluded that I wasn't going that route. I could probably handle an occasional request with a cve and example tiff that is reproducible on Linux x86_64. These are the ones that I'm told need to be fixed: https://gitlab.com/libtiff/libtiff/-/issues/?sort=created_date=closed_name%5B%5D=wontfix-unmaintained Thanks, Lee. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
>Unfortunately, the demoted tools do not only use tiffconf.h. Some of them >rely heavily on libtiff internals. It wouldn't be a simple process to >separate the tools from the rest of libtiff. I didn't realize that. I think that is worth fixing. The utilities can't be examples of best use of libtiff if they access libtiff internals that normal applications can't use. Possibly other users of libtiff are forced into accessing the same libtiff internals, and it might help libtiff users if everything required to implement the utilities was part of the stable public api. Is it more complicated than trying to build the utilities with just the public header files to see what breaks, and then moving some declarations or wrappers to access them to a public header? >Fork libtiff How about setting up the utilities as a git repo that builds with libtiff as a submodule? The utilities would be able to reference a specific commit of libtiff, so they could access libtiff internals safely. >I have been trying to rally people interested in doing the work to fix the >security issues. I could probably handle an occasional request with a cve and example tiff that is reproducible on Linux x86_64. William From: Lee Howard Sent: Sunday, February 4, 2024 4:15 PM To: William Bader ; Bob Friesenhahn ; Rob Tillaart Cc: Patrice Fournier via Tiff Subject: Re: [Tiff] www.libtiff.org is restored On 2/4/24 8:11 AM, William Bader via Tiff wrote: >If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process Shouldn't the build for the utilities be simpler than the build for libtiff because the utilities only use tiffconf.h instead of generating it? The utilities should be best use examples for libtiff, and something might be wrong if they end up needing a massively complicated build process. Unfortunately, the demoted tools do not only use tiffconf.h. Some of them rely heavily on libtiff internals. It wouldn't be a simple process to separate the tools from the rest of libtiff. I understand and hear the opinions about having the tools be in a separate repository maintained by separate people, etc., but the tools can't really be ripped out of the library source and compile at all. To maintain the tools would necessarily require maintaining the library. The tools are integrated into the library source. The only paths forward that I can visualize would be: 1) Fix the security issues in the tools, commit to maintaining them long term, and restore the tools to the package as they were previously. This is what I had understood was acceptable to Even and Sulau. (And I'm a bit discouraged about slight backpedaling I'm hearing in this thread.) 2) Fork libtiff - one with the tools, and one without. (And the one with the tools would necessarily duplicate the one without.) Distributions would either need to choose between the two or package both in ways in which they wouldn't conflict, e.g., libtiff45 and libtiff. Again, I had heard that #1 was acceptable, and I have been trying to rally people interested in doing the work to fix the security issues. I'll do all of that work, myself, if I ultimately have to (once I can get some priority work out of the way first). I find it frustrating to hear comments here from dev team members suggesting that #1 is now not acceptable. I am in no way interested in #2. However, if #1 will never, ever happen then I am faced with no other practical option. Thanks, Lee. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On 2/4/24 8:11 AM, William Bader via Tiff wrote: >If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process Shouldn't the build for the utilities be simpler than the build for libtiff because the utilities only use tiffconf.h instead of generating it? The utilities should be best use examples for libtiff, and something might be wrong if they end up needing a massively complicated build process. Unfortunately, the demoted tools do not only use tiffconf.h. Some of them rely heavily on libtiff internals. It wouldn't be a simple process to separate the tools from the rest of libtiff. I understand and hear the opinions about having the tools be in a separate repository maintained by separate people, etc., but the tools can't really be ripped out of the library source and compile at all. To maintain the tools would necessarily require maintaining the library. The tools are integrated into the library source. The only paths forward that I can visualize would be: 1) Fix the security issues in the tools, commit to maintaining them long term, and restore the tools to the package as they were previously. This is what I had understood was acceptable to Even and Sulau. (And I'm a bit discouraged about slight backpedaling I'm hearing in this thread.) 2) Fork libtiff - one with the tools, and one without. (And the one with the tools would necessarily duplicate the one without.) Distributions would either need to choose between the two or package both in ways in which they wouldn't conflict, e.g., libtiff45 and libtiff. Again, I had heard that #1 was acceptable, and I have been trying to rally people interested in doing the work to fix the security issues. I'll do all of that work, myself, if I ultimately have to (once I can get some priority work out of the way first). I find it frustrating to hear comments here from dev team members suggesting that #1 is now not acceptable. I am in no way interested in #2. However, if #1 will never, ever happen then I am faced with no other practical option. Thanks, Lee. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On Sun, 4 Feb 2024, William Bader via Tiff wrote: What percentage of the tiff utility CVEs are coding errors in the utilities compared to issues that the utilities expose in libtiff? Most of the issues in modern times have been with the utilities code. The utilities code was originally "proof of concept" or "demo" level code, very similar to other code implemented at the time (the first libtiff release was in 1988!). Priority was placed on function and features. Libtiff itself got more attention from developers to make it robust and secure. A glance at the libtiff WikiPedia page (https://en.wikipedia.org/wiki/LibTIFF) shows that there is no much there other than mentions of past security issues. Iterative patching/fixing the utilities code (based on reported/detected issues) has not gotten it to where it should be. A thorough examination needs to be made in order to discover core weaknesses, and come up new designs which avoid intrinsic weaknesses, while still supporting existing requirements, and modern demands. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
>If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process Shouldn't the build for the utilities be simpler than the build for libtiff because the utilities only use tiffconf.h instead of generating it? The utilities should be best use examples for libtiff, and something might be wrong if they end up needing a massively complicated build process. William From: Tiff on behalf of Rob Tillaart via Tiff Sent: Sunday, February 4, 2024 9:09 AM To: Bob Friesenhahn Cc: Patrice Fournier via Tiff Subject: Re: [Tiff] www.libtiff.org is restored > If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process, and released distinctly from libtiff. If this approach is not acceptable to libtiff maintainers, then the tools would need to be hosted elsewhere. Agree, maybe even create a project per tool? my 2 cents, Rob On Sun, Feb 4, 2024 at 2:59 PM Bob Friesenhahn via Tiff mailto:tiff@lists.osgeo.org>> wrote: On Sat, 3 Feb 2024, Patrice Fournier via Tiff wrote: > > This would be really helpful indeed! I was already looking at my teams (iFAX > Solutions (HylaFAX Enterprise and HylaFAX), but also T38Fax which uses these > tools internally) to spare some time to work on this, but first, we'll need > to know where to work on this and where to handle the issues. We'd personally > prefer it be in the libtiff project, either in the main project, master > branch or at minimum a separate branch from which (security issues) fixed > tools are merged back into master. This would require all tools bugs to be > restored and `wontfix-unmaintained` tags changed to `tools` or something like > that, from which we could identify/label security issues and know which ones > to concentrate on for this task (and the main libtiff team could exclude in > their buglist if they so prefer, until we made enough progress). It is useful to be aware of the underlying reasons why utilities were removed from libtiff. Whenever a security issue is identified related to software produced by the libtiff project, a CVE was created against libtiff, since the utility was released as part of libtiff. Proprietary and free operating system and application distributions which include libtiff then had a huge red flag assigned to them, which demands action. The utilities were continually having CVEs at the most severe levels written against them. It is also a fact that several people maintaining core libtiff primarily care about the library and not these old utilities. If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process, and released distinctly from libtiff. If this approach is not acceptable to libtiff maintainers, then the tools would need to be hosted elsewhere. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us<mailto:bfrie...@simple.dallas.tx.us>, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ Tiff mailing list Tiff@lists.osgeo.org<mailto:Tiff@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/tiff ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
If the tiff utilities are moved to their own project, how closely would they need to track changes in the libtiff api or to support different versions of libtiff? I thought that the tiff utility programs were, in part, examples showing best practice in using libtiff, so there is a benefit to having the utilities in libtiff or connected to it. First time users of libtiff probably look at how the utilities work. What percentage of the tiff utility CVEs are coding errors in the utilities compared to issues that the utilities expose in libtiff? I use tiff2ps. If you split the utilities into their own project, I would be willing to be on the list of people who help with CVEs. William From: Tiff on behalf of Even Rouault via Tiff Sent: Sunday, February 4, 2024 9:23 AM To: Bob Friesenhahn ; Patrice Fournier via Tiff Subject: Re: [Tiff] www.libtiff.org is restored Hi, > It is useful to be aware of the underlying reasons why utilities were > removed from libtiff. Whenever a security issue is identified related > to software produced by the libtiff project, a CVE was created against > libtiff, since the utility was released as part of libtiff. > Proprietary and free operating system and application distributions > which include libtiff then had a huge red flag assigned to them, which > demands action. The utilities were continually having CVEs at the > most severe levels written against them. I concur with that. > > It is also a fact that several people maintaining core libtiff > primarily care about the library and not these old utilities. I'm one of those people. I personally only use libtiff, and occasionally for debugging purposes tiffdump and tiffinfo. Very very infrequently tiffset > > If the utilities are again maintained by the libtiff project, they > need to be in a separate repository, with its own build process, and > released distinctly from libtiff. If this approach is not acceptable > to libtiff maintainers, then the tools would need to be hosted elsewhere. My own preference would be for a separate repository too. That would avoid libtiff-the-lib to be perceived as being affected by issues specific to the utilities, and would allow people interested in the utilities to do releases at their own pace. One "little detail" though that can go against moving them to a separate repo is that most of those utilities include "tiffiop.h", a private non-installed header. But I suspect/hope that in most time it is an oversight, and that dependency could easily be removed (although some fax related utilities might use internal details of the fax codec). I'm not entirely closed to the idea of motivated volunteers trying to resurrect a subset of those utilities in libtiff main repo, but they must be ready to do a very significant amount work to address those already reported vulnerabilities, and the ones that will for sure come in the future. One thing that make it hard to maintain the utilities is that they have very little regression tests (to be fair, the library itself could be more tested too, and there has certainly been effort in adding unit tests recently for modified/added functionality), so any security patching made by people not familiar with them had the opportunity to break things. Regards, Even -- http://www.spatialys.com My software is free, but my time generally not. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On Sat, 3 Feb 2024, Patrice Fournier via Tiff wrote: P.S. http://libtiff.org/ doesn't redirect like http://www.libtiff.org/ does. It shows the main Simple Systems web page. I was aware of that when I first implemented it, and did not make any effort to address it. It should be addressed now. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
Hi, It is useful to be aware of the underlying reasons why utilities were removed from libtiff. Whenever a security issue is identified related to software produced by the libtiff project, a CVE was created against libtiff, since the utility was released as part of libtiff. Proprietary and free operating system and application distributions which include libtiff then had a huge red flag assigned to them, which demands action. The utilities were continually having CVEs at the most severe levels written against them. I concur with that. It is also a fact that several people maintaining core libtiff primarily care about the library and not these old utilities. I'm one of those people. I personally only use libtiff, and occasionally for debugging purposes tiffdump and tiffinfo. Very very infrequently tiffset If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process, and released distinctly from libtiff. If this approach is not acceptable to libtiff maintainers, then the tools would need to be hosted elsewhere. My own preference would be for a separate repository too. That would avoid libtiff-the-lib to be perceived as being affected by issues specific to the utilities, and would allow people interested in the utilities to do releases at their own pace. One "little detail" though that can go against moving them to a separate repo is that most of those utilities include "tiffiop.h", a private non-installed header. But I suspect/hope that in most time it is an oversight, and that dependency could easily be removed (although some fax related utilities might use internal details of the fax codec). I'm not entirely closed to the idea of motivated volunteers trying to resurrect a subset of those utilities in libtiff main repo, but they must be ready to do a very significant amount work to address those already reported vulnerabilities, and the ones that will for sure come in the future. One thing that make it hard to maintain the utilities is that they have very little regression tests (to be fair, the library itself could be more tested too, and there has certainly been effort in adding unit tests recently for modified/added functionality), so any security patching made by people not familiar with them had the opportunity to break things. Regards, Even -- http://www.spatialys.com My software is free, but my time generally not. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On Sun, 4 Feb 2024, Rob Tillaart wrote: If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process, and released distinctly from libtiff. If this approach is not acceptable to libtiff maintainers, then the tools would need to be hosted elsewhere. Agree, maybe even create a project per tool? Keep in mind that each new project creates an additional package to be separately maintained for OS distributions. This is potentially more burden. Common things such as a build/test infrastructure would need to be duplicated, and duplication is not a good thing. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
> If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process, and released distinctly from libtiff. If this approach is not acceptable to libtiff maintainers, then the tools would need to be hosted elsewhere. Agree, maybe even create a project per tool? my 2 cents, Rob On Sun, Feb 4, 2024 at 2:59 PM Bob Friesenhahn via Tiff < tiff@lists.osgeo.org> wrote: > On Sat, 3 Feb 2024, Patrice Fournier via Tiff wrote: > > > > This would be really helpful indeed! I was already looking at my teams > (iFAX > > Solutions (HylaFAX Enterprise and HylaFAX), but also T38Fax which uses > these > > tools internally) to spare some time to work on this, but first, we'll > need > > to know where to work on this and where to handle the issues. We'd > personally > > prefer it be in the libtiff project, either in the main project, master > > branch or at minimum a separate branch from which (security issues) > fixed > > tools are merged back into master. This would require all tools bugs to > be > > restored and `wontfix-unmaintained` tags changed to `tools` or something > like > > that, from which we could identify/label security issues and know which > ones > > to concentrate on for this task (and the main libtiff team could exclude > in > > their buglist if they so prefer, until we made enough progress). > > It is useful to be aware of the underlying reasons why utilities were > removed from libtiff. Whenever a security issue is identified related > to software produced by the libtiff project, a CVE was created against > libtiff, since the utility was released as part of libtiff. > Proprietary and free operating system and application distributions > which include libtiff then had a huge red flag assigned to them, which > demands action. The utilities were continually having CVEs at the > most severe levels written against them. > > It is also a fact that several people maintaining core libtiff > primarily care about the library and not these old utilities. > > If the utilities are again maintained by the libtiff project, they > need to be in a separate repository, with its own build process, and > released distinctly from libtiff. If this approach is not acceptable > to libtiff maintainers, then the tools would need to be hosted > elsewhere. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > ___ > Tiff mailing list > Tiff@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/tiff > ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On Sat, 3 Feb 2024, Patrice Fournier via Tiff wrote: This would be really helpful indeed! I was already looking at my teams (iFAX Solutions (HylaFAX Enterprise and HylaFAX), but also T38Fax which uses these tools internally) to spare some time to work on this, but first, we'll need to know where to work on this and where to handle the issues. We'd personally prefer it be in the libtiff project, either in the main project, master branch or at minimum a separate branch from which (security issues) fixed tools are merged back into master. This would require all tools bugs to be restored and `wontfix-unmaintained` tags changed to `tools` or something like that, from which we could identify/label security issues and know which ones to concentrate on for this task (and the main libtiff team could exclude in their buglist if they so prefer, until we made enough progress). It is useful to be aware of the underlying reasons why utilities were removed from libtiff. Whenever a security issue is identified related to software produced by the libtiff project, a CVE was created against libtiff, since the utility was released as part of libtiff. Proprietary and free operating system and application distributions which include libtiff then had a huge red flag assigned to them, which demands action. The utilities were continually having CVEs at the most severe levels written against them. It is also a fact that several people maintaining core libtiff primarily care about the library and not these old utilities. If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process, and released distinctly from libtiff. If this approach is not acceptable to libtiff maintainers, then the tools would need to be hosted elsewhere. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On 04/02/2024 02:08, miguel medalha via Tiff wrote: As they are now, neither ImageMagick nor GraphicsMagick are a match for the functionality of tiff2pdf. Having easy control over the image position on the page (i.e. page size and horizontal and vertical offsets) and Distiller-like capabilities, such as inclusion of notes, bookmarks, and metadata in general, on the fly are essential for my kind of work. Speed is also important when processing thousands of pages. img2pdf https://pypi.org/project/img2pdf/ is my favourite replacement for tiff2pdf. ocrmypdf is also a very useful addition, as it supports PDF/A. Regards Jeff OpenPGP_signature.asc Description: OpenPGP digital signature ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On Sat, 3 Feb 2024, Leonard Rosenthol via Tiff wrote: There should be no reason for tiff2ps in 2024….but I agree that having a high quality, open source, TIFF->PDF solution benefits everyone. Given the advances in PDF since the last time that tool was touched, it would probably be more reasonable to see if we could partner up with some other solution to keep that supported into the future. Alternatively, maybe this is an opportunity to improve the PDF output in something like GraphicsMagick - Bob?? Knowledgeable volunteers are certainly needed to improve the PDF support in GraphicsMagick. However, even with perfect PDF support, general-purpose software like GraphicsMagick will never be able to perform as well (for a specific purpose) as a special-purpose tool. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On Sun, Feb 4, 2024 at 12:23 AM Leonard Rosenthol via Tiff wrote: > > There should be no reason for tiff2ps in 2024….but I agree that having a high > quality, open source, TIFF->PDF solution benefits everyone. > > > > Given the advances in PDF since the last time that tool was touched, it would > probably be more reasonable to see if we could partner up with some other > solution to keep that supported into the future. Alternatively, maybe this > is an opportunity to improve the PDF output in something like GraphicsMagick > - Bob?? do you plan to use an external lib for pdf output, like poppler or mupdf ? Vincent Torri > > > Leonard > > > > From: Tiff on behalf of miguel medalha via > Tiff > Date: Saturday, February 3, 2024 at 11:38 AM > To: tiff@lists.osgeo.org > Subject: Re: [Tiff] www.libtiff.org is restored > > EXTERNAL: Use caution when clicking on links or opening attachments. > > > > (...) It would be beneficial for his project (and others) if > > the deprecated/removed libtiff utilities are restored (with security > > fixes), if even as a different project from libtiff itself. > > I strongly agree, in particular the 'tiff2ps' and 'tiff2pdf' tools. They are > immensely useful in the post-processing workflows of mass digitization of > documents. I know no other tools with their exact capabilities. > > > ___ > Tiff mailing list > Tiff@lists.osgeo.org > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Ftiff=05%7C02%7Clrosenth%40adobe.com%7C09c8485d8bbf42e3fd5608dc24d68ea4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638425751137804299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=tClsdKM1iJpp5rL3JPnZQ3lnHqNQgwWRcAAAmwDtDKI%3D=0 > > ___ > Tiff mailing list > Tiff@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/tiff ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
> There should be no reason for tiff2ps in 2024 .but I agree that having a high quality, open source, TIFF->PDF solution benefits everyone. I can agree with that and I think that the effort should be on tiff2pdf. > Given the advances in PDF since the last time that tool was touched, it would probably be more > reasonable to see if we could partner up with some other solution to keep that supported into the future. > Alternatively, maybe this is an opportunity to improve the PDF output in something like GraphicsMagick - Bob?? As they are now, neither ImageMagick nor GraphicsMagick are a match for the functionality of tiff2pdf. Having easy control over the image position on the page (i.e. page size and horizontal and vertical offsets) and Distiller-like capabilities, such as inclusion of notes, bookmarks, and metadata in general, on the fly are essential for my kind of work. Speed is also important when processing thousands of pages. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
Thank you all for this. I’m a lurker, but have followed this saga all along. Paul On Feb 3, 2024, at 6:28 PM, Patrice Fournier via Tiff wrote: Hi Bob, On 2024-02-03 10:00, Bob Friesenhahn via Tiff wrote: Lee Howard has managed to acquire the libtiff.org domain (with great effort and expense to himself). That's an excellent news! Thanks Lee! On 2024-02-03 11:15, Bob Friesenhahn via Tiff wrote: We should keep in mind that Lee Howard is a maintainer of Hylafax, which is now broken given latest libtiff due to many libtiff utilities being removed. It would be beneficial for his project (and others) if the deprecated/removed libtiff utilities are restored (with security fixes), if even as a different project from libtiff itself. This would be really helpful indeed! I was already looking at my teams (iFAX Solutions (HylaFAX Enterprise and HylaFAX), but also T38Fax which uses these tools internally) to spare some time to work on this, but first, we'll need to know where to work on this and where to handle the issues. We'd personally prefer it be in the libtiff project, either in the main project, master branch or at minimum a separate branch from which (security issues) fixed tools are merged back into master. This would require all tools bugs to be restored and `wontfix-unmaintained` tags changed to `tools` or something like that, from which we could identify/label security issues and know which ones to concentrate on for this task (and the main libtiff team could exclude in their buglist if they so prefer, until we made enough progress). Working in a separate project under the libtiff group or a separate one (I got `libtiff-tools` just in case) would allow giving rights to different people from the main project and have the bugs completely separated if that is preferred. And if it's a fork of the main project, still makes for easy merge requests so the fixes makes it to the main project. Adding that layer would complicate things when it's time to report bugs to tools though, especially when some tools bugs need to go to the main project and not others. Is the libtiff team willing to have a group of helpers come on board to work on tools issues inside the libtiff project so we can restore these tools and willing to restore tools to build automatically inside the main libtiff project? (So at first, restore the issues that have been closed so we can work on this and agree to get tools back inside the main project?) If the goal is to not burden the current team with these issues, then we'd need to create a tools team to triage these bugs, add labels, close them, etc., so that would require at minimum some reporter level users. Might also need some developer to merge the fixes unless the main team is willing to accept that role. P.S. http://libtiff.org/ doesn't redirect like http://www.libtiff.org/ does. It shows the main Simple Systems web page. Regards, -- Patrice Fournier iFAX Solutions, Inc. http://www.ifax.com/ ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
Hi Bob, On 2024-02-03 10:00, Bob Friesenhahn via Tiff wrote: Lee Howard has managed to acquire the libtiff.org domain (with great effort and expense to himself). That's an excellent news! Thanks Lee! On 2024-02-03 11:15, Bob Friesenhahn via Tiff wrote: We should keep in mind that Lee Howard is a maintainer of Hylafax, which is now broken given latest libtiff due to many libtiff utilities being removed. It would be beneficial for his project (and others) if the deprecated/removed libtiff utilities are restored (with security fixes), if even as a different project from libtiff itself. This would be really helpful indeed! I was already looking at my teams (iFAX Solutions (HylaFAX Enterprise and HylaFAX), but also T38Fax which uses these tools internally) to spare some time to work on this, but first, we'll need to know where to work on this and where to handle the issues. We'd personally prefer it be in the libtiff project, either in the main project, master branch or at minimum a separate branch from which (security issues) fixed tools are merged back into master. This would require all tools bugs to be restored and `wontfix-unmaintained` tags changed to `tools` or something like that, from which we could identify/label security issues and know which ones to concentrate on for this task (and the main libtiff team could exclude in their buglist if they so prefer, until we made enough progress). Working in a separate project under the libtiff group or a separate one (I got `libtiff-tools` just in case) would allow giving rights to different people from the main project and have the bugs completely separated if that is preferred. And if it's a fork of the main project, still makes for easy merge requests so the fixes makes it to the main project. Adding that layer would complicate things when it's time to report bugs to tools though, especially when some tools bugs need to go to the main project and not others. Is the libtiff team willing to have a group of helpers come on board to work on tools issues inside the libtiff project so we can restore these tools and willing to restore tools to build automatically inside the main libtiff project? (So at first, restore the issues that have been closed so we can work on this and agree to get tools back inside the main project?) If the goal is to not burden the current team with these issues, then we'd need to create a tools team to triage these bugs, add labels, close them, etc., so that would require at minimum some reporter level users. Might also need some developer to merge the fixes unless the main team is willing to accept that role. P.S. http://libtiff.org/ doesn't redirect like http://www.libtiff.org/ does. It shows the main Simple Systems web page. Regards, -- Patrice Fournier iFAX Solutions, Inc. http://www.ifax.com/ ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
There should be no reason for tiff2ps in 2024….but I agree that having a high quality, open source, TIFF->PDF solution benefits everyone. Given the advances in PDF since the last time that tool was touched, it would probably be more reasonable to see if we could partner up with some other solution to keep that supported into the future. Alternatively, maybe this is an opportunity to improve the PDF output in something like GraphicsMagick - Bob?? Leonard From: Tiff on behalf of miguel medalha via Tiff Date: Saturday, February 3, 2024 at 11:38 AM To: tiff@lists.osgeo.org Subject: Re: [Tiff] www.libtiff.org is restored EXTERNAL: Use caution when clicking on links or opening attachments. > (...) It would be beneficial for his project (and others) if > the deprecated/removed libtiff utilities are restored (with security > fixes), if even as a different project from libtiff itself. I strongly agree, in particular the 'tiff2ps' and 'tiff2pdf' tools. They are immensely useful in the post-processing workflows of mass digitization of documents. I know no other tools with their exact capabilities. ___ Tiff mailing list Tiff@lists.osgeo.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Ftiff=05%7C02%7Clrosenth%40adobe.com%7C09c8485d8bbf42e3fd5608dc24d68ea4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638425751137804299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=tClsdKM1iJpp5rL3JPnZQ3lnHqNQgwWRcAAAmwDtDKI%3D=0<https://lists.osgeo.org/mailman/listinfo/tiff> ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
> (...) It would be beneficial for his project (and others) if > the deprecated/removed libtiff utilities are restored (with security > fixes), if even as a different project from libtiff itself. I strongly agree, in particular the 'tiff2ps' and 'tiff2pdf' tools. They are immensely useful in the post-processing workflows of mass digitization of documents. I know no other tools with their exact capabilities. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
On Sat, 3 Feb 2024, Even Rouault wrote: Hi Bob, (by the way I had to manually accept your message. You should probably (re?)register your email) Done. I forgot that I changed my email address when I was away on a three week trip and there was a partial network outage. Now I am subscribed twice. This is excellent news ! Thanks for sharing it! Would it be possible that libtiff.org just redirects to https://libtiff.gitlab.io/libtiff/, which will probably have better scalability ? But that's nitpicking. Having got control back is the main thing. Thanks to Lee! I have added the redirection for "http://www.libtiff.org/;, but retained "http://www.simplesystems.org/libtiff/;, for redundancy purposes. Since Lee Howard is in charge of this domain, he is free to make any changes to it later, such as change it to a dedicated server. We should keep in mind that Lee Howard is a maintainer of Hylafax, which is now broken given latest libtiff due to many libtiff utilities being removed. It would be beneficial for his project (and others) if the deprecated/removed libtiff utilities are restored (with security fixes), if even as a different project from libtiff itself. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] www.libtiff.org is restored
Hi Bob, (by the way I had to manually accept your message. You should probably (re?)register your email) This is excellent news ! Thanks for sharing it! Would it be possible that libtiff.org just redirects to https://libtiff.gitlab.io/libtiff/, which will probably have better scalability ? But that's nitpicking. Having got control back is the main thing. Thanks to Lee! Even Le 03/02/2024 à 16:00, Bob Friesenhahn via Tiff a écrit : Lee Howard has managed to acquire the libtiff.org domain (with great effort and expense to himself). The libtiff.org domain was hijacked many years ago, and since then it has only provided stale pages for an archaic version of libtiff. Now "http://www.libtiff.org/; leads to the latest libtiff HTML pages, and the same server/directory which already provides "http://www.simplesystems.org/libtiff/;. This is still a server with limited bandwidth which runs out of a server closet in my residence. Please treat it kindly! Bob -- http://www.spatialys.com My software is free, but my time generally not. ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
[Tiff] www.libtiff.org is restored
Lee Howard has managed to acquire the libtiff.org domain (with great effort and expense to himself). The libtiff.org domain was hijacked many years ago, and since then it has only provided stale pages for an archaic version of libtiff. Now "http://www.libtiff.org/; leads to the latest libtiff HTML pages, and the same server/directory which already provides "http://www.simplesystems.org/libtiff/;. This is still a server with limited bandwidth which runs out of a server closet in my residence. Please treat it kindly! Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
