Message-Id:	<200101211728.MAA26023@qnx.com>
Subject:	Re: Status update (Smalltalk/Python)
To:	djgpp-workers AT delorie DOT com
Date:	Sun, 21 Jan 2001 12:28:19 -0500 (EST)
From:	"Alain Magloire" <alain AT qnx DOT com>
In-Reply-To:	<2593-Sun21Jan2001185912+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Jan 21, 2001 06:59:13 PM
X-Mailer:	ELM [version 2.5 PL0b1]
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> 
> > Date: Sun, 21 Jan 2001 11:09:16 -0500 (EST)
> > From: "Alain Magloire" <alain AT qnx DOT com>
> > > 
> > > Eli Zaretskii wrote:
> > > > 
> > > > On Sun, 21 Jan 2001, Tim Van Holder wrote:
> > > > > Wasn't sure what to use for a value though; would apps expect
> > > > > crypt()'ed values or plaintext?
> > > > 
> > > > Could people who can access Unix and GNU/Linux boxes please look what
> > > > they do?
> > 
> > Crypt.
> 
> I think emulating encrypted password is way too much.  Would some
> application mind if we return a clear-text password?  Would they even
> know?

Yes and no.

Yes, it the sense it will always fail.  The way
programs(login, ftpd, popd, etc ...) authenticate is by doing this:

if (strcmp (pw->pw_passwd, crypt (pass, pw->pw_passwd))) {
	return error;
}

By providing, a clear text passwd crypt() will always failed.

So porting applications that involve this may take a few #ifdefs
#ifdef __DJGPP__
# define crypt(k,s) s
#endif

No, since if I understand, DJPP does not provide any support for this.

There are may crypt()'s implementation on the net.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!

- Raw text -