Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45DBB598.9020308@hanik.com>
Date: Tue, 20 Feb 2007 19:59:36 -0700
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Proposed new security pages
References: <45D52636.5000904@apache.org>
 <45DB7D63.7010901@hanik.com>	 <db94f1a0702201506l3a37430etc9c491df4801d1b6@mail.gmail.com>
	 <45DB98B2.7060504@hanik.com>
 <db94f1a0702201706k3d2ab4bahe3763bca19c413d6@mail.gmail.com>
 <45DBAB12.7000107@hanik.com>
In-Reply-To: <45DBAB12.7000107@hanik.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Filip Hanik - Dev Lists wrote:
> Yoav Shapira wrote:
>> Hi,
>>
>> On 2/20/07, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>>> The consequence of this is that you are "advertising" a security
>>> vulnerability to the world, and you are leaving your users with either
>>> continue running a stable version that everyone knows how to exploit or
>>> to upgrade to a non stable version.
>>>
>>> Doesn't sound like a fair choice, does it?
>>
>> The first, and default choice for security-conscious users, is to
>> apply the patch directly from SVN without even waiting for a release.
>> This follows the practice httpd has been following for many years, and
>> they document it well: see for example
>> http://www.apacheweek.com/issues/04-06-11 .
> yes, I can see a few folks doing this. But I believe most folks still 
> get the updated binaries from their distribution source.
> for example, RedHat will apply the actual patch and rebuild for their 
> distro, others will do the same.
>
>>
>> If someone is security-conscious, they should look at the SVN details
>> that will be announced when we publish a vulnerability, and see for
>> themselves whether they want to update or not.  If they do want to
>> update, they'll do so immediately right from the source, and waiting
>> for us to release, much less waiting for us to vote on a release, is
>> spurious.
> you assume that companies know how to "patch" a release, build etc.
> some do, some don't. Some that do, still prefer to get a binary.
>>
>> In general, we can't assume the release following a security
>> vulnerability announcement, x.y.(z+1) in your example, will be stable
>> for a long long time, unless someone wants to do a release not from
>> the trunk, but from the tag of the previous stable release.  That
>> someone, e.g. you if you're interested, is welcome to do that work.
>> But I think it's a waste of time because of the above source update
>> option, and therefore shouldn't be our mandated practice.
>>
>> Also one other note: our putting a security vulnerability notice is
>> not likely to be the first publication of such notice.  In most cases,
>> the original person or entity who discovered the vulnerability will
>> report it to such bodies as CVE, which are watched by a lot more
>> people (good and bad) than the Tomcat mailing lists.
> really, I was under the impression that most bodies that report a 
> security issue,
> will not publish until you OK them to do so.
> For example, the security problem in the JDK, was reported over a year 
> before Sun actually released the fix.
> First when Sun had a JDK version available, was the vulnerability 
> released. We're not talking weeks in this particular case, rather months.
> And I would assume that most reporting bodies follow the same 
> practices. Am I wrong?
and with all this crap said, I'm ok either way. Not trying to convince 
anyone, I just thought that we should provide our users with the same 
"delay"-courtesy that we would expect a reporting body to provide for us

Filip

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org