You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Cliff Woolley <cl...@yahoo.com> on 2001/05/31 06:14:02 UTC
Re: cvs commit: apr STATUS
On 31 May 2001 jerenkrantz@apache.org wrote:
> @@ -65,6 +65,8 @@
> * add apr_crypt() and APR_HAS_CRYPT for apps to determine whether the
> crypt() function is available, and a way to call it (whether it is
> located in libc, libcrypt, or libufc)
> + Justin says: Should apr_crypt() be in apr-util?
> +
> Status: Greg +1 (volunteers)
>From the description, it sounds to me like apr_crypt is a portability
wrapper, not a function that is inherently portable like all the things in
apr-util. Therefore it belongs in APR itself IMO...
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: apr STATUS
Posted by Greg Stein <gs...@lyra.org>.
Right. What Cliff said.
We aren't going to provide a replacement for it, just say whether it is
available, and get it linked in from the right library (it can live in
several places).
crypt() is a rather poor hash function. We have MD5 and SHA1 instead.
Cheers,
-g
On Thu, May 31, 2001 at 12:37:41AM -0400, Cliff Woolley wrote:
> On Wed, 30 May 2001, Justin Erenkrantz wrote:
>
> > I think that wherever these other crypto functions go, so should
> > crypt().
>
> Yeah, but...
>
> > crypt() is slightly different than the other crypto algorithms as
> > my systems have it as a standard library call. But, not all systems
> > will have it.
>
> Which is exactly why it should go in APR and not APR-util. APR-util only
> contains functions that are complete, portable implementations of their
> respective functionality (eg the SHA1 implementation). It was born when
> it was decided that APR's focus should be on creating a library that hides
> platform-specific details of functionality (eg locking, mmaps, DSOs, etc)
> that is non-portable. That's the aim of apr_crypt()... to make a portable
> way to access the system's crypt() if there is one. If apr_crypt() were
> to be a from-scratch implementation of crypt() that was written with
> inherently portable code, then yes, it would go in apr-util. But that's
> not the goal, so it goes in APR.
>
> My $0.02.
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr STATUS
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 30 May 2001, Justin Erenkrantz wrote:
> I think that wherever these other crypto functions go, so should
> crypt().
Yeah, but...
> crypt() is slightly different than the other crypto algorithms as
> my systems have it as a standard library call. But, not all systems
> will have it.
Which is exactly why it should go in APR and not APR-util. APR-util only
contains functions that are complete, portable implementations of their
respective functionality (eg the SHA1 implementation). It was born when
it was decided that APR's focus should be on creating a library that hides
platform-specific details of functionality (eg locking, mmaps, DSOs, etc)
that is non-portable. That's the aim of apr_crypt()... to make a portable
way to access the system's crypt() if there is one. If apr_crypt() were
to be a from-scratch implementation of crypt() that was written with
inherently portable code, then yes, it would go in apr-util. But that's
not the goal, so it goes in APR.
My $0.02.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: apr STATUS
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, May 31, 2001 at 12:14:02AM -0400, Cliff Woolley wrote:
> On 31 May 2001 jerenkrantz@apache.org wrote:
>
> > @@ -65,6 +65,8 @@
> > * add apr_crypt() and APR_HAS_CRYPT for apps to determine whether the
> > crypt() function is available, and a way to call it (whether it is
> > located in libc, libcrypt, or libufc)
> > + Justin says: Should apr_crypt() be in apr-util?
> > +
> > Status: Greg +1 (volunteers)
>
> >From the description, it sounds to me like apr_crypt is a portability
> wrapper, not a function that is inherently portable like all the things in
> apr-util. Therefore it belongs in APR itself IMO...
Well, I was thinking of the crypto dir in apr-util. sha1 is already
there. md5 would make sense there - I think we've agreed that if we
*can* replace md5 in uuid, it makes sense to place md5 in apr-util.
The only reason that md5 is in APR is because we don't always have
random data sources. Sander has submitted a patch for md4 (I'm
slowly working my way through patches...).
I think that wherever these other crypto functions go, so should
crypt(). But, as always, I'm open to discussion on this. Granted,
crypt() is slightly different than the other crypto algorithms as
my systems have it as a standard library call. But, not all systems
will have it. -- justin