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