Re: MD5

[David Ayers]

Hi Manuel,
hi Richard

Manuel Guesdon wrote:

> Hi,
>
> On Thu, 23 Jan 2003 12:44:59 +0100 David Ayers <d.ayers@inode.at> wrote:
> >| I don't think the issue right now is "how" to implement it (because with 
> >| yours we now seem to have three implementations) but rather "where".  
> >| But let me get back to "how" anyway.  I think the following API would be 
> >| usefull
> >| 
> >| @interface NSData (MD5)
> >| - (NSData *)md5Digest; /* This method actually implements the calculations*/
>
> seems good.
Currently base exports -(NSData *)MD5Digest (but personnally I would 
have preferred md5Digest :-)...)

> >| - (NSString *)md5StringUsingEncoding: (NSStringEncoding) enc;
>
> MD5 strings are usually encoded as done in GSCryptBase.m: DataToHexString (be 
> carefill to checkout last version .There
> was a bug on previous versions).
> There's no need for encoding. so I'll prefer using name like: 
> md5DigestHexString.
(Yes, Richard made me aware of that also :-) ) The gsweb patch I posted 
yesterday still refered to DataToHexSting, but I didn't have to link it 
agains gscrypt for some strange reason.  So I guess I left a runtime 
error. :-( (I didn't see a compiler warning using 3.2.1 either, but I 
think I noticed that before.)

> >| - (NSString *)md5String; /* uses default encoding.*/
>
> ==> md5DigestHexString.
Yes something like this what would be very convienient.  All we would 
*really* need is an NSData category that returns the contents in a hex 
representation.  This is already done in a way by the plist 
representation but not in a format that is usable as URL's or as a 
comparison for check md5 check sums.  In fact I'm wondering whether 
there should be some parameter denoting the format (capitol vs. lower 
case letters / prepending bytes with ' 0x' or not) but that would only 
be interesting for NSData. All we would need for md5 digests are capital 
letters.

> >| @end
> >| 
> >| @interface NSString (MD5)
> >| - (NSString *)md5StringUsingEncoding: (NSStringEncoding) enc;
>
> ==> md5DigestHexString.
Carefull! Here we would need the encoding because the string recieving 
the message would have to turned into NSData before it gets digested.

> >| - (NSString *)md5String; /* uses default encoding.*/
>
> ==> md5DigestHexString.
OK, this would use the default encoding to produce the NSData.

The names sound sane, and I'm not too emotional about them.  I would 
just like to know, Richard, if you agree this to be plausible and 
whether you are allready doing something in this respect.  If it's 
acceptable but you just don't have the time currently, I'll gladly get 
to it.  I just want to avoid duplicating the work. (BTW: what should we 
do with md5.c/h in base currently as you seem to have used yet another 
md5 implementation within GSCategories.m)

> >| But more importantly is where these Categories should go:
> >| 
> >| 1. base/Additions
>
> base/Additions seems a good place. 
Convinced.

> >| 2. gscrypt - well actually I wouldn't change the existing 
> >| implementation, I would just try handling the pam_-problem transparently 
> >| with LIBRARY_DEPENDS_UPON or/and configure.
>
> The best way I see for this is to add a configure so pam part can be ignored.
I'll do this on monday.

Cheers,
Dave