Обсуждение: Re: SVN Commit by dpage: r5106 - in trunk/pgadmin3:

Поиск
Список
Период
Сортировка

Re: SVN Commit by dpage: r5106 - in trunk/pgadmin3:

От
"Dave Page"
Дата:

-----Original Message-----
From: "Andreas Pflug"<pgadmin@pse-consulting.de>
Sent: 01/05/06 11:46:24
To: "svn@pgadmin.org"<svn@pgadmin.org>
Cc: "pgadmin-hackers@postgresql.org"<pgadmin-hackers@postgresql.org>
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'tfail 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'tfind 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-----
svn@pgadmin.org 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

Re: SVN Commit by dpage: r5106 - in trunk/pgadmin3:

От
Andreas Pflug
Дата:
Dave Page wrote:

>
>
> I considered this carefully and chose that method for a few reasons.

'k, after having a look what you did a I found you copied the backend's
version. I agree with your arguments.

AFAICS this is basically a plain copy of the backend version? If so, I'd
prefer to have it stored in the db directory, where we already have the
unchanged keywords.c. All backend extracted sources should be upgradable
from pgsql HEAD by simply copying them.

Regards,
Andreas