From owner-freebsd-hackers Wed Sep 24 17:24:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10490 for hackers-outgoing; Wed, 24 Sep 1997 17:24:48 -0700 (PDT) Received: from roguetrader.com (brandon@cold.org [206.81.134.103]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10485 for ; Wed, 24 Sep 1997 17:24:44 -0700 (PDT) Received: from localhost (brandon@localhost) by roguetrader.com (8.8.5/8.8.5) with SMTP id SAA07530; Wed, 24 Sep 1997 18:25:43 -0600 (MDT) Date: Wed, 24 Sep 1997 18:25:42 -0600 (MDT) From: Brandon Gillespie To: Terry Lambert cc: freebsd-hackers@FreeBSD.ORG Subject: Re: crypt() returning an error... In-Reply-To: <199709242358.QAA29468@usr03.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 24 Sep 1997, Terry Lambert wrote: > > The man page on crypt() states that a NULL will be returned instead of a > > pointer to a string, if an error occurred. The MD5 crypt does not follow > > this, however DES crypt does. Furthermore, in the attempt to hunt out a > > 'standard' for handling error codes, I have checked how other crypt() > > implementations function. OpenBSD for some unknown reason returns the > > string: > > > > ":" > > > > Where Digital Unix also returns a NULL, as does Unixware--however their > > manual pages do not specify NULL as a valid return value. Actually, I mislead you here..both of these crypt implementations will always return a valid string--it simply may be zero-length if the salt is bogus.. > Forget that; we want to know how you are making a straight MD5 hash > cause an error in the first place... 8-) 8-). Well, what should... crypt("", "$MD5$$") return? (er, make that $1$ with the current crypt) > > With MD5 will actually return an encrypted value, with a zero-length salt. > > After my changes, this will return a NULL instead. > > > > Anybody forsee any problems with this? I do not, but I figured I would > > bring it up... > > You should wrapper this; I don't know if "crypt" is enough of a wrapper. hrm, wrapper for what purpose? The code I have now crypt is actually simply a wrapper for whichever algorithm is used.. it looks at the initial token and calls another function specific to that algorithm, so all of the following are valid results: $MD5$salt$passwd $SHS$salt$passwd $BLF$salt$XX$passwd (des style results are also possible) Some of the situations where an error should be raised is if somebody is explicitly trying to use an algorithm that is recognized, but is not enabled (such as using the Extended DES format). -Brandon