[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patches] [PATCH] EGLIBC_CRYPT and EGLIBC_CRYPT_UFC option groups



Joseph S. Myers wrote:
On Sun, 15 Nov 2009, Maxim Kuvyrkov wrote:

The different algorithms have different salt syntax.  If DES support has
been disabled, the use of a salt with DES syntax should make crypt return an
error rather than doing something with MD5; only a salt starting $1$ should
cause MD5 to be used.  Will such errors be properly given if DES is disabled
with this patch?
Thank you for pointing this out.  I've fixed the crypt[_r] functions to fail
when DES is requested but not available, the fail condition is the same as
with DES not being available due to export restrictions: result == NULL, errno
set to ENOSYS.

Both incremental and full updated patches are attached.  Any further comments?

This revised patch is OK. I wonder if each algorithm should have its own option group - I could imagine that many systems would only need one algorithm - but maybe the others don't take up much space. (Of course enabling libcrypt but disabling *all* algorithms would be a nonsensical combination.)

All the algorithms take little space in the library, around 8-12 KB per algorithm, so it doesn't matter that much to separate all them into dedicated option groups.

The main reason why UFC DES was singled out is due to 160KB RAM overhead per each process which is linked against libcrypt, irrespectively of the encryption algorithm an application is actually using.

Thank you for the review!

--
Maxim Kuvyrkov
CodeSourcery
maxim@xxxxxxxxxxxxxxxx
(650) 331-3385 x724