Message-Id: <200004092257.IAA30746@mustang.sdc.com.au>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Henk van Lingen <henkvl@cs.uu.nl>, pgsql-interfaces@postgresql.org,
	Magnus Hagander <mha@sollentuna.net>
Subject: Re: ODBC and crypted passwords 
In-Reply-To: Message from Tom Lane <tgl@sss.pgh.pa.us>
	of "Sun, 09 Apr 2000 13:31:10 -0400." <9661.955301470@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 10 Apr 2000 08:27:47 +0930
From: Stephen Davies <scldad@sdc.com.au>

I believe that the US export restrictions have been lifted.

cheers,
Stephen Davies.

Tom Lane <tgl@sss.pgh.pa.us>  wrote:
> Magnus Hagander <mha@sollentuna.net> writes:
> >>>> Is there something which makes a 'crypt' implementation hard?
> >> 
> >> I imagine the problem is that he doesn't want to depend on the 'crypt'
> >> library, which is standard on Unixen but not (AFAIK) on Windows.
> >> Otherwise it'd be easy to transpose libpq's code into the odbc driver.
> >> (OTOH, I believe there are ports of libpq for Windows, so 
> >> maybe crypt() is available there?  Anyone know?)
> 
> > Actually, the crypt()ed authentication is not supported on libpq for Win32.
> > I meant to do this, but I had completely forgotten... 
> 
> Hmm.  Can we find a freely-distributable version of libcrypt anywhere?
> 
> (Actually, now that I think about it, I'm not entirely sure that crypt()
> implements exactly the same transformation on every Unix platform.
> It may be that you have to have a version of crypt() that matches the
> one on your server's platform.  That would be a pain in the neck ...
> but if we did find an open-source libcrypt, maybe we could standardize
> on using it in preference to vendor crypts...)
> 
> 			regards, tom lane


========================================================================
Stephen Davies Consulting	    		      scldad@sdc.com.au
Adelaide, South Australia.     		          Voice: 08-8177 1595
Computing & Network solutions.	 	      Fax: 08-8177 0133