You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 2000/07/04 22:53:15 UTC
Re: hooks
Sam Magnuson wrote:
> All of this is fine if the abstraction of protocols is to give an easy way
> of plugging in an all new monolithic module that incorporates all the stuff
> for another protocol (ala the apache core stuff). If it is there to provide
> the ability to have a very generic framework and I can easily plug in
> different protocols and those different protocol modules can use some
> common modules to do certain aspects then it seems what exists isn't going
> to work well.
Catching up with this rather late, but I really can't see why you think
this. New protocol modules can call the hooks just like old protocols do
- how does that not work well?
And like Ryan said - give a real-world example of how this doesn't work,
and we'll figure out how to make it better.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: hooks
Posted by rb...@covalent.net.
> > I was mainly thinking of the MD5 stuff with regards to portability,
> > because some platforms have it and others don't. We actually took our
> > code from FreeBSD, so we know they have this function.
>
> I believe the result of that conversation was just to always use our
> functions rather than trying to rely on per-platform MD5 libraries.
Yes, but this doesn't reduce the need for portability here, and it doesn't
reduce the argument that not all platforms have an encryption/encoding
routine.
> > The other argument is that this is a bunch of VERY portable encryption
> > code. Anybody who is trying to write a secure piece of portable software
> > would most likely like to use some of these functions. Isn't this what
> > APR is supposed to provide? The ability to write very portable software
> > with one library. We can put all of these functions in lib/apr/encrypt or
> > lib/apr/enocde (may be more precise) and be able to enable/disable them at
> > compile time. I really think these are useful portable routines.
>
> MD5 and SHA1 are "hash" functions. Very far from encryption or even
> encoding. We should avoid calling them anything close to encryption because
> that would open a huge can of worms :-)
Considering that both the md5 and sha1 files refer to them encoding data
multiple times, I think we are safe calling them encoding functions.
> Both hash functions are inherently portable, which makes their placement in
> APR dubious.
The placement in APR isn't dubious. They are very useful portable
functions. These are also functions that we have needed, and used
extensively. I really don't see what the problem is as long as their
compilation can be turned off easily. It can, by adding a simple flag to
the configure stage.
> Given our move towards shifting some functionality over to lib/util, then I
> believe that is a good location for these generic, inherently-portable
> suites of functionality.
We don't even have lib/util yet. We have been talking about it for
months, but nothing has ever been done, so I don't see how we can say we
have made that move. Putting a new library in lib/util also implies that
this library will have it's own build system. We can not just put a bunch
of files into a lib subdirectory and tie it into Apache's build system.
> Correct. APR should be our portability-enabler rather than a kitchen sink of
> useful functions. Keeping a tight, clean focus on that will keep APR on
> track to being an excellent tool.
APR is a very focused project. It's goal is to provide a set of functions
to help make programs portable. This does not mean that all code that is
in APR must be inherently non-portable. It just means that all code in
APR must be portable.
> [ note: Subversion (subversion.tigris.org) has definitively selected APR as
> a base library. their first milestone is September, where we'll see a
> non-Apache application ship using APR. whee! ]
Sorry, they are too late. :-) I know of at least one closed source
application already using APR. No, I'm not the one writing it. I haven't
announced that it is being used or who is writing it, because the project
isn't finished. :-)
> Now if lib/util becomes "interesting" to package, then we can make that
> choice later. IMO, there are already too many "kitchen sink" libraries out
> there. Lets avoid that space. APR can be incredibly successful by simply
> offering portability to apps.
But offering a small set of encoding functions could be argued to provide
portability. Consider the trouble Apache had getting encoded passwords
into the Windows version. Not all platforms provide ANY scheme to
encrypt/encode data. This is a useful function, and it belongs in APR.
> > > Etc referred to stuff in ap and main: ap/ap_cache, ap/ap_hooks, and the
> > > main/util* stuff.
>
> What is the rule for moving something into lib/util? What is the rule for
> NOT moving it? I am unclear on this. Do we simply say anything that happened
> to have been named "util_*" gets moved? Why not mpm_common? It is a neat
> little set of common functions that an MPM might use. Is util_uri really a
> non-web-server thing that is destined for lib/util?
Things that are moved to lib/util, should be those functions that would be
useful to have outside of the webserver. If they only make sense inside
of Apache, then the function doesn't belong in lib/util. It belongs in
ap/. As far as the util_* functions, if we remove the reliance on the
request_rec and ap_log_error* from the few functions that require it, then
yes those functions become VERY useful outside of the webserver. Imagine
a small app wanting to make a web request or to parse a URI. Having
util_uri would go a long way to making that easier. Some of the util_*
files shouldn't be moved, they should be removed from the server
completely. For example, util_script. This file needs to start being
merged into mod_cgi[d], and the remaining parts need to be moved into
modules/common (a nonexistant directory, for functions needed by multiple
modules. This would always be compiled into the server).
> Meta-point here: if we're going to start creating directories for this and
> that, then *please* make sure that a directory has a well-defined meaning.
> Otherwise, it could create confusion when people think, "dang. where does
> that module live? in the utility directory? oh, wait, that is an HTTP
> utility, so it must be in the main directory. oops. but it applies to any
> networking protocol, so it must be in the netutil directory."
Of course. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: hooks
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jul 04, 2000 at 05:10:26PM -0700, rbb@covalent.net wrote:
> > > > If everybody is happy with lib/utils then I'll attempt to beat you to
> > > > it for the md5, sha1, base64, getpass, etc.
> > >
>
> > > I would still really like to see all of these files in APR. They all use
> > > APR types, and although the code is all common for all platforms, they are
> > > portability issues for most programs. By moving them into different
> > > directories within APR, we can enable and disable them at compile time.
> >
> > What portability issues? The ebcdic stuff is now in apr (ap_xlate, or so
> > I assume), and I can't think of any others.
>
> The EBCDIC stuff is still in ap_base64.c, but that is another issue.
>
> I was mainly thinking of the MD5 stuff with regards to portability,
> because some platforms have it and others don't. We actually took our
> code from FreeBSD, so we know they have this function.
I believe the result of that conversation was just to always use our
functions rather than trying to rely on per-platform MD5 libraries.
> The other argument is that this is a bunch of VERY portable encryption
> code. Anybody who is trying to write a secure piece of portable software
> would most likely like to use some of these functions. Isn't this what
> APR is supposed to provide? The ability to write very portable software
> with one library. We can put all of these functions in lib/apr/encrypt or
> lib/apr/enocde (may be more precise) and be able to enable/disable them at
> compile time. I really think these are useful portable routines.
MD5 and SHA1 are "hash" functions. Very far from encryption or even
encoding. We should avoid calling them anything close to encryption because
that would open a huge can of worms :-)
Both hash functions are inherently portable, which makes their placement in
APR dubious.
Given our move towards shifting some functionality over to lib/util, then I
believe that is a good location for these generic, inherently-portable
suites of functionality.
> > Last time I asked about
> > this, Greg was against moving them into apr and other-Bill was for it -
> > other than that nobody cared. I'm equally split on whether to put it in
> > apr or lib/utils.
Correct. APR should be our portability-enabler rather than a kitchen sink of
useful functions. Keeping a tight, clean focus on that will keep APR on
track to being an excellent tool.
[ note: Subversion (subversion.tigris.org) has definitively selected APR as
a base library. their first milestone is September, where we'll see a
non-Apache application ship using APR. whee! ]
Now if lib/util becomes "interesting" to package, then we can make that
choice later. IMO, there are already too many "kitchen sink" libraries out
there. Lets avoid that space. APR can be incredibly successful by simply
offering portability to apps.
>...
> > > Which things are included in the etc? I would like to be VERY careful
> > > about what we move out of APR, because some of the functions in the lib
> > > directory are portability issues, and not cruft for APR.
> >
> > Etc referred to stuff in ap and main: ap/ap_cache, ap/ap_hooks, and the
> > main/util* stuff.
What is the rule for moving something into lib/util? What is the rule for
NOT moving it? I am unclear on this. Do we simply say anything that happened
to have been named "util_*" gets moved? Why not mpm_common? It is a neat
little set of common functions that an MPM might use. Is util_uri really a
non-web-server thing that is destined for lib/util?
Meta-point here: if we're going to start creating directories for this and
that, then *please* make sure that a directory has a well-defined meaning.
Otherwise, it could create confusion when people think, "dang. where does
that module live? in the utility directory? oh, wait, that is an HTTP
utility, so it must be in the main directory. oops. but it applies to any
networking protocol, so it must be in the netutil directory."
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: hooks
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Thu, Jul 06, 2000 at 09:53:15AM -0400, Jeff Trawick wrote:
> > Date: Wed, 5 Jul 2000 13:12:21 -0700
> > From: "Life is hard, and then you die" <ro...@innovation.ch>
>
> > Btw., does anybody disagree with changing the update functions in
> > md5 and sha1 to ap_MD5Update_ascii(), ap_MD5Update_binary(),
> > ap_SHA1Update_ascii(), and ap_SHA1Update_binary()? I.e. to better
> > reflect which are ascii and which binary (the ascii forms first
> > translate the characters as necessary to ascii). And similarly
> > for ap_base64. Currently we have ap_SHA1Update() and
> > ap_SHA1Update_binary() in 1.3.
>
> A. MD5:
>
> Currently:
>
> single call to ap_MD5Init()
> optional single call to ap_MD5SetXlate()
> multiple calls to ap_MD5Update()
> single call to ap_MD5Final()
>
> Your proposal (I guess):
>
> single call to ap_MD5Init()
> multiple calls to either ap_MD5Update_ascii() or ap_MD5Update_binary()
> single call to ap_MD5Final()
Yes.
> 1) _ascii is a mis-nomer for this feature; we don't know or care what
> type of translation is performed (if it is done); since this is
> content, it could be anything
Agreed - I wasn't thinking too far. So _text would probably be better.
> 2) I like the current API better because once the app sets up the
> translation properly it doesn't have to have dual paths later
> (Hmmm... do I call ap_MD5Update_ascii() or ap_MD5Update_binary()?)
>
> You could get rid of ap_MD5SetXlate() and provide an additional
> parameter to ap_MD5Init() if you want to simplify it.
The problem with the current setup and with ap_MD5Init(ap_xlate,...) is that
they aren't mt-safe. The later could be made so if the ap_xlate is stored
as part of the context, not in a global variable as is done in
ap_SHA1InitEBCDIC. Passing the ap_xlate in _text provides for a little
more flexibility, but I honestly don't know if that's needed or useful.
> B. SHA1
>
> This is definitely hard-wired for EBCDIC currently. The API set could
> be changed to be more similar to the MD5 one, but you'll need to
> change more code in the utilities to be EBCDIC-aware. It is ugly
> either way, but until some app needs a different type of translation
> for SHA1, I think the code savings (and the related smaller amount of
> EBCDIC awareness in Apache) with the current API set is worth the
> ugliness. #ifdef EBCDIC is pretty ugly to me, and I are EBCDIC for at
> least part of the day.
This brings up a second point that I'm having problems with: if we have
ap_xlate, then why the heck do we have #ifdef CHARSET_EBCDIC everywhere?
We should just be able to pass an ap_xlate everywhere, and if that's
NULL then the ap_xlate_conv_buffer should be a no-op. I don't think that
extra function call and test is going to affect performance noticeably,
considering all the other code in the sha/md5/base64/etc functions.
> C. base64
>
> no real opinion... I don't have a notion of how much app-level code
> would get changed (and possibly uglified). You'll find out soon
> enough.
Basically same as above, i.e. supply _text and _binary versions. Since these
are not multipart operations we have to supply the ap_xlate to the _text.
The only problem is the pr2six table - not sure what to do about it. One
possibility would be to use a cache of pr2six tables, and compute them on
the fly if not in the cache.
Cheers,
Ronald
Re: hooks
Posted by Jeff Trawick <tr...@ibm.net>.
> Date: Wed, 5 Jul 2000 13:12:21 -0700
> From: "Life is hard, and then you die" <ro...@innovation.ch>
> Btw., does anybody disagree with changing the update functions in
> md5 and sha1 to ap_MD5Update_ascii(), ap_MD5Update_binary(),
> ap_SHA1Update_ascii(), and ap_SHA1Update_binary()? I.e. to better
> reflect which are ascii and which binary (the ascii forms first
> translate the characters as necessary to ascii). And similarly
> for ap_base64. Currently we have ap_SHA1Update() and
> ap_SHA1Update_binary() in 1.3.
A. MD5:
Currently:
single call to ap_MD5Init()
optional single call to ap_MD5SetXlate()
multiple calls to ap_MD5Update()
single call to ap_MD5Final()
Your proposal (I guess):
single call to ap_MD5Init()
multiple calls to either ap_MD5Update_ascii() or ap_MD5Update_binary()
single call to ap_MD5Final()
1) _ascii is a mis-nomer for this feature; we don't know or care what
type of translation is performed (if it is done); since this is
content, it could be anything
2) I like the current API better because once the app sets up the
translation properly it doesn't have to have dual paths later
(Hmmm... do I call ap_MD5Update_ascii() or ap_MD5Update_binary()?)
You could get rid of ap_MD5SetXlate() and provide an additional
parameter to ap_MD5Init() if you want to simplify it.
B. SHA1
This is definitely hard-wired for EBCDIC currently. The API set could
be changed to be more similar to the MD5 one, but you'll need to
change more code in the utilities to be EBCDIC-aware. It is ugly
either way, but until some app needs a different type of translation
for SHA1, I think the code savings (and the related smaller amount of
EBCDIC awareness in Apache) with the current API set is worth the
ugliness. #ifdef EBCDIC is pretty ugly to me, and I are EBCDIC for at
least part of the day.
C. base64
no real opinion... I don't have a notion of how much app-level code
would get changed (and possibly uglified). You'll find out soon
enough.
Best wishes,
Jeff
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: hooks
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Wed, Jul 05, 2000 at 02:06:23PM -0700, rbb@covalent.net wrote:
>
> > > Btw., does anybody disagree with changing the update functions in
> > > md5 and sha1 to ap_MD5Update_ascii(), ap_MD5Update_binary(),
> > > ap_SHA1Update_ascii(), and ap_SHA1Update_binary()? I.e. to better
> > > reflect which are ascii and which binary (the ascii forms first
> > > translate the characters as necessary to ascii). And similarly
> > > for ap_base64. Currently we have ap_SHA1Update() and
> > > ap_SHA1Update_binary() in 1.3.
> >
> > Euh... why not call it ap_MD5Update_xlate() and pass an xlate pointer? Seems
> > a bit better than hard-wiring to ascii/ebcdic and using just one of those
> > two charsets.
We could do that. But the conversion will always be <default-charset> ->
<ascii>. Hmm, wait, maybe it will be <local-charset> -> <ascii> in some
cases, in which case your suggestion would make sense. Umm, what's the
behaviour when writing headers? Oh, I think I see it: ap_hdrs_to_ascii
in main/util_charset.c. So it ends up being a fixed translation, at least
for Apache. OTOH if these are supposed to be generic libraries then
passing ap_xlate, while a little uglier for the rest of code, may be the
right thing.
I guess I'm not too happy with the current setup in which ap_MD5InitEBCDIC
is called once to setup the ap_xlate.
> Huh. The translation is already done. I was under the impression that we
> currently have two functions, ap_SHA1Update and ap_SHA1Update_binary. I
> thought the suggestion was to just change ap_SHA1Update to
> ap_SHA1Update_ascii.
Correct.
> The translation only makes sense if we are dealing
> with ascii data IMO, and that is setup before hand and is taken care of
> automagically. What am I missing?
Not sure if I understand you correctly. The point of the _ascii version
is to assume that the input data is text and translate it to ascii before
doing the update (actually, 8859_1 would be more precise). The point of
this is that when you're sticking a hash value or base64-encoded data
into the headers you first need to make sure the input to the hash or
base64 is ascii, because that's what the other side will assume.
base64_encode will also translate the result back, btw, because that's
also text.
Cheers,
Ronald
Re: hooks
Posted by rb...@covalent.net.
> > Btw., does anybody disagree with changing the update functions in
> > md5 and sha1 to ap_MD5Update_ascii(), ap_MD5Update_binary(),
> > ap_SHA1Update_ascii(), and ap_SHA1Update_binary()? I.e. to better
> > reflect which are ascii and which binary (the ascii forms first
> > translate the characters as necessary to ascii). And similarly
> > for ap_base64. Currently we have ap_SHA1Update() and
> > ap_SHA1Update_binary() in 1.3.
>
> Euh... why not call it ap_MD5Update_xlate() and pass an xlate pointer? Seems
> a bit better than hard-wiring to ascii/ebcdic and using just one of those
> two charsets.
Huh. The translation is already done. I was under the impression that we
currently have two functions, ap_SHA1Update and ap_SHA1Update_binary. I
thought the suggestion was to just change ap_SHA1Update to
ap_SHA1Update_ascii. The translation only makes sense if we are dealing
with ascii data IMO, and that is setup before hand and is taken care of
automagically. What am I missing?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: hooks
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jul 05, 2000 at 01:12:21PM -0700, Life is hard, and then you die wrote:
>...
> Btw., does anybody disagree with changing the update functions in
> md5 and sha1 to ap_MD5Update_ascii(), ap_MD5Update_binary(),
> ap_SHA1Update_ascii(), and ap_SHA1Update_binary()? I.e. to better
> reflect which are ascii and which binary (the ascii forms first
> translate the characters as necessary to ascii). And similarly
> for ap_base64. Currently we have ap_SHA1Update() and
> ap_SHA1Update_binary() in 1.3.
Euh... why not call it ap_MD5Update_xlate() and pass an xlate pointer? Seems
a bit better than hard-wiring to ascii/ebcdic and using just one of those
two charsets.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: hooks
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Thu, Jul 06, 2000 at 10:21:51AM -0400, Jeff Trawick wrote:
> > Date: Thu, 6 Jul 2000 06:26:36 -0700
> > From: Greg Stein <gs...@lyra.org>
> >
> > On Thu, Jul 06, 2000 at 08:59:14AM -0400, Jeff Trawick wrote:
> > > > From: rbb@covalent.net
> > > > Date: Wed, 5 Jul 2000 13:35:04 -0700 (PDT)
> > > >
> > > > > > The EBCDIC stuff is still in ap_base64.c, but that is another issue.
> > > > >
> > > > > That has to change anyway to use ap_xlate.
> > > >
> > > > Agreed.
> > >
> > > I guess I'm supposed to know what you're talking about here, but I
> > > don't. Can you clarify?
> >
> > Read the thread a bit later... <20...@innovation.ch> is a
> > good terminus. Ryan's response dropped the authors of the quoted material,
> > but it is basically Ronald on the innermost, myself, Ryan, then Ronald
> > again. :-)
>
> Yep, I went back to the archive and later responded to one of the
> earlier messages. I still don't understand "change anyway to use
> ap_xlate()." All EBCDIC code in 2.0 has been solely APR-based (i.e.,
> ap_xlate_*()) for many moons.
Sorry, you're right, I must have been smoking something weird. I think
the #ifdef CHARSET_EBCDIC confused me.
Cheers,
Ronald
Re: hooks
Posted by Jeff Trawick <tr...@ibm.net>.
> Date: Thu, 6 Jul 2000 06:26:36 -0700
> From: Greg Stein <gs...@lyra.org>
>
> On Thu, Jul 06, 2000 at 08:59:14AM -0400, Jeff Trawick wrote:
> > > From: rbb@covalent.net
> > > Date: Wed, 5 Jul 2000 13:35:04 -0700 (PDT)
> > >
> > > > > The EBCDIC stuff is still in ap_base64.c, but that is another issue.
> > > >
> > > > That has to change anyway to use ap_xlate.
> > >
> > > Agreed.
> >
> > I guess I'm supposed to know what you're talking about here, but I
> > don't. Can you clarify?
>
> Read the thread a bit later... <20...@innovation.ch> is a
> good terminus. Ryan's response dropped the authors of the quoted material,
> but it is basically Ronald on the innermost, myself, Ryan, then Ronald
> again. :-)
Yep, I went back to the archive and later responded to one of the
earlier messages. I still don't understand "change anyway to use
ap_xlate()." All EBCDIC code in 2.0 has been solely APR-based (i.e.,
ap_xlate_*()) for many moons.
Have fun...
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: hooks
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jul 06, 2000 at 08:59:14AM -0400, Jeff Trawick wrote:
> > From: rbb@covalent.net
> > Date: Wed, 5 Jul 2000 13:35:04 -0700 (PDT)
> >
> > > > The EBCDIC stuff is still in ap_base64.c, but that is another issue.
> > >
> > > That has to change anyway to use ap_xlate.
> >
> > Agreed.
>
> I guess I'm supposed to know what you're talking about here, but I
> don't. Can you clarify?
Read the thread a bit later... <20...@innovation.ch> is a
good terminus. Ryan's response dropped the authors of the quoted material,
but it is basically Ronald on the innermost, myself, Ryan, then Ronald
again. :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: hooks
Posted by Jeff Trawick <tr...@ibm.net>.
> From: rbb@covalent.net
> Date: Wed, 5 Jul 2000 13:35:04 -0700 (PDT)
>
> > > The EBCDIC stuff is still in ap_base64.c, but that is another issue.
> >
> > That has to change anyway to use ap_xlate.
>
> Agreed.
I guess I'm supposed to know what you're talking about here, but I
don't. Can you clarify?
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Encoding code in APR
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jul 07, 2000 at 08:28:44PM -0700, rbb@covalent.net wrote:
>...
> > For the SHA1 and MD5 hashing stuff, I'd suggest putting them under
> > apr/crypto/ ("cryptographic algorithms"). That leaves the directory open to
> > other crypto stuff (i.e interfaces to SSL, TLS, or whatever).
>
> Either apr/crypto or apr/hash, either way. crypto is probably better,
> because it can't be confused with hash tables.
Right. That was my thought process, too.
Tonite, I also realized that the /dev/random and truerand stuff in APR
should go in there. Those are used only for true, "cryptographically safe"
random numbers. (they're too slow for basic random number gen)
I'll get that stuff moved at some point, as I'd like to use it for the UUID
generation on non-Win32 platforms.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Encoding code in APR
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Sun, Jul 09, 2000 at 07:38:57PM -0700, rbb@covalent.net wrote:
> On Sun, 9 Jul 2000, Greg Stein wrote:
> > On Sun, Jul 09, 2000 at 04:09:46PM -0700, Life is hard, and then you die wrote:
> > > On Sun, Jul 09, 2000 at 07:29:37AM -0700, rbb@covalent.net wrote:
> > >...
> > > > But apr_validate_password is a VERY useful function. I would personally
> > > > rather move ap_validate_password out of apr_md5, and put it in it's own
> > > > file. If it requires base64, then base64 goes into the crypt directory
> > > > too.
> >
> > Hmm. base64 isn't crypto :-) If/when base64 goes into APR, that is where
> > your "encode" directory would pop up. Or:
> >
> > encoder
> > encoding
> > encode
> >
> > Dunno. The problem is how to properly classify base64 because we don't have
> > any siblings for it (yet).
>
> Am I the only person who doesn't understand this. MD5 is used to encode
> passwords in our scheme, so is SHA1. The algorithms themselves, may not
> be meant for this, but this is what Apache uses these algorithms
> for.
No. As Greg already said, encodings/encoders are usually understood to
be reversible processes; hashes/digests are not reversible. So no,
Apache does not encode passwords, it hashes them - the password is lost
after the process. But this is nit-picking.
> Yes, we also take MD5 checksums at times. But, the reason APR needs
> MD5 is to encode passwords. This is also why we need to ap_checkpasswd
> function.
>
> Why can't we put all of the algorithms in the same directory, along with a
> simple function to check the passwords? This just makes sense to me, so
> please explain it to me.
Fine with me. But we should call not call it crypto (which none of this stuff
is), or encoders (which only base64 is). misc? utils? security? (though
base64 would be stretching that last term a bit).
Cheers,
Ronald
Re: Encoding code in APR
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jul 11, 2000 at 11:05:09PM +0100, Ben Laurie wrote:
> Greg Stein wrote:
> >
> > On Sun, Jul 09, 2000 at 04:09:46PM -0700, Life is hard, and then you die wrote:
> > > On Sun, Jul 09, 2000 at 07:29:37AM -0700, rbb@covalent.net wrote:
> > >...
> > > > But apr_validate_password is a VERY useful function. I would personally
> > > > rather move ap_validate_password out of apr_md5, and put it in it's own
> > > > file. If it requires base64, then base64 goes into the crypt directory
> > > > too.
> >
> > Hmm. base64 isn't crypto :-) If/when base64 goes into APR, that is where
> > your "encode" directory would pop up. Or:
> >
> > encoder
> > encoding
> > encode
> >
> > Dunno. The problem is how to properly classify base64 because we don't have
> > any siblings for it (yet).
>
> No encoding at all is a sibling, of course. Hex is another.
Eh? How does that help to classify where to place base64?
-g
--
Greg Stein, http://www.lyra.org/
Re: Encoding code in APR
Posted by Ben Laurie <be...@algroup.co.uk>.
Greg Stein wrote:
>
> On Sun, Jul 09, 2000 at 04:09:46PM -0700, Life is hard, and then you die wrote:
> > On Sun, Jul 09, 2000 at 07:29:37AM -0700, rbb@covalent.net wrote:
> >...
> > > But apr_validate_password is a VERY useful function. I would personally
> > > rather move ap_validate_password out of apr_md5, and put it in it's own
> > > file. If it requires base64, then base64 goes into the crypt directory
> > > too.
>
> Hmm. base64 isn't crypto :-) If/when base64 goes into APR, that is where
> your "encode" directory would pop up. Or:
>
> encoder
> encoding
> encode
>
> Dunno. The problem is how to properly classify base64 because we don't have
> any siblings for it (yet).
No encoding at all is a sibling, of course. Hex is another.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: Encoding code in APR
Posted by rb...@covalent.net.
On Sun, 9 Jul 2000, Greg Stein wrote:
> On Sun, Jul 09, 2000 at 04:09:46PM -0700, Life is hard, and then you die wrote:
> > On Sun, Jul 09, 2000 at 07:29:37AM -0700, rbb@covalent.net wrote:
> >...
> > > But apr_validate_password is a VERY useful function. I would personally
> > > rather move ap_validate_password out of apr_md5, and put it in it's own
> > > file. If it requires base64, then base64 goes into the crypt directory
> > > too.
>
> Hmm. base64 isn't crypto :-) If/when base64 goes into APR, that is where
> your "encode" directory would pop up. Or:
>
> encoder
> encoding
> encode
>
> Dunno. The problem is how to properly classify base64 because we don't have
> any siblings for it (yet).
Am I the only person who doesn't understand this. MD5 is used to encode
passwords in our scheme, so is SHA1. The algorithms themselves, may not
be meant for this, but this is what Apache uses these algorithms
for. Yes, we also take MD5 checksums at times. But, the reason APR needs
MD5 is to encode passwords. This is also why we need to ap_checkpasswd
function.
Why can't we put all of the algorithms in the same directory, along with a
simple function to check the passwords? This just makes sense to me, so
please explain it to me.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Encoding code in APR
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Jul 09, 2000 at 04:09:46PM -0700, Life is hard, and then you die wrote:
> On Sun, Jul 09, 2000 at 07:29:37AM -0700, rbb@covalent.net wrote:
>...
> > But apr_validate_password is a VERY useful function. I would personally
> > rather move ap_validate_password out of apr_md5, and put it in it's own
> > file. If it requires base64, then base64 goes into the crypt directory
> > too.
Hmm. base64 isn't crypto :-) If/when base64 goes into APR, that is where
your "encode" directory would pop up. Or:
encoder
encoding
encode
Dunno. The problem is how to properly classify base64 because we don't have
any siblings for it (yet).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Encoding code in APR
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Sun, Jul 09, 2000 at 07:29:37AM -0700, rbb@covalent.net wrote:
> On Sat, 8 Jul 2000, Life is hard, and then you die wrote:
>
> > On Sat, Jul 08, 2000 at 09:08:47AM -0700, rbb@covalent.net wrote:
> > >
> > > > ap_base64, ap_checkpass -> lib/utils/
> > >
> > > ap_base64 should be moved. ap_checkpass still bothers me. The function
> > > it implements is in APR already.
> >
> > But it's incomplete (it's missing Netscape's SHA-1 based password).
> > This means apr_validate_password has to move out of apr_md5. Also, the
> > Netscape password scheme needs base64 (in addition to SHA-1). So, if
> > apr_checkpass were to go into apr then ap_base64 would have to too.
>
> But apr_validate_password is a VERY useful function. I would personally
> rather move ap_validate_password out of apr_md5, and put it in it's own
> file. If it requires base64, then base64 goes into the crypt directory
> too.
Of course it's useful - it's part of apr_checkpass, i.e. it's in its own
file. So we're really in complete agreement here.
Cheers,
Ronald
Re: Encoding code in APR
Posted by rb...@covalent.net.
On Sat, 8 Jul 2000, Life is hard, and then you die wrote:
> On Sat, Jul 08, 2000 at 09:08:47AM -0700, rbb@covalent.net wrote:
> >
> > > ap_base64, ap_checkpass -> lib/utils/
> >
> > ap_base64 should be moved. ap_checkpass still bothers me. The function
> > it implements is in APR already.
>
> But it's incomplete (it's missing Netscape's SHA-1 based password).
> This means apr_validate_password has to move out of apr_md5. Also, the
> Netscape password scheme needs base64 (in addition to SHA-1). So, if
> apr_checkpass were to go into apr then ap_base64 would have to too.
But apr_validate_password is a VERY useful function. I would personally
rather move ap_validate_password out of apr_md5, and put it in it's own
file. If it requires base64, then base64 goes into the crypt directory
too.
Although I know that will upset some people.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Encoding code in APR
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Sat, Jul 08, 2000 at 09:08:47AM -0700, rbb@covalent.net wrote:
>
> > ap_base64, ap_checkpass -> lib/utils/
>
> ap_base64 should be moved. ap_checkpass still bothers me. The function
> it implements is in APR already.
But it's incomplete (it's missing Netscape's SHA-1 based password).
This means apr_validate_password has to move out of apr_md5. Also, the
Netscape password scheme needs base64 (in addition to SHA-1). So, if
apr_checkpass were to go into apr then ap_base64 would have to too.
> I would rather just see that function
> moved into the crypt directory in APR.
>
> > ap/ap_cache, ap/ap_hooks -> lib/utils/
> >
> > I'm wondering about main/util_* - util_md5.c and util_date.c could be
> > moved to lib/utils/, but the other stuff references things like request_rec
> > and therefore aren't suitable for putting in lib/utils/ unless we make that
> > lib tightly bound to apache (i.e. unusable outside of it).
>
> Take a VERY close look at main/utils_*. For the most part, the references
> to request_rec's can be replaced with one or two fields from the
> request_rec. Regardless, I am VERY hesitant to move anything into
> lib/utils right now. That library will need it's own build system,
> because we don't want to tie it to Apache. The hooks are tied to APR VERY
> tightly, I haven't looked at ap_cache.
Ok, I'll leave that stuff alone since you have a much better handle on it
than I.
Cheers,
Ronald
Re: Encoding code in APR
Posted by rb...@covalent.net.
> > Either apr/crypto or apr/hash, either way. crypto is probably better,
> > because it can't be confused with hash tables.
>
> Ok, so
>
> apr_md5, apr_sha1 -> lib/apr/crypto/
Yes.
> ap_base64, ap_checkpass -> lib/utils/
ap_base64 should be moved. ap_checkpass still bothers me. The function
it implements is in APR already. I would rather just see that function
moved into the crypt directory in APR.
> ap/ap_cache, ap/ap_hooks -> lib/utils/
>
> I'm wondering about main/util_* - util_md5.c and util_date.c could be
> moved to lib/utils/, but the other stuff references things like request_rec
> and therefore aren't suitable for putting in lib/utils/ unless we make that
> lib tightly bound to apache (i.e. unusable outside of it).
Take a VERY close look at main/utils_*. For the most part, the references
to request_rec's can be replaced with one or two fields from the
request_rec. Regardless, I am VERY hesitant to move anything into
lib/utils right now. That library will need it's own build system,
because we don't want to tie it to Apache. The hooks are tied to APR VERY
tightly, I haven't looked at ap_cache.
I say go for it.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Encoding code in APR
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Fri, Jul 07, 2000 at 08:28:44PM -0700, rbb@covalent.net wrote:
> >
> > For the SHA1 and MD5 hashing stuff, I'd suggest putting them under
> > apr/crypto/ ("cryptographic algorithms"). That leaves the directory open to
> > other crypto stuff (i.e interfaces to SSL, TLS, or whatever).
>
> Either apr/crypto or apr/hash, either way. crypto is probably better,
> because it can't be confused with hash tables.
Ok, so
apr_md5, apr_sha1 -> lib/apr/crypto/
ap_base64, ap_checkpass -> lib/utils/
ap/ap_cache, ap/ap_hooks -> lib/utils/
I'm wondering about main/util_* - util_md5.c and util_date.c could be
moved to lib/utils/, but the other stuff references things like request_rec
and therefore aren't suitable for putting in lib/utils/ unless we make that
lib tightly bound to apache (i.e. unusable outside of it).
Cheers,
Ronald
Re: Encoding code in APR
Posted by rb...@covalent.net.
> They hash data into a fixed-size block. It is an irreversible process. That
> is not encoding.
>
> If the code says "encoding", then it should be changed. It is an improper
> characterization of the process.
Then lets put them in apr/hash.
> No problem, I agree with you on this. You beat me to moving the pool
> functions to apr_pools.h. I was getting pissed off at searching through
> apr_pools.h, apr_lib.h, and apr_general.h. (why the latter two?) I was just
> about to do it, then saw your checkin :-)
apr_lib.h was what all of the lib functions were put in. I always hated
this, and never got around to fixing it until I had to document
everything (something else that was long overdue). Apr_general was a
trash bin for a while, until I was able to get everything sorted
out. That took longer than I expected. :-)
> For the SHA1 and MD5 hashing stuff, I'd suggest putting them under
> apr/crypto/ ("cryptographic algorithms"). That leaves the directory open to
> other crypto stuff (i.e interfaces to SSL, TLS, or whatever).
Either apr/crypto or apr/hash, either way. crypto is probably better,
because it can't be confused with hash tables.
I will get to this next week unless somebody beats me to it.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Encoding code in APR
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jul 07, 2000 at 07:52:36AM -0700, rbb@covalent.net wrote:
>...
> > *) MD5 and SHA1 are *hash* algorithms. not encodings. base64 is an encoding.
>
> Read the code please.
Doesn't matter what the code says :-)
http://www.mach5.com/crypto/algorithms.html -- look at the bottom part of
the page under "hash algorithms"
> As I said before ALL of the code refers to
> encoding data. That sure makes it sound to me like they can be used as
> encoding algorithms. Whether that was their purpose or not is
> irrelevant. They can be used to encode data.
They hash data into a fixed-size block. It is an irreversible process. That
is not encoding.
If the code says "encoding", then it should be changed. It is an improper
characterization of the process.
> > May as well toss the SHA1 hash in there. The two files would simply go into
> > apr/lib/.
>
> No. I am trying to remove apr/lib, because it is a horrible mess of
> unrelated functions. I would like for it to be easy to find functions in
> APR, and currently it isn't inside of lib. Whenever I have to give a
> presentation about APR, I have a section in my talk about "Functions moved
> from Apache 1.3 to APR". That is horrible. I am moving things out of lib
> sometime next week, and making new directories for them.
No problem, I agree with you on this. You beat me to moving the pool
functions to apr_pools.h. I was getting pissed off at searching through
apr_pools.h, apr_lib.h, and apr_general.h. (why the latter two?) I was just
about to do it, then saw your checkin :-)
For the SHA1 and MD5 hashing stuff, I'd suggest putting them under
apr/crypto/ ("cryptographic algorithms"). That leaves the directory open to
other crypto stuff (i.e interfaces to SSL, TLS, or whatever).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Encoding code in APR
Posted by rb...@covalent.net.
> > If you review the archives, you'll discover that later versions of FreeBSD
> > modified their version of crypt to produce different results. They are a
> > bit more secure IIRC, but the results are also just not portable. This
> > means that if we don't put the encoding stuff into APR, and somebody uses
> > an MD5 algorithm on a FreeBSD box, that code will not be portable to a
> > Windows machine using APR with the lib/util MD5 algorithm.
>
> You're mixing your arguments here.
>
> *) crypt() is non-portable
> *) the MD5 hash algorithm is totally portable
I am not mixing arguments, your not paying attention. :-)
The MD5 algorithm is only portable if everybody implements it as
stock. Not every platform does. This was proven on FreeBSD, where we
couldn't GET a stock version of MD5 so that the same passwords could be
used on Unix and Windows, or even two Unix boxes that weren't running the
same version of FreeBSD
> *) the above argument doesn't hold
> *) not all platforms have these hash algorithms, but that doesn't matter --
> we already said that we will never attempt to rely on the platform's hash
> functions (we have our own, so use it)
The problem is Apache versus APR. If MD5 isn't in APR, then we don't have
our own implementation unless we are Apache. It's that simple.
> *) MD5 and SHA1 are *hash* algorithms. not encodings. base64 is an encoding.
Read the code please. As I said before ALL of the code refers to
encoding data. That sure makes it sound to me like they can be used as
encoding algorithms. Whether that was their purpose or not is
irrelevant. They can be used to encode data.
> May as well toss the SHA1 hash in there. The two files would simply go into
> apr/lib/.
No. I am trying to remove apr/lib, because it is a horrible mess of
unrelated functions. I would like for it to be easy to find functions in
APR, and currently it isn't inside of lib. Whenever I have to give a
presentation about APR, I have a section in my talk about "Functions moved
from Apache 1.3 to APR". That is horrible. I am moving things out of lib
sometime next week, and making new directories for them.
> I don't see an argument for base64 encoding, though. I would disagree with
> moving that into APR.
Fine. I'm not going to argue about this anymore.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Encoding code in APR
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jul 06, 2000 at 08:40:39AM -0700, rbb@covalent.net wrote:
>
> I thought of another reason why the md5/sha1 encoding code needs to be in
> APR. It may be VERY portable code, but the results aren't portable. I
> know that makes very little sense. Think about why we decided to always
> use the Apache MD5 code on all platforms. We got the code originally from
> FreeBSD, so we know they have the code, we could have used the crypt
> function on FreeBSD.
>
> If you review the archives, you'll discover that later versions of FreeBSD
> modified their version of crypt to produce different results. They are a
> bit more secure IIRC, but the results are also just not portable. This
> means that if we don't put the encoding stuff into APR, and somebody uses
> an MD5 algorithm on a FreeBSD box, that code will not be portable to a
> Windows machine using APR with the lib/util MD5 algorithm.
You're mixing your arguments here.
*) crypt() is non-portable
*) the MD5 hash algorithm is totally portable
The problem that you refer to is trying to use crypt() to do MD5 hashing.
That just doesn't work.
>...
> With this argument and the argument laid out yesterday about not all
> platforms having encoding API's, does anybody still have a problem with
> creating lib/apr/encode, and putting ap_(md5/sha1/base64) there?
*) the above argument doesn't hold
*) not all platforms have these hash algorithms, but that doesn't matter --
we already said that we will never attempt to rely on the platform's hash
functions (we have our own, so use it)
*) MD5 and SHA1 are *hash* algorithms. not encodings. base64 is an encoding.
All that said, I have discovered a reason for MD5 to be in APR, and it has
nothing to do with the above :-) ... APR needs to do UUID generation which
is non-portable. Win32 has UuidCreate(), but other platforms need to roll an
algorithm. Part of the UUID is random data. This can be fetched using
something like the "truerand" library (which is already in APR?). But when a
good random number generator isn't present, then a great way to generate
random bytes is to apply the MD5 hash to a block of data. By definition, the
result is random :-) ... in any case, this means that APR itself will have a
dependency upon MD5 hashing. Therefore, it needs to include it.
May as well toss the SHA1 hash in there. The two files would simply go into
apr/lib/.
I don't see an argument for base64 encoding, though. I would disagree with
moving that into APR.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Encoding code in APR (Was: Re: hooks)
Posted by rb...@covalent.net.
I thought of another reason why the md5/sha1 encoding code needs to be in
APR. It may be VERY portable code, but the results aren't portable. I
know that makes very little sense. Think about why we decided to always
use the Apache MD5 code on all platforms. We got the code originally from
FreeBSD, so we know they have the code, we could have used the crypt
function on FreeBSD.
If you review the archives, you'll discover that later versions of FreeBSD
modified their version of crypt to produce different results. They are a
bit more secure IIRC, but the results are also just not portable. This
means that if we don't put the encoding stuff into APR, and somebody uses
an MD5 algorithm on a FreeBSD box, that code will not be portable to a
Windows machine using APR with the lib/util MD5 algorithm.
By putting the MD5 algorithm in APR, we remove that problem, and can
provide a common interface that always implements the same alpgorithm
across all platforms.
With this argument and the argument laid out yesterday about not all
platforms having encoding API's, does anybody still have a problem with
creating lib/apr/encode, and putting ap_(md5/sha1/base64) there?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: hooks
Posted by rb...@covalent.net.
> > The EBCDIC stuff is still in ap_base64.c, but that is another issue.
>
> That has to change anyway to use ap_xlate.
Agreed.
> As has been said, these are completely portable functions across any
> platform/compiler/etc, with the exception of the non-binary versions
> of update - those need to use ap_xlate, at which point the stuff
> becomes fully portable.
The problem is what do we mean by "portable". Yes, the C code is
portable. The problem is that there isn't currently an encoding function
on all platforms. If we take the stance that any inheritantly portable
code does not belong in APR, then we basically have to remove all of the
apr/lib directory. All of that code is inherantly portable. But wait,
look at what that code is.
pools -- can't remove those, APR relies on those.
string functions -- things like ap_pstrdup and ap_pstrncpy. We re-wrote
those to be more portable, and to make more
sense. According to the definition that is keeping
the encoding stuff out of APR, these aren't portable
functions.
signals -- not all platforms used the same API or had the same
semantics. We re-implemented to make it all common.
apr_getopt (from misc) -- all platforms didn't have the same semantics,
we re-implemented.
APR wasn't designed to provide only functions that couldn't be written
once for all platforms. It was designed to provide a common API for all
platforms. Not all platforms have crypt, not all platforms have md5, not
all platforms have sha1. Shoot, Windows doesn't have any of them.
These belong in APR, because they implement the same feature on all
platforms. That makes them portable, and it makes them a candidate for a
portability run-time. This does not make APR a kitchen-sink, it doesn't
even expand APR's design goals.
If we want APR to decide on one encoding algorithm, and use it on all
platforms, then fine, put one encoding algorithm in APR and the rest in
lib/util. This sounds stupid to me though. APR needs a way to encode
data on all platforms without relying on another library. Unless crypt is
available on all platforms (it isn't), then this is something APR should
provide.
> Btw., does anybody disagree with changing the update functions in
> md5 and sha1 to ap_MD5Update_ascii(), ap_MD5Update_binary(),
> ap_SHA1Update_ascii(), and ap_SHA1Update_binary()? I.e. to better
> reflect which are ascii and which binary (the ascii forms first
> translate the characters as necessary to ascii). And similarly
> for ap_base64. Currently we have ap_SHA1Update() and
> ap_SHA1Update_binary() in 1.3.
Nope.
> I agree. This is boiling down to the previous (and I think undecided)
> discussion of what should go into APR. I have nothing against putting
> md5, sha1, and base64 into APR - I'm just noting that I think your
> portability argument isn't valid.
I think I explained the portability issue a bit better above. Do you
think it's valid and makes sense now?
> I quite aware of what ap_checkpass contains :-)
> A number of changes were made in the 1.3 code base last July, but those
> changes never got brought forward to 2.0 (the snapshot was taken just
> before). As part of the move I intended to bring those changes forward.
> Btw., apr_validate.c is too generic, IMHO - validate what?
> apr_checkpass.c is clearer. Or apr_validate_pw.c . But that's a nit.
Names are a VERY minor thing to me. I usually don't come up with the
right one, so choose whatever you want. I wasn't aware that there were
changes made to validate_passwd in 1.3 that weren't in 2.0. By all means,
this needs to be updated. From your original note it looked like we were
about to duplicate some logic. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: hooks
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Tue, Jul 04, 2000 at 05:10:26PM -0700, rbb@covalent.net wrote:
> > > I would still really like to see all of these files in APR. They all use
> > > APR types, and although the code is all common for all platforms, they are
> > > portability issues for most programs. By moving them into different
> > > directories within APR, we can enable and disable them at compile time.
> >
> > What portability issues? The ebcdic stuff is now in apr (ap_xlate, or so
> > I assume), and I can't think of any others.
>
> The EBCDIC stuff is still in ap_base64.c, but that is another issue.
That has to change anyway to use ap_xlate.
> I was mainly thinking of the MD5 stuff with regards to portability,
> because some platforms have it and others don't. We actually took our
> code from FreeBSD, so we know they have this function.
As has been said, these are completely portable functions across any
platform/compiler/etc, with the exception of the non-binary versions
of update - those need to use ap_xlate, at which point the stuff
becomes fully portable.
Btw., does anybody disagree with changing the update functions in
md5 and sha1 to ap_MD5Update_ascii(), ap_MD5Update_binary(),
ap_SHA1Update_ascii(), and ap_SHA1Update_binary()? I.e. to better
reflect which are ascii and which binary (the ascii forms first
translate the characters as necessary to ascii). And similarly
for ap_base64. Currently we have ap_SHA1Update() and
ap_SHA1Update_binary() in 1.3.
> The other argument is that this is a bunch of VERY portable encryption
> code. Anybody who is trying to write a secure piece of portable software
> would most likely like to use some of these functions. Isn't this what
> APR is supposed to provide? The ability to write very portable software
> with one library. We can put all of these functions in lib/apr/encrypt or
> lib/apr/enocde (may be more precise) and be able to enable/disable them at
> compile time. I really think these are useful portable routines.
I agree. This is boiling down to the previous (and I think undecided)
discussion of what should go into APR. I have nothing against putting
md5, sha1, and base64 into APR - I'm just noting that I think your
portability argument isn't valid.
> > > At the very least getpass is a portability issue, and it doesn't always
> > > have common code, so it definately belongs in APR.
> >
> > Sorry, confused getpass with checkpass (which needs to be brought in from
> > apache-1.3) - you're right, getpass shouldn't be touched.
>
> ap_checkpass is validate_password, which can be found in
> apr/lib/apr_md5.c. :-) See above for why this function shouldn't be
> moved out of APR. It should be moved to apr/encode/apr_validate.c IMHO
> though.
I quite aware of what ap_checkpass contains :-)
A number of changes were made in the 1.3 code base last July, but those
changes never got brought forward to 2.0 (the snapshot was taken just
before). As part of the move I intended to bring those changes forward.
Btw., apr_validate.c is too generic, IMHO - validate what?
apr_checkpass.c is clearer. Or apr_validate_pw.c . But that's a nit.
Cheers,
Ronald
RE: hooks
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Life is hard, and then you die [mailto:ronald@innovation.ch]
> Sent: Tuesday, July 04, 2000 6:51 PM
>
> On Tue, Jul 04, 2000 at 04:10:21PM -0700, rbb@covalent.net wrote:
> >
> > > If everybody is happy with lib/utils then I'll attempt to
> > > beat you to it for the md5, sha1, base64, getpass, etc.
> >
> > I would still really like to see all of these files in APR. They all use
> > APR types, and although the code is all common for all platforms, they are
> > portability issues for most programs. By moving them into different
> > directories within APR, we can enable and disable them at
> compile time.
>
> What portability issues? The ebcdic stuff is now in apr (ap_xlate, or so
> I assume), and I can't think of any others. Last time I asked about
> this, Greg was against moving them into apr and other-Bill was for it -
> other than that nobody cared. I'm equally split on whether to put it in
> apr or lib/utils.
Ok... APR being APR, and we had very, very little in the way of ap code
left, I strongly felt that should move. I believed it should become part
of APR.
In hindsite, I realize why many were against this. And I think, given
what everyone is suggesting for all the "module helper" code, that there
is room for a lib/aputil style library. The existing ap stuff belongs
there, and so should all the xml stuff.
The difference? No lib/aputil stuff should EVER change from processor
to processor, compiler to compiler, or os to os.
If it isn't that generic, then it's a portability problem (al la APR).
And if it is truly platform process or security model dependent, than
it belongs in the MPM or the potential future SMM.
Bill
Re: hooks
Posted by rb...@covalent.net.
> > > If everybody is happy with lib/utils then I'll attempt to beat you to
> > > it for the md5, sha1, base64, getpass, etc.
> >
> > I would still really like to see all of these files in APR. They all use
> > APR types, and although the code is all common for all platforms, they are
> > portability issues for most programs. By moving them into different
> > directories within APR, we can enable and disable them at compile time.
>
> What portability issues? The ebcdic stuff is now in apr (ap_xlate, or so
> I assume), and I can't think of any others.
The EBCDIC stuff is still in ap_base64.c, but that is another issue.
I was mainly thinking of the MD5 stuff with regards to portability,
because some platforms have it and others don't. We actually took our
code from FreeBSD, so we know they have this function.
The other argument is that this is a bunch of VERY portable encryption
code. Anybody who is trying to write a secure piece of portable software
would most likely like to use some of these functions. Isn't this what
APR is supposed to provide? The ability to write very portable software
with one library. We can put all of these functions in lib/apr/encrypt or
lib/apr/enocde (may be more precise) and be able to enable/disable them at
compile time. I really think these are useful portable routines.
> Last time I asked about
> this, Greg was against moving them into apr and other-Bill was for it -
> other than that nobody cared. I'm equally split on whether to put it in
> apr or lib/utils.
Count me on the side of APR. :-) I believe Manoj is against moving them
into APR as well, but I don't want to speak for him. :-)
> > At the very least getpass is a portability issue, and it doesn't always
> > have common code, so it definately belongs in APR.
>
> Sorry, confused getpass with checkpass (which needs to be brought in from
> apache-1.3) - you're right, getpass shouldn't be touched.
ap_checkpass is validate_password, which can be found in
apr/lib/apr_md5.c. :-) See above for why this function shouldn't be
moved out of APR. It should be moved to apr/encode/apr_validate.c IMHO
though.
> > Which things are included in the etc? I would like to be VERY careful
> > about what we move out of APR, because some of the functions in the lib
> > directory are portability issues, and not cruft for APR.
>
> Etc referred to stuff in ap and main: ap/ap_cache, ap/ap_hooks, and the
> main/util* stuff.
This stuff I would like to see moved to lib/util. This is code that is
very suited for Apache, but isn't really written to be useful to things
other than web servers. That is where I see the biggest
difference.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: hooks
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Tue, Jul 04, 2000 at 04:10:21PM -0700, rbb@covalent.net wrote:
>
> > > .... I keep meaning to move files around and modify
> > > Makefiles to untie these, but other things keep coming up. I think we
> > > need modules/protocol/echo and modules/protocol/http directories. I also
> > > would like to see lib/utils. I plan on doing some of this work this week
> > > unless somebody beats me to it. :-)
> >
> > If everybody is happy with lib/utils then I'll attempt to beat you to
> > it for the md5, sha1, base64, getpass, etc.
>
> I would still really like to see all of these files in APR. They all use
> APR types, and although the code is all common for all platforms, they are
> portability issues for most programs. By moving them into different
> directories within APR, we can enable and disable them at compile time.
What portability issues? The ebcdic stuff is now in apr (ap_xlate, or so
I assume), and I can't think of any others. Last time I asked about
this, Greg was against moving them into apr and other-Bill was for it -
other than that nobody cared. I'm equally split on whether to put it in
apr or lib/utils.
> At the very least getpass is a portability issue, and it doesn't always
> have common code, so it definately belongs in APR.
Sorry, confused getpass with checkpass (which needs to be brought in from
apache-1.3) - you're right, getpass shouldn't be touched.
> Which things are included in the etc? I would like to be VERY careful
> about what we move out of APR, because some of the functions in the lib
> directory are portability issues, and not cruft for APR.
Etc referred to stuff in ap and main: ap/ap_cache, ap/ap_hooks, and the
main/util* stuff.
Cheers,
Ronald
Re: hooks
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jul 04, 2000 at 03:51:00PM -0700, Life is hard, and then you die wrote:
> On Tue, Jul 04, 2000 at 02:57:08PM -0700, rbb@covalent.net wrote:
> >
> > .... I keep meaning to move files around and modify
> > Makefiles to untie these, but other things keep coming up. I think we
> > need modules/protocol/echo and modules/protocol/http directories. I also
> > would like to see lib/utils. I plan on doing some of this work this week
> > unless somebody beats me to it. :-)
>
> If everybody is happy with lib/utils then I'll attempt to beat you to
> it for the md5, sha1, base64, getpass, etc.
+1
--
Greg Stein, http://www.lyra.org/
Re: hooks
Posted by rb...@covalent.net.
> > .... I keep meaning to move files around and modify
> > Makefiles to untie these, but other things keep coming up. I think we
> > need modules/protocol/echo and modules/protocol/http directories. I also
> > would like to see lib/utils. I plan on doing some of this work this week
> > unless somebody beats me to it. :-)
>
> If everybody is happy with lib/utils then I'll attempt to beat you to
> it for the md5, sha1, base64, getpass, etc.
I would still really like to see all of these files in APR. They all use
APR types, and although the code is all common for all platforms, they are
portability issues for most programs. By moving them into different
directories within APR, we can enable and disable them at compile time.
At the very least getpass is a portability issue, and it doesn't always
have common code, so it definately belongs in APR.
Which things are included in the etc? I would like to be VERY careful
about what we move out of APR, because some of the functions in the lib
directory are portability issues, and not cruft for APR.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: hooks
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Tue, Jul 04, 2000 at 02:57:08PM -0700, rbb@covalent.net wrote:
>
> .... I keep meaning to move files around and modify
> Makefiles to untie these, but other things keep coming up. I think we
> need modules/protocol/echo and modules/protocol/http directories. I also
> would like to see lib/utils. I plan on doing some of this work this week
> unless somebody beats me to it. :-)
If everybody is happy with lib/utils then I'll attempt to beat you to
it for the md5, sha1, base64, getpass, etc.
Cheers,
Ronald
Re: hooks
Posted by rb...@covalent.net.
> > All of this is fine if the abstraction of protocols is to give an easy way
> > of plugging in an all new monolithic module that incorporates all the stuff
> > for another protocol (ala the apache core stuff). If it is there to provide
> > the ability to have a very generic framework and I can easily plug in
> > different protocols and those different protocol modules can use some
> > common modules to do certain aspects then it seems what exists isn't going
> > to work well.
>
> Catching up with this rather late, but I really can't see why you think
> this. New protocol modules can call the hooks just like old protocols do
> - how does that not work well?
>
> And like Ryan said - give a real-world example of how this doesn't work,
> and we'll figure out how to make it better.
I think we have convinced him that this is true, but Sam does bring up an
interesting point. Currently, the http protocol module is tied into
Apache very tightly. I keep meaning to move files around and modify
Makefiles to untie these, but other things keep coming up. I think we
need modules/protocol/echo and modules/protocol/http directories. I also
would like to see lib/utils. I plan on doing some of this work this week
unless somebody beats me to it. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------