httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guenter Knauf <>
Subject Re: vote on concept of ServerTokens Off
Date Wed, 02 Sep 2009 11:35:57 GMT
William A. Rowe, Jr. schrieb:
> Jim Jagielski wrote:
>> Lars Eilebrecht wrote:
>>> According to Jeff:
>>>> A lot of opinions were offered back in August.  Some were negative but
>>>> I don't see anything that looks like a veto.
>>> I voted -1 at that time which is a veto.
>>> My opinion hasn't changed and I still think that it is a very
>>> stupid idea to add a "feature" that allows our users to do
>>> something which is stupid and absurd.
>>> *shrug* but as everyone seems to think that this is a good idea,
>>> feel free to ignore my veto.
>> A Veto is a Veto. If you feel strongly enough about it, then
>> it cannot be, and should not be, ignored.
> Lars,
> yours is the last veto standing for ServerTokens Off.  What say you?
> (Your veto would appear to imply a veto of any ServerTokens Set syntax).

If we would vote now, I would vote against. It makes no sense at all,
and folks who believe that hiding ServerTokens would make their server
more secure or relax the requirement to update for security bugfixes are
complete idiots who have never looked into their server logs.
I see tons of attacks on my Apache servers where scripts check for each
and every IIS exploit, so certainly those exploit scripts dont care at
all for what the server claims to be; also if a script wants to exploit
an APR bug then it cant rely on Apache ServerTokens since they dont tell
about APR version, and 2.2.x can run with a bunch of different 1.2.x and
1.3.x APR versions.

Also, I think we have some new folks here who also might want to vote,
and we should probably vote again?

Finally, I would even like to suggest something opposite: let the
user/admin add a configurable ServerToken with something like
AddServerToken "String"; I have already years ago hacked such a module
which is very useful in load balance environments in order to see which
server actually served the request.


View raw message