Date: Wed, 22 Apr 1998 12:03:06 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Message-ID: <199804221603.MAA01135@brain.zeus.leitch.com> In-Reply-To: Peter Wemm's message of "Wed, April 22, 1998 13:04:35 %2B0800" regarding "Re: Using MD5 insted of DES for passwd ecnryption " id <199804220504.NAA01624@spinner.netplex.com.au> References: <199804211814.OAA23669@brain.zeus.leitch.com> <199804220504.NAA01624@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
[ On Wed, April 22, 1998 at 13:04:35 (+0800), Peter Wemm wrote: ] > Subject: Re: Using MD5 insted of DES for passwd ecnryption > > And what happens when you've got some static 3rd party binary that you can't > relink, and you use a different encryption system locally? (eg: the > chained secureware (as used in SCO etc) des hash method). That's why we run FreeBSD/NetBSD/etc.! (i.e. to avoid ever having to use 3rd party binaries that we can't re-link or even re-compile!) > Distributing statically linked binaries has to be strongly discouraged > since it prevents things like libc bug fixes (eg: res_send() being > adjusted to use poll() or large a fd_set with select() and so on). Many times the possibility of actually implementating such fixes in this wayis extremely limited, esp. when you try to merge multiple fixes. Backwards compatability at the object level is difficult. However by distributing products in object mode they can be re-linked with just those fixes they require, and it's much easier to put special wrappers around clashing object modules. Not so easy as with source, which is obviously more preferable, but possible none the less. > FWIW, I'm a little amazed at the paranoia about dynamic linking. I have > *never* *ever* "lost" or damaged ld.so except through stupidity (made a > mistake with a source change and caused an undefined symbol). I have never > lost or damaged libc.so except through stupidity (again, generally through > normal development accidents with undefined symbols). I have also rendered > my system "cactus" by loosing /dev/console, the entire /dev directory, > damaging /sbin/init and /sbin/sh, misakes in /etc/rc and so on. ld.so and > libc.so have been the *least* of my problems. I can understand the concern > of people coming from systems with less robust VM systems, but we've had a > system where the executable activation and mmap() etc have been pretty much > unified and have been quite been solid since 2.0.5 days. I can't ever > recall a situation where ld.so was unable to be successfully mmap'ed while > executables themselves were loadable. Those kinds of problems are not necessarily the only issues! ;-) -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804221603.MAA01135>