AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
August 2008

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2008.08.29 22:53 "Some security fixes from RHEL", by Even Rouault
2008.08.30 02:08 "Re: Some security fixes from RHEL", by Tom Lane
2008.09.01 22:18 "Re: libtiff security", by Dmitry V Levin
2008.08.31 15:17 "Re: Some security fixes from RHEL", by Frank Warmerdam
2008.08.31 15:38 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.08.31 21:09 "Re: Some security fixes from RHEL", by Rogier Wolff
2008.08.31 21:21 "Re: Some security fixes from RHEL", by <o.druemmer@callassoftware.com>
2008.08.31 21:51 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.08.31 22:08 "Re: Some security fixes from RHEL", by Lee Howard
2008.08.31 22:21 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.01 22:10 "Re: Some security fixes from RHEL", by Dmitry V Levin
2008.09.03 08:21 "Re: Some security fixes from RHEL", by Andrey Kiselev
2008.09.03 15:11 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.03 17:31 "Re: Some security fixes from RHEL", by <ron@debian.org>
2008.09.03 17:48 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.08.31 21:52 "Re: Some security fixes from RHEL", by Toby Thain
2008.08.31 22:01 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.08.31 21:59 "Re: Some security fixes from RHEL", by Lee Howard
2008.08.31 22:17 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.01 06:29 "Re: Some security fixes from RHEL", by Rogier Wolff
2008.09.01 06:53 "Re: Some security fixes from RHEL", by Toby Thain
2008.09.01 03:12 "Re: Some security fixes from RHEL", by Frank Warmerdam
2008.09.01 15:52 "Re: Some security fixes from RHEL", by Lee Howard
2008.09.01 21:33 "Re: Some security fixes from RHEL", by Frank Warmerdam
2008.09.03 16:38 "Re: Some security fixes from RHEL", by Lee Howard
2008.09.03 17:07 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.03 17:20 "Re: Some security fixes from RHEL", by Lee Howard
2008.09.03 18:02 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.03 18:13 "Re: Some security fixes from RHEL", by Lee Howard
2008.09.03 18:43 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.03 20:47 "Re: Some security fixes from RHEL", by Edward Lam
2008.09.03 21:01 "Re: Some security fixes from RHEL", by Lee Howard
2008.09.03 18:32 "Re: Some security fixes from RHEL", by Frank Warmerdam
2008.09.03 19:04 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.03 19:32 "Re: Some security fixes from RHEL", by <ron@debian.org>
2008.09.03 21:39 "Re: Some security fixes from RHEL", by Lee Howard
2008.09.03 21:59 "Re: Some security fixes from RHEL", by Even Rouault
2008.09.03 22:35 "Re: Some security fixes from RHEL", by <ron@debian.org>
2008.09.03 23:31 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.04 07:47 "Re: Some security fixes from RHEL", by <ron@debian.org>
2008.09.04 12:55 "Re: Some security fixes from RHEL", by Edward Lam
2008.09.06 01:20 "Re: Some security fixes from RHEL", by Jay Berkenbilt
2008.09.04 07:22 "Re: Some security fixes from RHEL", by Andrey Kiselev
2008.09.04 08:05 "Re: Some security fixes from RHEL", by Tom Lane
2008.09.04 08:52 "Re: Some security fixes from RHEL", by Andrey Kiselev
2008.09.04 20:06 "tiffsplit.c broken on Windows in trunk", by Edward Lam
2008.09.04 20:41 "Re: tiffsplit.c broken on Windows in trunk", by Toby Thain
2008.09.04 21:13 "Re: tiffsplit.c broken on Windows in trunk", by Edward Lam
2008.09.05 06:42 "Re: tiffsplit.c broken on Windows in trunk", by Andrey Kiselev
2008.09.03 17:16 "Re: Some security fixes from RHEL", by Frank Warmerdam
2008.09.04 07:45 "Re: Some security fixes from RHEL", by Andrey Kiselev
2008.09.01 22:30 "Re: Some security fixes from RHEL", by Dmitry V Levin
2008.09.03 08:05 "Re: Some security fixes from RHEL", by Andrey Kiselev
2008.09.01 05:11 "Re: Some security fixes from RHEL", by Tom Lane
2008.09.01 15:30 "Re: Some security fixes from RHEL", by Frank Warmerdam
2008.09.01 15:33 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.02 08:13 "Re: Some security fixes from RHEL", by Tom Lane
2008.09.02 08:24 "Re: Some security fixes from RHEL", by Tom Lane
2008.09.02 12:01 "Re: Some security fixes from RHEL", by Kai-uwe Behrmann
2008.09.02 15:49 "Re: Some security fixes from RHEL", by <ron@debian.org>
2008.09.03 08:14 "Re: Some security fixes from RHEL", by Andrey Kiselev
2008.09.03 14:07 "Re: Some security fixes from RHEL", by Frank Warmerdam
2008.09.03 15:53 "Re: Some security fixes from RHEL", by Frank Warmerdam
2008.09.01 16:23 "Re: Some security fixes from RHEL", by <ron@debian.org>
2008.09.01 18:00 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.01 22:04 "Re: Some security fixes from RHEL", by Dmitry V Levin
2008.09.01 15:40 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.01 18:19 "Re: Some security fixes from RHEL", by Rogier Wolff
2008.09.01 18:45 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.02 15:54 "Re: Some security fixes from RHEL", by <ron@debian.org>
2008.09.02 16:39 "Re: Some security fixes from RHEL", by Bob Friesenhahn
2008.09.03 08:03 "Re: Some security fixes from RHEL", by Andrey Kiselev

2008.09.01 15:52 "Re: Some security fixes from RHEL", by Lee Howard

Frank Warmerdam wrote:
> Lee Howard wrote:
>> While the above statements are undoubtedly accurate, the sentiments 
>> that they express are unhealthy for the large community that uses 
>> libtiff.  So, while the statements may be true, they really should 
>> not so be.
>>
>> Maintainers and developers of any software should be committed to the 
>> software development and to the health of the community that uses 
>> that software.  Some degree of responsibility is expected.  When 
>> flaws in the software are discovered, be they rather benign or 
>> security-related, the community looks to developers and maintainers 
>> to take action.  Failure to take action leads the community into an 
>> atmosphere of uncertainty and mistrust... all of which further 
>> inhibits the software development cycle.
>>
>> Understand that while the software development process may be slow, 
>> stagnant, or distracted, distribution maintainers and application 
>> maintainers are under pressure from their own customers to be 
>> responsive and to indemnify any inaction by the upstream.  Thus you 
>> will find RedHat, Fedora, SuSE, Debian, Gentoo, etc. maintainers who 
>> will have to patch and patch and continue to patch to satisfy those 
>> expectations.
>>
>> It seems to me that the least that could be done in such situations 
>> would be to accept the patches developed downstream and to 
>> acknowledge and be at least verbally responsive to credible reports 
>> of such issues.
>
> Lee,
>
> It would be helpful to have additional libtiff maintainers interested in
> taking on such problems. I will say that I expect to apply the provided
> patch, though it would be better if this could be handled without
> depending on me. 

I am willing to volunteer to:

* Commit applicable downstream patches (i.e. security patches in 
RedHat's build).

* Commit applicable patches that appear on this mailing list, on 
bugzilla, or come to me in a more private manner.

* Monitor bug reports (esp. bugzilla) in an effort to encourage the 
reporter to provide enough information such that the problematic code 
can be pinpointed or such that a patch is provided.

* Perform test builds and run the test suite (I assume that libtiff has 
one now?) after every commit to make sure that the commit did not break 
anything - and if it did then to either fix the problem myself, return 
to the patch developer for a fix, or to back out the patch.

What I cannot do is:

* Maintain same-day responsiveness all of the time.

* Perform a security audit.

* Spend vast amounts of time developing features, redesigning code, or 
fixing bugs that would either require too much time to fix or that are 
beyond my ability to fix.

What I would require in return is:

* Regular and frequent releases.  (And what I mean by that is 
approximately once per month whenever there has been any non-trivial 
amount of code changes committed.)  If this cannot be done due to other 
maintainer time constraints, then I am willing to assist in the releases 
to whatever degree is necessary.

Thanks,

Lee.