Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)

2010-10-21 Thread Lars Eilebrecht
Jim Jagielski wrote:

> ++1.
> 
> On Oct 19, 2010, at 3:28 PM, Roy T. Fielding wrote:
> 
> > IMO, removing Limit and LimitExcept would require a bump to httpd 3.x,
> > since it would break almost all existing configs and introduce security
> > holes if the installer is not prepared to rewrite them.
> > 
> > Deprecating Limit and LimitExcept can be done in 2.4.x, which means
> > keeping their functionality intact and warning at startup that the
> > feature is less good than the new directives.
> > 
> > Roy

Big +1 


cheers
-- 
Lars Eilebrecht
l...@eilebrecht.net


RE: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)

2010-10-21 Thread Plüm, Rüdiger, VF-Group
 

> -Original Message-
> From: Jim Jagielski 
> Sent: Donnerstag, 21. Oktober 2010 17:22
> To: dev@httpd.apache.org
> Subject: Re: Removing Limit and LimitExcept (was: svn commit: 
> r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
> 
> All this debate makes me wonder how many people here still
> *run* and *administer* web sites... How about putting yourself
> in the shoes of the sys admin before willy-nilly recrafting
> configs.
> 

+1. I am one of them :-)

Regards

Rüdiger


Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)

2010-10-21 Thread Jim Jagielski
All this debate makes me wonder how many people here still
*run* and *administer* web sites... How about putting yourself
in the shoes of the sys admin before willy-nilly recrafting
configs.


Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)

2010-10-21 Thread Jim Jagielski
++1.

On Oct 19, 2010, at 3:28 PM, Roy T. Fielding wrote:

> IMO, removing Limit and LimitExcept would require a bump to httpd 3.x,
> since it would break almost all existing configs and introduce security
> holes if the installer is not prepared to rewrite them.
> 
> Deprecating Limit and LimitExcept can be done in 2.4.x, which means
> keeping their functionality intact and warning at startup that the
> feature is less good than the new directives.
> 
> Roy
> 



RE: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)

2010-10-20 Thread Plüm, Rüdiger, VF-Group
 

> -Original Message-
> From: Stefan Fritsch 
> Sent: Dienstag, 19. Oktober 2010 22:33
> To: dev@httpd.apache.org
> Subject: Re: Removing Limit and LimitExcept (was: svn commit: 
> r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
> 
> On Tuesday 19 October 2010, Roy T. Fielding wrote:
> > On Oct 19, 2010, at 12:46 PM, Stefan Fritsch wrote:
> > > On Tuesday 19 October 2010, Roy T. Fielding wrote:
> > >> IMO, removing Limit and LimitExcept would require a bump to
> > >> httpd 3.x, since it would break almost all existing configs and
> > >> introduce security holes if the installer is not prepared to
> > >> rewrite them.
> > > 
> > > If the user is not prepared to change the config, httpd will not
> > > start. The user would need to comment out the Limit/LimitExcept
> > > lines, but in this case it would be absolutely obvious that he
> > > breaks his auth config.
> > > 
> > > And keeping Limit/LimitExcept is bad for security, too, because
> > > it has such insane behaviour. See
> > > 
> > > https://issues.apache.org/bugzilla/show_bug.cgi?id=47019
> > > https://issues.apache.org/bugzilla/show_bug.cgi?id=25057
> > > https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
> > 
> > Then fix the insane behavior.
> 
> I don't think that's an option. Changing the behaviour of Limit will 
> surely break some users' auth configs in subtle ways, which is much 
> worse than a clean break.

The question is how it breaks users auth configs. If it results in more
restrictive behaviour I guess this would be acceptable.

> 
> > >> Deprecating Limit and LimitExcept can be done in 2.4.x, which
> > >> means keeping their functionality intact and warning at startup
> > >> that the feature is less good than the new directives.
> > > 
> > > If we just add a warning, I fear that many users will still use
> > > it even in new installations, because there are so many outdated
> > > howtos around.
> > 
> > Of course they will still use it.  If you want to mandate config
> > changes, then release it as httpd 3.x.  Keeling over a website when
> > they perform a *minor* version upgrade is foolish.  Version numbers
> > are cheap.
> 
> I disagree and think that the change is small enough for 2.2->2.4.

There are a lot of AAA changes between 2.2 and 2.4, but we tried to provide
the users with the option to keep the old syntax in their config 
e.g. via mod_access_compat.
So I do not think that removing Limit between 2.2 and 2.4 without deprecating
it before is a good idea.
The annoying warning at the start gives users a chance to adjust their config
over time. If they don't do that until 2.6 or 3.0, then it is their own fault.

Regards

Rüdiger



Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)

2010-10-19 Thread Stefan Fritsch
On Tuesday 19 October 2010, Roy T. Fielding wrote:
> On Oct 19, 2010, at 12:46 PM, Stefan Fritsch wrote:
> > On Tuesday 19 October 2010, Roy T. Fielding wrote:
> >> IMO, removing Limit and LimitExcept would require a bump to
> >> httpd 3.x, since it would break almost all existing configs and
> >> introduce security holes if the installer is not prepared to
> >> rewrite them.
> > 
> > If the user is not prepared to change the config, httpd will not
> > start. The user would need to comment out the Limit/LimitExcept
> > lines, but in this case it would be absolutely obvious that he
> > breaks his auth config.
> > 
> > And keeping Limit/LimitExcept is bad for security, too, because
> > it has such insane behaviour. See
> > 
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=47019
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=25057
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
> 
> Then fix the insane behavior.

I don't think that's an option. Changing the behaviour of Limit will 
surely break some users' auth configs in subtle ways, which is much 
worse than a clean break.

> >> Deprecating Limit and LimitExcept can be done in 2.4.x, which
> >> means keeping their functionality intact and warning at startup
> >> that the feature is less good than the new directives.
> > 
> > If we just add a warning, I fear that many users will still use
> > it even in new installations, because there are so many outdated
> > howtos around.
> 
> Of course they will still use it.  If you want to mandate config
> changes, then release it as httpd 3.x.  Keeling over a website when
> they perform a *minor* version upgrade is foolish.  Version numbers
> are cheap.

I disagree and think that the change is small enough for 2.2->2.4.


Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)

2010-10-19 Thread Roy T. Fielding
On Oct 19, 2010, at 12:46 PM, Stefan Fritsch wrote:

> On Tuesday 19 October 2010, Roy T. Fielding wrote:
>> IMO, removing Limit and LimitExcept would require a bump to httpd
>> 3.x, since it would break almost all existing configs and
>> introduce security holes if the installer is not prepared to
>> rewrite them.
> 
> If the user is not prepared to change the config, httpd will not 
> start. The user would need to comment out the Limit/LimitExcept lines, 
> but in this case it would be absolutely obvious that he breaks his 
> auth config.
> 
> And keeping Limit/LimitExcept is bad for security, too, because it has 
> such insane behaviour. See
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=47019
> https://issues.apache.org/bugzilla/show_bug.cgi?id=25057
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49927

Then fix the insane behavior.

>> Deprecating Limit and LimitExcept can be done in 2.4.x, which means
>> keeping their functionality intact and warning at startup that the
>> feature is less good than the new directives.
> 
> If we just add a warning, I fear that many users will still use it 
> even in new installations, because there are so many outdated howtos 
> around.

Of course they will still use it.  If you want to mandate config
changes, then release it as httpd 3.x.  Keeling over a website when
they perform a *minor* version upgrade is foolish.  Version numbers
are cheap.

Roy


Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)

2010-10-19 Thread Stefan Fritsch
On Tuesday 19 October 2010, Roy T. Fielding wrote:
> IMO, removing Limit and LimitExcept would require a bump to httpd
> 3.x, since it would break almost all existing configs and
> introduce security holes if the installer is not prepared to
> rewrite them.

If the user is not prepared to change the config, httpd will not 
start. The user would need to comment out the Limit/LimitExcept lines, 
but in this case it would be absolutely obvious that he breaks his 
auth config.

And keeping Limit/LimitExcept is bad for security, too, because it has 
such insane behaviour. See

https://issues.apache.org/bugzilla/show_bug.cgi?id=47019
https://issues.apache.org/bugzilla/show_bug.cgi?id=25057
https://issues.apache.org/bugzilla/show_bug.cgi?id=49927

> Deprecating Limit and LimitExcept can be done in 2.4.x, which means
> keeping their functionality intact and warning at startup that the
> feature is less good than the new directives.

If we just add a warning, I fear that many users will still use it 
even in new installations, because there are so many outdated howtos 
around.


Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)

2010-10-19 Thread Roy T. Fielding
IMO, removing Limit and LimitExcept would require a bump to httpd 3.x,
since it would break almost all existing configs and introduce security
holes if the installer is not prepared to rewrite them.

Deprecating Limit and LimitExcept can be done in 2.4.x, which means
keeping their functionality intact and warning at startup that the
feature is less good than the new directives.

Roy