> David Burren writes:
>  > Danny Thomas <D.Thomas@vthrc.uq.edu.au> has reminded me about something:
>  > 
>  > Has anyone else given any thought to the pros and cons of having crypt in
>  > a shared library?  I'm starting to think the disadvantages outweigh the
>  > advantages.
>
> The advantages are that when I forget to copy crypt.c into the compile
> dir, I only have to compile and install libcrypt to be back in
> business.

Huh?  There are only a limited number of programs in /usr/src that use crypt.
Some of them are statically linked already (for different reasons) so your
comment seems to fall flat.

A simple find/grep on the Makefiles will find the affected programs for you,
and relinking those is a small job.  Not having to relink these programs is
only a small win, and doesn't seem to outweigh the security concerns.


Anyway, what's this "copy crypt.c into the compile dir"?  Why isn't it in
there already?  Seems like your procedures need some work.

If you use the tar files from sun-lamp et. al. then you should have another
"crypt" tar file that you extract along with them.  If you're inside the
US this can simply contain the US crypt.c.  Or (and this includes if you're
outside the US) it can be the FreeSec tar file.

If you use sup, the crypt files should be there automagically.  US sup-ers
are probably already supping the US crypt.c, and I'm hoping that non-US sup
sites will put FreeSec into their "security" package so that their sup
clients don't have to bother changing anything.

- David B.

------------------------------------------------------------------------------