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: <45DBAB12.7000107@hanik.com>
Date: Tue, 20 Feb 2007 19:14:42 -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>
In-Reply-To: <db94f1a0702201706k3d2ab4bahe3763bca19c413d6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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?

Filip

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