* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> ODBC and Kerberos works just fine, if you use the 8.1 ODBC driver. I use
> it all the time :)
That's what I had heard, I just havn't gotten it working yet myself. :)
Believe me when I say that I *really* want to have it working though;
this postgres->
] [pgadmin-hackers] Client-side password encryption
> There's also Kerberos, which I'm happy to say seems to be getting more
> and more use. I'd really like to get ODBC Kerberos working, at least
> with MIT kerberos and then maybe someday (if I can manage to get it
> w
> There's also Kerberos, which I'm happy to say seems to be
> getting more and more use. I'd really like to get ODBC
> Kerberos working, at least with MIT kerberos and then maybe
> someday (if I can manage to get it
> working...) setup some cross-realm stuff with the Windows AD and SSPI
> (iir
Stephen Frost wrote:
Is it actually doing challenge-response where the challenge is different
each time?
The docs say:
AuthenticationMD5Password
The frontend must now send a PasswordMessage containing the password
encrypted via MD5, using the 4-character salt specified in the
* Martijn van Oosterhout (kleptog@svana.org) wrote:
> On Fri, Dec 23, 2005 at 09:42:44AM -0500, Stephen Frost wrote:
> > * Martijn van Oosterhout (kleptog@svana.org) wrote:
> > > This isn't the first time this has been explained, but:
> > >
> > > With password encryption you essentially have two o
On Fri, Dec 23, 2005 at 09:42:44AM -0500, Stephen Frost wrote:
> * Martijn van Oosterhout (kleptog@svana.org) wrote:
> > This isn't the first time this has been explained, but:
> >
> > With password encryption you essentially have two options:
> >
> > - Server knows password, use challenge-respon
On 23 Dec 2005 09:12:52 -0500, Greg Stark <[EMAIL PROTECTED]> wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > > AndrewSN can't post at the moment, but asked me to post this for him:
> > > "Knowing the md5 hash is enough to authenticate v
* Martijn van Oosterhout (kleptog@svana.org) wrote:
> On Fri, Dec 23, 2005 at 09:12:52AM -0500, Greg Stark wrote:
> > Eh? Just because you know everything the postmaster does doesn't mean you
> > can't be stopped. In the traditional unix password file scheme the crypt
> > string is public knowledge
On Fri, Dec 23, 2005 at 09:12:52AM -0500, Greg Stark wrote:
> Eh? Just because you know everything the postmaster does doesn't mean you
> can't be stopped. In the traditional unix password file scheme the crypt
> string is public knowledge but it's not enough to log in. You need the
> original pass
Tom Lane <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > AndrewSN can't post at the moment, but asked me to post this for him:
> > "Knowing the md5 hash is enough to authenticate via the 'md5' method in
> > pg_hba.conf, even if you don't know the original pa
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> AndrewSN can't post at the moment, but asked me to post this for him:
> "Knowing the md5 hash is enough to authenticate via the 'md5' method in
> pg_hba.conf, even if you don't know the original password.
If you know the md5 hash, you know eve
So, can I specify the password to pg_connect() as
'md5127349123742342344234'?
Certainly not. We'd hardly be worrying about obscuring the original
password if the encrypted version were enough to get in with.
AndrewSN can't post at the moment, but asked me to post this for him:
"Knowing the m
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> So, can I specify the password to pg_connect() as
> 'md5127349123742342344234'?
Certainly not. We'd hardly be worrying about obscuring the original
password if the encrypted version were enough to get in with.
regards
Where are we on this? In general I agree with Tom, but I have no time to
do the work. Unless someone has an immediate implementation, I suggest
that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt,
which is the minimum needed to unbreak Windows builds, while this gets
sorted o
I wrote:
> I had forgotten that the Windows build is broken. I'll see what I can
> do with throwing together the cleaner-API function.
Done, but I noticed that the change to createuser has arguably broken
it; at least we need to change the docs. To wit, the docs say
-E
--encrypted
Encrypts
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Where are we on this? In general I agree with Tom, but I have no time to
> do the work. Unless someone has an immediate implementation, I suggest
> that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt,
> which is the minimum needed t
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> 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
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Wed, Dec 21, 2005 at 02:51:46PM -0500, Bruce Momjian wrote:
> > If you add a version number to the Win32 libpq name, you have to update
> > any command-line compile tools that mention libpq after an upgrade. The
> > Unix linker kno
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 ig
On Wed, Dec 21, 2005 at 02:51:46PM -0500, Bruce Momjian wrote:
> If you add a version number to the Win32 libpq name, you have to update
> any command-line compile tools that mention libpq after an upgrade. The
> Unix linker knows about version numbers, but the Win32 linker doesn't,
> so adding ve
On 12/21/05, Bruce Momjian wrote:
> Andreas Pflug wrote:
> > Martijn van Oosterhout wrote:
> >
> > >
> > > So it's only an issue if you have a policy of removing old versions of
> > > libpq on upgrades... I'm not sure what's "best practice" on windows in
> > > this area.
> >
> > When removing the
Andreas Pflug wrote:
> Martijn van Oosterhout wrote:
>
> >
> > So it's only an issue if you have a policy of removing old versions of
> > libpq on upgrades... I'm not sure what's "best practice" on windows in
> > this area.
>
> When removing the application (in this case: pgsql), you'd remove th
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
> Sent: 20 December 2005 01:33
> To: Dave Page
> Cc: Tom Lane; Peter Eisentraut; pgsql-hackers@postgresql.org;
> Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin-hackers] Client-side p
I've already implemented this in phpPgAdmin trivially using the md5()
function. I can't be bothered using a C library function :D
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 cours
Christopher Kings-Lynne wrote:
> 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 :D
IIRC the whole point of this exercise was to avoid passing the password
to the server in the first place. Unless
pher 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 <[EMAIL PROTECTED]> writes:
So it appears that pg_md5_encrypt is not officially
exported fro
Tom Lane wrote:
Martijn van Oosterhout writes:
Are there any reasons why we shouldn't change the libname with every
release like for UNIX? I can't think of any, but you never know...
Surely that cure is far worse than the disease. You'd be trading a
might-break risk (app using new f
Peter Eisentraut said:
>
> 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?
>
Well, these changes have broken the windows build, so something needs to
change.I don't see a reason in pr
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 15:00
> To: Martijn van Oosterhout
> Cc: Dave Page; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin
Martijn van Oosterhout writes:
> Are there any reasons why we shouldn't change the libname with every
> release like for UNIX? I can't think of any, but you never know...
Surely that cure is far worse than the disease. You'd be trading a
might-break risk (app using new function will fail if used
E: [HACKERS] [pgadmin-hackers] Client-side password
> encryption
>
> > > Yes.
> > > If FooApp is compiled against 8.0, it will then be unable
> to run if
> > > you upgrade libpq to 8.1. IIRC on Unix it will "fall
> > forward" to the
>
> > Yes.
> > If FooApp is compiled against 8.0, it will then be unable to run if
> > you upgrade libpq to 8.1. IIRC on Unix it will "fall
> forward" to the
> > new version if it's just a minor version upgrade (correct me if I'm
> > wrong).
> > On windows, it will break with an ugly dialog box.
E: [HACKERS] [pgadmin-hackers] Client-side password
> encryption
>
> Yes.
> If FooApp is compiled against 8.0, it will then be unable to
> run if you
> upgrade libpq to 8.1. IIRC on Unix it will "fall forward" to the new
> version if it's just a minor version up
Martijn van Oosterhout wrote:
So it's only an issue if you have a policy of removing old versions of
libpq on upgrades... I'm not sure what's "best practice" on windows in
this area.
When removing the application (in this case: pgsql), you'd remove that
old lib as well if it's the only app u
On Mon, Dec 19, 2005 at 01:07:26PM +0100, Magnus Hagander wrote:
> If FooApp is compiled against 8.0, it will then be unable to run if you
> upgrade libpq to 8.1. IIRC on Unix it will "fall forward" to the new
> version if it's just a minor version upgrade (correct me if I'm wrong).
> On windows, i
> > > As for Windows DLL hell, I don't know a lot about that, but if
> > > that's such a problem, why didn't the original creators of the
> > > windows port stick the version number in there from the start. On
> > > UNIX, libpq is half versioned (the library is, but not
> the symbols)
> > > so
> -Original Message-
> From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 10:42
> To: Dave Page
> Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin
On Mon, Dec 19, 2005 at 10:32:03AM -, Dave Page wrote:
>
> > As for Windows DLL hell, I don't know a lot about that, but if that's
> > such a problem, why didn't the original creators of the windows port
> > stick the version number in there from the start. On UNIX, libpq is
> > half versioned
> -Original Message-
> From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 09:38
> To: Dave Page
> Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin
On Mon, Dec 19, 2005 at 09:16:19AM -, 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.
> > If programs are really worried about it, the
> -Original Message-
> From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 08:59
> To: Dave Page
> Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin
On Mon, Dec 19, 2005 at 08:51:23AM -, 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
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> 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 p
Christopher Kings-Lynne <[EMAIL PROTECTED]> 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
> proje
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?
Chris
---(end of broadcast)-
Andreas Pflug wrote:
> Dave Page wrote:
> > So did you just rip it from there into psql? I don't see it in the
> > list of libpq exports so if thats not the case, on Windows at least
> > we'll need to change the api, and possibly the dll name as well to
> > avoid any compatibility issues.
>
> And
46 matches
Mail list logo
