-----Original Message----- From: "Andreas Pflug"<[EMAIL PROTECTED]> Sent: 01/05/06 11:46:24 To: "[EMAIL PROTECTED]"<[EMAIL PROTECTED]> Cc: "[email protected]"<[email protected]> Subject: Re: [pgadmin-hackers] SVN Commit by dpage: r5106 - in trunk/pgadmin3:
> Is that a good idea to do this in a private md5 implementation? libpq is > going to/already exporting a method for this, which will make us less > sensitive to backend changes. I considered this carefully and chose that method for a few reasons. - Any change (say, to sha1) is a major compatibility issue for any libpq client - it wouldn't be taken lightly, we couldn't fail to miss the change, and it'll be mainly a cut n paste job to fix. - Using libpq to do it requires configure time checks for the correct libpq on *nix, and runtime checking on Win32. I couldn't find a sensibly clean way to do the latter. - Using libpq essentially forces ppl to upgrade to the latest client to benefit from the extra security. All in all, a private implementation seemed the least painful, and secure option. /D -----Unmodified Original Message----- [EMAIL PROTECTED] wrote: > Author: dpage > > Date: 2006-04-30 21:13:00 +0100 (Sun, 30 Apr 2006) > > New Revision: 5106 > > Revision summary: > http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5106&view=rev > > Log: > Pre-encrypt passwords before sending them down the wire or displaying them in > SQL statements. Is that a good idea to do this in a private md5 implementation? libpq is going to/already exporting a method for this, which will make us less sensitive to backend changes. Regards, Andreas ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
