> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 19 December 2005 05:37
> To: Christopher Kings-Lynne
> Cc: Peter Eisentraut; pgsql-hackers@postgresql.org; Andreas
> Pflug; Dave Page
> Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
> encryption
>
> Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> >> So it appears that pg_md5_encrypt is not officially
> exported from libpq.
> >> Does anyone see a problem with adding it to the export
> list and the
> >> header file?
>
> > Is it different to normal md5? How is this helpful to the
> phpPgAdmin
> > project?
>
> It would be better to export an API that is (a) less random (why one
> input null-terminated and the other not?) and (b) less tightly tied
> to MD5 --- the fact that the caller knows how long the result must be
> is the main problem here.
>
> Something like
> char *pg_gen_encrypted_passwd(const char *passwd, const
> char *user)
> with malloc'd result (or NULL on failure) seems more future-proof.

Changing the API is likely to cause fun on Windows for new apps that
find an old libpq.dll. Perhaps at this point it should become
libpq82.dll?

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Mon, Dec 19, 2005 at 08:51:23AM -0000, Dave Page wrote:
> > Something like
> > char *pg_gen_encrypted_passwd(const char *passwd, const
> > char *user)
> > with malloc'd result (or NULL on failure) seems more future-proof.
>
> Changing the API is likely to cause fun on Windows for new apps that
> find an old libpq.dll. Perhaps at this point it should become
> libpq82.dll?

Hmm? Libpq already has a version number, I beleive it's upto 4.1 right
now. So if any number is used, it should be that. And secondly, there
have already been new functions added to the API without changing the
library name so why should that happen here?

In windows the trend seems to be to upgrade a library if the one on the
system is too old. If programs are really worried about it, they should
lookup the function dynamically rather than statically...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFDpnZKIB7bNG8LQkwRAmrbAJ9vZuYLbTx/QEvQHBGFAhUY/jamVACfRd8A
UfUR0PeFBklLuxuPiEB+O1c=
=AAxf
-----END PGP SIGNATURE-----

By the way,

I've already implemented this in phpPgAdmin trivially using the md5()
function. I can't be bothered using a C library function

Chris

Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>>Sent: 19 December 2005 05:37
>>To: Christopher Kings-Lynne
>>Cc: Peter Eisentraut; pgsql-hackers@postgresql.org; Andreas
>>Pflug; Dave Page
>>Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
>>encryption
>>
>>Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>>
>>>>So it appears that pg_md5_encrypt is not officially
>>
>>exported from libpq.
>>
>>>>Does anyone see a problem with adding it to the export
>>
>>list and the
>>
>>>>header file?
>>
>>>Is it different to normal md5? How is this helpful to the
>>
>>phpPgAdmin
>>
>>>project?
>>
>>It would be better to export an API that is (a) less random (why one
>>input null-terminated and the other not?) and (b) less tightly tied
>>to MD5 --- the fact that the caller knows how long the result must be
>>is the main problem here.
>>
>>Something like
>> char *pg_gen_encrypted_passwd(const char *passwd, const
>>char *user)
>>with malloc'd result (or NULL on failure) seems more future-proof.
>
>
> Changing the API is likely to cause fun on Windows for new apps that
> find an old libpq.dll. Perhaps at this point it should become
> libpq82.dll?
>
> Regards, Dave.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

> IIRC the whole point of this exercise was to avoid passing the password
> to the server in the first place. Unless you are talking about a PHP
> md5() password of course ...
>



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match