From owner-freebsd-security Wed Apr 22 09:03:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07942 for freebsd-security-outgoing; Wed, 22 Apr 1998 09:03:04 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07931 for ; Wed, 22 Apr 1998 16:02:58 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id MAA00550 for ; Wed, 22 Apr 1998 12:03:06 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id MAA12751 for ; Wed, 22 Apr 1998 12:03:07 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id MAA01135; Wed, 22 Apr 1998 12:03:06 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Wed, 22 Apr 1998 12:03:06 -0400 (EDT) Message-Id: <199804221603.MAA01135@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-Reply-To: Peter Wemm's message of "Wed, April 22, 1998 13:04:35 +0800" 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> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: freebsd-security@FreeBSD.ORG Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ 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 Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message