[Pkg-shadow-devel] Bug#495502: shadow: please allow linking Shadow to OpenSSL

[Nicolas François]

tags 495502 wontfix
tags 495502 help
thanks

> From: Robert Connolly <robert at linuxfromscratch.org>
> To: pkg-shadow-devel at lists.alioth.debian.org
> Date: Sun, 17 Aug 2008 02:03:30 -0400
> Subject: [Pkg-shadow-devel] Linking Shadow to OpenSSL
> 
> Hello. I started a feature request for this, but maybe it will get more 
> feedback here. Attached is a patch to add --with-openssl. So far I got it 
> working with DES and MD5. I worked by example, and I didn't find examples of 
> using OpenSSL to make sha512 passwords that are compatible. Maybe someone who 
> knows what they're doing could help.
> 
> There are great advantages to using OpenSSL instead of Libc. We would have a 
> more robust choice in algorithms, random sources for salt, maybe hmac, and it 
> could pave the way towards AES passwords. Better performance with actively 
> maintained (asm) code for algorithms. Better portability.

I fail to see these as great advantages.
I'm not sure there is a need for more robust choice in algorithms, random
sources for salt, AES passwords, or better performance.

Better portability could be nice. But using OpenSSL also has a great
maintainability issue, because the code to generate the passwords will be
included in the shadow's source.

> I don't have the knowledge to finish the SHA patch, but I would like to use 
> RAND_pseudo_bytes() for password salt so we can finally start using 
> unpredictable (not gettimeofday+getpid) non-alphanumeric salt.
> 
> Opinions, help, comments?

I'm currently bot willing to actively contribute in that area.
I also fear that this code path will have no maintenance and very few
users.
I would prefer to use a portable replacement library for crypt (I don't
know if xcrypt is portable). At least this would give a small chance that
the tool which generate the passwords and the tools which verify the
passwords can use the same algorithm.


Best Regards,
-- 
Nekral