You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/08/30 08:48:39 UTC
authn/authz split
Since no one had any feedback to the earlier posts about splitting
the auth modules into authn/authz, I decided to just call it authn
(old auth) and authz (what Dirk called access).
http://www.apache.org/~jerenkrantz/new-aaa/aaa-authn-authz-split.tar.gz
http://www.apache.org/~jerenkrantz/new-aaa/split/ (expanded)
This is an extension over Dirk's aaa.tar.gz that he posted. It
does *not* add the provider API.
Notes:
- apr_lib.h isn't where apr_password_validate is, it's apr_md5.h.
- renamed mod_access* to mod_authz*
- mod_access.c->mod_authz_default.c
- mod_auth.c->mod_auth_basic.c
- removed all internal prefixes on the config_recs
- style cleanup
- AuthUserFile will be a bit wonky until mod_auth_basic is refactored with
provider support.
My plan is to commit this tomorrow AM and then add in the provider
support shortly thereafter. Any new files will be created from
scratch rather than try to keep revision history. When we get
done with this, the code won't look anything like what it was before.
Any objections?
I imagine auth may be a little wonky until this settles down, but
once it settles down, we can ensure we're backwards-compat with the
old aaa system. No one other than Aaron and myself seem interested
in calling this 2.1, so we stay at 2.0 with this and potentially not
having directive back-compat if it doesn't shake out. -- justin
Re: authn/authz split
Posted by "John K. Sterling" <jo...@sterls.com>.
>-- Original Message --
>Reply-To: dev@httpd.apache.org
>Date: Fri, 30 Aug 2002 00:49:14 -0700
>From: Aaron Bannert <aa...@clove.org>
>To: dev@httpd.apache.org
>Subject: Re: authn/authz split
>Do you think this new feature is well-defined enough to warrant
>a new revision number? I'd like to see us start burning up new rev
>numbers for things like this, to make it obvious that we are
>actually adding new features (that could use some testing/usage,
>and might be useful to some users).
As I stated before, I agree with you. I think changes like this should
trigger minor version bumps.
sterling
Re: authn/authz split
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Aug 29, 2002 at 11:48:39PM -0700, Justin Erenkrantz wrote:
> I imagine auth may be a little wonky until this settles down, but
> once it settles down, we can ensure we're backwards-compat with the
> old aaa system. No one other than Aaron and myself seem interested
> in calling this 2.1, so we stay at 2.0 with this and potentially not
> having directive back-compat if it doesn't shake out. -- justin
Do you think this new feature is well-defined enough to warrant
a new revision number? I'd like to see us start burning up new rev
numbers for things like this, to make it obvious that we are
actually adding new features (that could use some testing/usage,
and might be useful to some users).
-aaron
Re: what's the hubbub? (was: Re: 2.0/2.1 split)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:28 PM 8/30/2002, Marc Slemko wrote:
>On Fri, 30 Aug 2002, Ian Holsman wrote:
>
> > exactly,
> > this talk of 2.1/branching etc is very premature.
> > if you think your going to destablize the tree, then do your changes on
> > a copy of the file.. and when your done just overwrite the old one.
>
>In preference to doing that, just create a temporary branch for
>those changes, develop and stabilize them on the branch, then merge
>them back into the main tree when ready. Sure, some problems won't
>be found until they are merged back but this does allow interested
>developers to work together and test on that branch.
+1 on this alternative for proceeding with experiments, until they are
quite stable.
>Note that this requires either only branching the files you are
>working with and hoping that is all you have to change, or merging
>all other changes in other files into your branch as you go so the code
>you are working with is up to date with the head. Neither are likely
>to be big time sinks if the changes are reasonably isolated.
Right. No huge trees just to work on small side-projects like filters,
etc. When they are ready to be merged back, we see if we can do
that without changing the API. When we have viable code that will
break all of the module author's assumptions, then we have the
instant justification for the 2.1 bump.
Bill
Re: what's the hubbub? (was: Re: 2.0/2.1 split)
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Aug 30, 2002 at 02:35:59PM -0700, Ian Holsman wrote:
> EXACTLY.
> branch your code, make it work, merge it back.
> rinse repeat.
> what could be simpler than this ?
> as long as your merge is done quickly (1-2 weeks) and is well-defined
> you should be good to go.
Um, in this case, the code works. We just need to merge it in.
The point is that the new code would break things that people
may expect to work.
The biggest problem is going to be with the authn/authz split
requiring new directives for authoritative access. Previously,
AuthDBMAuthoritative would make dbms authoritative for both authn
and authz - since that is split into *two* modules (and one
directive can't be parsed for multiple modules it seems), then
we're stuck. My rewrite requires switching to AuthnDBMAuthortiative
and AuthzDBMAuthoritative, respectively. -- justin
Re: what's the hubbub? (was: Re: 2.0/2.1 split)
Posted by Ian Holsman <ia...@apache.org>.
Marc Slemko wrote:
> On Fri, 30 Aug 2002, Ian Holsman wrote:
>
>
>>exactly,
>>this talk of 2.1/branching etc is very premature.
>>if you think your going to destablize the tree, then do your changes on
>>a copy of the file.. and when your done just overwrite the old one.
>
>
> In preference to doing that, just create a temporary branch for
> those changes, develop and stabilize them on the branch, then merge
> them back into the main tree when ready. Sure, some problems won't
> be found until they are merged back but this does allow interested
> developers to work together and test on that branch.
>
> Note that this requires either only branching the files you are
> working with and hoping that is all you have to change, or merging
> all other changes in other files into your branch as you go so the code
> you are working with is up to date with the head. Neither are likely
> to be big time sinks if the changes are reasonably isolated.
>
EXACTLY.
branch your code, make it work, merge it back.
rinse repeat.
what could be simpler than this ?
as long as your merge is done quickly (1-2 weeks) and is well-defined
you should be good to go.
Re: what's the hubbub? (was: Re: 2.0/2.1 split)
Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 30 Aug 2002, Ian Holsman wrote:
> this talk of 2.1/branching etc is very premature.
> what we need most is a stable tree for a couple of months not spliting
> out to a 2.1 tree
Agreed.
--Cliff
Re: what's the hubbub? (was: Re: 2.0/2.1 split)
Posted by Marc Slemko <ma...@znep.com>.
On Fri, 30 Aug 2002, Ian Holsman wrote:
> exactly,
> this talk of 2.1/branching etc is very premature.
> if you think your going to destablize the tree, then do your changes on
> a copy of the file.. and when your done just overwrite the old one.
In preference to doing that, just create a temporary branch for
those changes, develop and stabilize them on the branch, then merge
them back into the main tree when ready. Sure, some problems won't
be found until they are merged back but this does allow interested
developers to work together and test on that branch.
Note that this requires either only branching the files you are
working with and hoping that is all you have to change, or merging
all other changes in other files into your branch as you go so the code
you are working with is up to date with the head. Neither are likely
to be big time sinks if the changes are reasonably isolated.
Re: what's the hubbub? (was: Re: 2.0/2.1 split)
Posted by Ian Holsman <ia...@apache.org>.
Greg Stein wrote:
> On Fri, Aug 30, 2002 at 11:00:49AM -0700, Brian Pane wrote:
>
>>Justin Erenkrantz wrote:
>>...
>>
>>>I honestly don't care where this ends up. It just needs to get
>>>in to our tree somewhere. The aaa code is broken. It needs to
>>>be fixed (and I believe the patches we already have start the
>>>process). 2.0, 2.1, 3.0, 1.4 - whatever. I'm perfectly happy
>>>to break backwards-compatibility. -- justin
>>
>>I wouldn't object to breaking aaa backward compatibility in 2.0,
>>if it eliminates (for now) the need to start 2.1.
>
>
> Hey... I don't believe it is going to break backwards compat [in a big way].
> I'm not sure what the fuss is all about. Since it won't break compat, then
> it doesn't need a 2.1 bump.
>
> I think in the end, there will be these minor compat problems:
>
> * some LoadModule lines will need to go away; some added
>
> [ and the failure mode here makes this painless; it will be very obvious
> that you need to toss a LoadModule when Apache says it can't find it.
> and that you need to load another when it doesn't understand a directive
> that you had in the file. ]
>
> * an undocumented feature of AuthUserFile and AuthGroupFile will go away. it
> is unknown how the hell they worked to begin with.
>
>
> I believe that is it. Justin: what else do you think will change from a user
> standpoint?
>
> And note that the API isn't changing here, either. Justin is adding APIs for
> people, but no changes.
exactly,
this talk of 2.1/branching etc is very premature.
if you think your going to destablize the tree, then do your changes on
a copy of the file.. and when your done just overwrite the old one.
I'm thinking a in-progress directory should be created for these kind of
things, simliar to the experimental mpm tree.
what we need most is a stable tree for a couple of months not spliting
out to a 2.1 tree
>
> Cheers,
> -g
>
what's the hubbub? (was: Re: 2.0/2.1 split)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 30, 2002 at 11:00:49AM -0700, Brian Pane wrote:
> Justin Erenkrantz wrote:
>...
> >I honestly don't care where this ends up. It just needs to get
> >in to our tree somewhere. The aaa code is broken. It needs to
> >be fixed (and I believe the patches we already have start the
> >process). 2.0, 2.1, 3.0, 1.4 - whatever. I'm perfectly happy
> >to break backwards-compatibility. -- justin
>
> I wouldn't object to breaking aaa backward compatibility in 2.0,
> if it eliminates (for now) the need to start 2.1.
Hey... I don't believe it is going to break backwards compat [in a big way].
I'm not sure what the fuss is all about. Since it won't break compat, then
it doesn't need a 2.1 bump.
I think in the end, there will be these minor compat problems:
* some LoadModule lines will need to go away; some added
[ and the failure mode here makes this painless; it will be very obvious
that you need to toss a LoadModule when Apache says it can't find it.
and that you need to load another when it doesn't understand a directive
that you had in the file. ]
* an undocumented feature of AuthUserFile and AuthGroupFile will go away. it
is unknown how the hell they worked to begin with.
I believe that is it. Justin: what else do you think will change from a user
standpoint?
And note that the API isn't changing here, either. Justin is adding APIs for
people, but no changes.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: 2.0/2.1 split was Re: authn/authz split
Posted by Brian Pane <br...@cnet.com>.
Justin Erenkrantz wrote:
>On Fri, Aug 30, 2002 at 10:17:52AM -0700, Aaron Bannert wrote:
>
>
>>No, that's exactly the problem we have with 1.3 right now. There *are*
>>people who are willing to backport fixes and even features to the 1.3
>>tree, it's only a faction of the group here that *doesn't* want that to
>>happen. I see no reason to close any httpd source tree. If it's just one
>>person complaining that they don't want to backport their changes, then
>>they shouldn't do it. This is a volunteer organization, do only what you
>>want to do, but don't prevent anyone else from have the same abilities.
>>
>>
>
>Um. I refuse to get stranded in 2.1 if I'm the only sucker there.
>I don't want to spend *my* time forward-porting fixes because
>everyone else is still on 2.0. That's a ridiculous waste. I'd
>be spending all my time merging.
>
Yeah, that's my biggest concern about a 2.1 branch. I suspect
that most of the other things in the roadmap file may really
be 2.0 features, even though they're listed as 2.1 and 3.0.
Adding an event-loop MPM, for example, could be a 2.0 feature if
we can make it work without breaking the 2.0 architecture.
>I honestly don't care where this ends up. It just needs to get
>in to our tree somewhere. The aaa code is broken. It needs to
>be fixed (and I believe the patches we already have start the
>process). 2.0, 2.1, 3.0, 1.4 - whatever. I'm perfectly happy
>to break backwards-compatibility. -- justin
>
>
I wouldn't object to breaking aaa backward compatibility in 2.0,
if it eliminates (for now) the need to start 2.1.
Brian
Re: 2.0/2.1 split was Re: authn/authz split
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Aug 30, 2002 at 10:17:52AM -0700, Aaron Bannert wrote:
> No, that's exactly the problem we have with 1.3 right now. There *are*
> people who are willing to backport fixes and even features to the 1.3
> tree, it's only a faction of the group here that *doesn't* want that to
> happen. I see no reason to close any httpd source tree. If it's just one
> person complaining that they don't want to backport their changes, then
> they shouldn't do it. This is a volunteer organization, do only what you
> want to do, but don't prevent anyone else from have the same abilities.
Um. I refuse to get stranded in 2.1 if I'm the only sucker there.
I don't want to spend *my* time forward-porting fixes because
everyone else is still on 2.0. That's a ridiculous waste. I'd
be spending all my time merging.
You can't have it both ways - "enforce frequent branching" *and*
"don't require people to commit to the latest branch." That's
going to kill everyone off. Pick one.
I honestly don't care where this ends up. It just needs to get
in to our tree somewhere. The aaa code is broken. It needs to
be fixed (and I believe the patches we already have start the
process). 2.0, 2.1, 3.0, 1.4 - whatever. I'm perfectly happy
to break backwards-compatibility. -- justin
Re: 2.0/2.1 split was Re: authn/authz split
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Aug 30, 2002 at 08:43:33AM -0700, Justin Erenkrantz wrote:
> I dislike backporting things. I think we all need to be on the 'same
> version.' Heck, we have committers who refuse to use 2.0 ("it's not
> portable"). If we go to 2.1, then I want to see 2.0 closed for
> anything other than security fixes.
>
> I don't think we have enough of a community to continue active
> development on two separate (but similar) trees. I don't want to
> start 2.1 and still see everyone adding features to 2.0. -- justin
No, that's exactly the problem we have with 1.3 right now. There *are*
people who are willing to backport fixes and even features to the 1.3
tree, it's only a faction of the group here that *doesn't* want that to
happen. I see no reason to close any httpd source tree. If it's just one
person complaining that they don't want to backport their changes, then
they shouldn't do it. This is a volunteer organization, do only what you
want to do, but don't prevent anyone else from have the same abilities.
-aaron
Re: 2.0/2.1 split?
Posted by al...@foogod.com.
On Fri, Aug 30, 2002 at 11:10:27AM -0500, William A. Rowe, Jr. wrote:
> I don't think we have enough -user- community to continue development
> on any Apache 2.x. UNLESS we reconsider what we are doing wrong.
> Breaking our users on every bugfix/point release would be a good start.
> Seeing the successful completion of the PHP/Perl compatibility would
> be a good finish.
I have to throw my two cents in here. I completely agree with this.
Speaking as a system administrator and web administration consultant for quite
a few companies, I have to say that I do not currently, and will never, use 2.0
for more than trivial applications, until I feel that I can rely on its
(developmental) stability. I still reccomend to all of my clients that they
use 1.3, and I expect to continue to do this for quite a long time unless folks
here can resolve this issue adequately.
I cannot afford to use a server where any time I try to upgrade it for a bugfix
I might have to rewrite my configuration files, tweak all my add-on modules, or
otherwise spend potentially days figuring out what's changed and why my server
doesn't work the way it used to anymore, when all I wanted was a security fix.
I know that most new 2.0 releases aren't quite this drastic, but the problem is
that there's always the _possibility_ lurking there, and I can't afford to take
the gamble on the 40 or 50 servers I'm (directly or indirectly) responsible
for.
I don't really care (from a user perspective) whether there's a 2.1 or not. It
really doesn't matter. I don't care about all the nifty new features people
are wanting to add to the project, because they're all going into a product
which I'm not gonna be able to use, so they don't matter either. As far as I'm
concerned 2.0 doesn't even exist yet, and won't until this situation is fixed.
Until then, 1.3 is still the only Apache server there is.
I really hope this situation changes because I really would like to start using
2.0 more.
-alex
Re: 2.0/2.1 split was Re: authn/authz split
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Fri, 30 Aug 2002, Justin Erenkrantz wrote:
> I don't think we have enough of a community to continue active
> development on two separate (but similar) trees. I don't want to
> start 2.1 and still see everyone adding features to 2.0. -- justin
Why not do a tiny temporary branch just for those features; and you merge
that branch in once we're done. That branch would only need to touch a
fraction of the files - so the merge back in should not be too painful.
Dw
RE: 2.0/2.1 split?
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Friday, August 30, 2002 6:10 PM
> To: dev@httpd.apache.org
> Subject: Re: 2.0/2.1 split?
>
> I don't think we have enough -user- community to continue development
> on any Apache 2.x. UNLESS we reconsider what we are doing wrong.
Good point!
Well, can you or someone else _actually_ say what is (from its own point
of view) the major obstacle for making a 2.0 final? Lets put the cards
on the table or the story will eventually end up like a Mozilla.
Personally I'm seeing the entire project more and more like a
intellectual masturbation. Just look at the last month postings, that
almost ended in a 'Gunfight at OK coral'.
Seems that everyone is killing his brains out, but we still have only
6500 upgrades from 1.3.x. One of them is the guy from Germany that is
running 2.0.18 for more than a year.
MT.
Re: 2.0/2.1 split?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:43 AM 8/30/2002, Justin Erenkrantz wrote:
>On Fri, Aug 30, 2002 at 09:54:45AM -0500, William A. Rowe, Jr. wrote:
> > It's time for a 2.1-dev tree, if we want to be playing with new ideas,
> guys.
> > If they test out clean and don't break compatibility [in any significant
> > way]
> > then they can be backported to 2.0.
>
>I dislike backporting things. I think we all need to be on the 'same
>version.' Heck, we have committers who refuse to use 2.0 ("it's not
>portable"). If we go to 2.1, then I want to see 2.0 closed for
>anything other than security fixes.
or -bug- fixes, surely. Some can be fixed trivially. Some need major
restructuring. Those trivial fixes need to continually go in. Why do you
suppose -most- of our users upgraded their 1.3.x -> 1.3.26, instead of
2.0.39?
Apache 1.3.26 Upgrade(Downgrade) Report
https://secure1.securityspace.com/s_survey/data/man.200207/srvch.html?server=Apache&revision=Apache%2F1.3.26
Apache 2.0.39 Upgrade(Downgrade) Report
https://secure1.securityspace.com/s_survey/data/man.200207/srvch.html?server=Apache&revision=Apache%2F2.0.39
To summarize, in July;
1,553,930 Apache 1.3.x web sites upgraded to a secure version.
1,547,430 Of those sites upgraded to 1.3.26
6,500 Of those sites upgraded to 2.0.39
Less than 1/2 of 1%.
>I don't think we have enough of a community to continue active
>development on two separate (but similar) trees. I don't want to
>start 2.1 and still see everyone adding features to 2.0. -- justin
I don't think we have enough -user- community to continue development
on any Apache 2.x. UNLESS we reconsider what we are doing wrong.
Breaking our users on every bugfix/point release would be a good start.
Seeing the successful completion of the PHP/Perl compatibility would
be a good finish.
Bill
2.0/2.1 split was Re: authn/authz split
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Aug 30, 2002 at 09:54:45AM -0500, William A. Rowe, Jr. wrote:
> It's time for a 2.1-dev tree, if we want to be playing with new ideas, guys.
> If they test out clean and don't break compatibility [in any significant
> way]
> then they can be backported to 2.0.
I dislike backporting things. I think we all need to be on the 'same
version.' Heck, we have committers who refuse to use 2.0 ("it's not
portable"). If we go to 2.1, then I want to see 2.0 closed for
anything other than security fixes.
I don't think we have enough of a community to continue active
development on two separate (but similar) trees. I don't want to
start 2.1 and still see everyone adding features to 2.0. -- justin
Re: authn/authz split
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:09 AM 8/30/2002, rbb@apache.org wrote:
>On Fri, 30 Aug 2002, William A. Rowe, Jr. wrote:
>
> > ... Now that it's GA, we should really be treating the 2.0 tree
> > with the same respect and caution we use on the 1.3 tree.
> >
> > It's time for a 2.1-dev tree, if we want to be playing with new ideas,
> guys.
> > If they test out clean and don't break compatibility [in any
> significant way]
> > then they can be backported to 2.0.
>
>The 1.3 tree didn't become "stable" for many releases after the initial
>release. We definately didn't treat it with the respect and caution that
>we now use until well after the first alphas for 2.0 came out, which was
>years after the first 1.3 release.
Um, I'd like to disagree with you there. I was told often in early 2000 [prior
to any 2.0 alpha] that "we should save fixing that for 2.0". Or I would be
questioned, "is that worth a major mmn bump?!?" The answer was often
no, not for 1.3, and we will deal with it in 2.0.
Don't get me wrong... 2.0 has some bugs to fix. But we have a dozen coders
with great [new] ideas that need a 'playground' to pursue those ideas. If they
prove stable and don't break the api, why not backport to 2.0 after the ideas
are proven.
We have enough users who 'played' in the 2.0 alpha tree. I'm certain some
will be excited enough to stay on the bleeding edge of 2.1.
In the meantime, we've delievered a terrific server, 2.0, that still has a few
wrinkles to iron out. If we keep breaking the 2.0 tree for "neat new features"
while ironing out those bugs, users will continue to ask when 2.0 will become
stable. And the answer will be "not in your lifetime."
We took -years- to go to 2.0, because 2.0 is such a massive restructuring.
There is no reason that new features in 2.1 won't be in user's hands by
ApacheCon Las Vegas [at least in beta form.] Then a 2.2, as long as folks
want to incrementally improve the server, after we call 2.1 golden.
It wasn't until 1.3.14 that we quit flipping around the API.
19980527 MMN bump for the 1.3.0 initial release
19980713 MMN bump for 1.3.1 release
19980917 MMN bump for 1.3.2 release
19990108 MMN bump for 1.3.4 release
19990320 MMN bump for 1.3.5 release
So your statement doesn't hold up that much water, we've gone from the
2.0.35 GA to 2.0.40, bumping several times. But we should be about ready
to quit it. Many, many 1.3.6 sources build against 1.3.27-dev. Many are
even binary compatible. Somewhere along the way, we quit mucking with
the API. Maybe we aught to have quit sooner :-)
All this leads to the inevitable question, "when 3.0?" and that will only be
answered when a few folks put fingers to keys and start to prototype some
radically different async code. The faux-async models can all be supported
in the 2.x line. It isn't until we start thread-jumping within a single
request
that this server architecture just can't cut it anymore.
So... it's time to stop cutting off our developers and start the 2.1 branch or
separate tree. Let everyone scratch their itches! I'm happy to see a branch
(leaving 2.0 as head, so nobody following older checkout instructions to grab
the now-current version have a 'surprize' in store.) I'd also be happy with
a new httpd-2.1 tree. Doesn't matter one way or the other.
Bill
Re: authn/authz split
Posted by rb...@apache.org.
On Fri, 30 Aug 2002, William A. Rowe, Jr. wrote:
> At 01:48 AM 8/30/2002, Justin Erenkrantz wrote:
> >Since no one had any feedback to the earlier posts about splitting
> >the auth modules into authn/authz, I decided to just call it authn
> >(old auth) and authz (what Dirk called access).
> >
> >http://www.apache.org/~jerenkrantz/new-aaa/aaa-authn-authz-split.tar.gz
> >http://www.apache.org/~jerenkrantz/new-aaa/split/ (expanded)
> >
> >This is an extension over Dirk's aaa.tar.gz that he posted. It
> >does *not* add the provider API.
> >
> >Notes:
> >- apr_lib.h isn't where apr_password_validate is, it's apr_md5.h.
> >- renamed mod_access* to mod_authz*
> >- mod_access.c->mod_authz_default.c
> >- mod_auth.c->mod_auth_basic.c
> >- removed all internal prefixes on the config_recs
> >- style cleanup
> >- AuthUserFile will be a bit wonky until mod_auth_basic is refactored with
> > provider support.
> >
> >My plan is to commit this tomorrow AM and then add in the provider
> >support shortly thereafter. Any new files will be created from
> >scratch rather than try to keep revision history. When we get
> >done with this, the code won't look anything like what it was before.
> >
> >Any objections?
>
> Only one veto here. If it destabilizes the server, and we cannot react
> to new security incidents, that's not acceptable. Your next comment...
>
> >I imagine auth may be a little wonky until this settles down, but
> >once it settles down, we can ensure we're backwards-compat with the
> >old aaa system. No one other than Aaron and myself seem interested
> >in calling this 2.1, so we stay at 2.0 with this and potentially not
> >having directive back-compat if it doesn't shake out. -- justin
>
> ...scares me. Now that it's GA, we should really be treating the 2.0 tree
> with the same respect and caution we use on the 1.3 tree.
>
> It's time for a 2.1-dev tree, if we want to be playing with new ideas, guys.
> If they test out clean and don't break compatibility [in any significant way]
> then they can be backported to 2.0.
The 1.3 tree didn't become "stable" for many releases after the initial
release. We definately didn't treat it with the respect and caution that
we now use until well after the first alphas for 2.0 came out, which was
years after the first 1.3 release.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: authn/authz split
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:48 AM 8/30/2002, Justin Erenkrantz wrote:
>Since no one had any feedback to the earlier posts about splitting
>the auth modules into authn/authz, I decided to just call it authn
>(old auth) and authz (what Dirk called access).
>
>http://www.apache.org/~jerenkrantz/new-aaa/aaa-authn-authz-split.tar.gz
>http://www.apache.org/~jerenkrantz/new-aaa/split/ (expanded)
>
>This is an extension over Dirk's aaa.tar.gz that he posted. It
>does *not* add the provider API.
>
>Notes:
>- apr_lib.h isn't where apr_password_validate is, it's apr_md5.h.
>- renamed mod_access* to mod_authz*
>- mod_access.c->mod_authz_default.c
>- mod_auth.c->mod_auth_basic.c
>- removed all internal prefixes on the config_recs
>- style cleanup
>- AuthUserFile will be a bit wonky until mod_auth_basic is refactored with
> provider support.
>
>My plan is to commit this tomorrow AM and then add in the provider
>support shortly thereafter. Any new files will be created from
>scratch rather than try to keep revision history. When we get
>done with this, the code won't look anything like what it was before.
>
>Any objections?
Only one veto here. If it destabilizes the server, and we cannot react
to new security incidents, that's not acceptable. Your next comment...
>I imagine auth may be a little wonky until this settles down, but
>once it settles down, we can ensure we're backwards-compat with the
>old aaa system. No one other than Aaron and myself seem interested
>in calling this 2.1, so we stay at 2.0 with this and potentially not
>having directive back-compat if it doesn't shake out. -- justin
...scares me. Now that it's GA, we should really be treating the 2.0 tree
with the same respect and caution we use on the 1.3 tree.
It's time for a 2.1-dev tree, if we want to be playing with new ideas, guys.
If they test out clean and don't break compatibility [in any significant way]
then they can be backported to 2.0.
Bill