On Wed, Jul 18, 2007 at 06:01:33PM -0400, Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Oh, they're fully interchangeable at the wire level? Is this true both
with respect to the PG client/backend protocol and the protocol to the
authentication server?
I believe that's the
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
That's for client. How should we go about doing it on the server side?
Perhaps just add the ability to specify sspi as authentication method, to
differentiate it from gss?
That certainly works for me, and makes sense to me.
Thanks!
On Thu, Jul 19, 2007 at 06:38:08AM -0400, Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
That's for client. How should we go about doing it on the server side?
Perhaps just add the ability to specify sspi as authentication method, to
differentiate it from gss?
That
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Ok, I actually have this working now, pending a few cleanups.
Awesome!
Do you have a dev box with 8.3 on it that you could run some tests on? I
could send over a libpq.dll compiled to support both GSSAPI and SSPI (and
krb5) and you could verify it
Now that we have working GSSAPI authentication, I'd like to see the
following done:
* Deprecate krb5 authentication in 8.3. At least in documentation, possibly
with a warning when loading pg_hba.conf?
* Remove krb5 authenticatino completely in 8.4.
The reasons for this is:
* krb5 auth doesn't do
Magnus Hagander wrote:
Now that we have working GSSAPI authentication, I'd like to see the
following done:
* Deprecate krb5 authentication in 8.3. At least in documentation, possibly
with a warning when loading pg_hba.conf?
* Remove krb5 authenticatino completely in 8.4.
libpq would still
On Wed, Jul 18, 2007 at 11:45:19AM +0100, Heikki Linnakangas wrote:
Magnus Hagander wrote:
Now that we have working GSSAPI authentication, I'd like to see the
following done:
* Deprecate krb5 authentication in 8.3. At least in documentation, possibly
with a warning when loading
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5 auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
/D
---(end of
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5 auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
You have a
Magnus Hagander wrote:
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5 auth.
OK, well thats a problem. pgAdmin supports back to
Magnus Hagander wrote:
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5 auth.
OK, well thats a problem. pgAdmin supports back to
On Wed, Jul 18, 2007 at 12:16:49PM +0100, Heikki Linnakangas wrote:
Magnus Hagander wrote:
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server
Magnus Hagander wrote:
But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)
I'm not sure what the deprecation would mean in the client-side. You're
going to need it if you want to
On Wed, Jul 18, 2007 at 12:26:28PM +0100, Heikki Linnakangas wrote:
Magnus Hagander wrote:
But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)
I'm not sure what the deprecation
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5
auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
I think you need to put forward an alternative
Andrew Dunstan wrote:
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5
auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
I think you need to put
Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander:
The main reasons would be to have less code to maintain,
I don't think the krb5 support has needed all that much maintenance in the
last few years.
and to make life
easier for packagers. For example, win32 would no longer need to
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5
auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
How many people actually use kerberos... How many
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used
krb5 auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
I think
Joshua D. Drake wrote:
pgAdmin was just one example. This prevents anyone with kerberos5 in a
similar situation upgrading their client libraries - including users
of the myriad of apps that use psqlODBC.
Who likely don't use kerberos.
Probably not in the majority of cases - but we have a
Magnus Hagander [EMAIL PROTECTED] writes:
But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)
In the krb4 case, we left it in there until there was very little
probability anyone was
[EMAIL PROTECTED] (Peter Eisentraut) writes:
Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander:
The main reasons would be to have less code to maintain,
I don't think the krb5 support has needed all that much maintenance in the
last few years.
and to make life
easier for
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)
In the krb4 case, we
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
This needs to be fixed.
Non, GSSAPI and krb5 are *not* mutually exclusive.
SSPI and GSSAPI are mutually exclusive.
Color me confused then. What's the difference?
Joshua D. Drake wrote:
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used
krb5 auth.
OK, well thats a problem. pgAdmin supports
Tom Lane [EMAIL PROTECTED] writes:
The real problem in my mind is this business of the gssapi and krb5
support being mutually exclusive.
Oh, I didn't catch that. That's wrong anyways, there could be multiple
applications on the same machine, some of which use krb4 and some which use
gssapi.
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
This needs to be fixed.
Non, GSSAPI and krb5 are *not* mutually exclusive.
SSPI and GSSAPI are mutually exclusive.
Color me confused then. What's the difference?
SSPI
* Tom Lane ([EMAIL PROTECTED]) wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
This needs to be fixed.
Non, GSSAPI and krb5 are *not* mutually exclusive.
SSPI and GSSAPI are mutually exclusive.
Color me confused then.
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
But we're talking two different issues. Deprecating/removing krb5 is a
different thing from having GSSAPI and SSPI mutually exclusive or not.
To the extent that keeping krb5 around implies a much lower burden on
GSSAPI support under Windows, I
* Dave Page ([EMAIL PROTECTED]) wrote:
Probably not in the majority of cases - but we have a large userbase these
days, and a small percentage may still equate to a large number. I know at
least two people that do use psqlODBC + Kerberos.
I certainly use it alot! Of course, we'll move to
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
OK, well thats a problem. pgAdmin supports back to 7.3...
How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who cares.
AOL, MIT, CMU,
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
But we're talking two different issues. Deprecating/removing krb5 is a
different thing from having GSSAPI and SSPI mutually exclusive or not.
To the extent that keeping krb5 around implies a much lower burden on
GSSAPI
Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
This needs to be fixed.
Non, GSSAPI and krb5 are *not* mutually exclusive.
SSPI and GSSAPI are mutually exclusive.
Color me confused
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
The maintenance part of me suggesting getting rid of krb5 is the
smallest one. It being a non-standard protocol is more important, and
the fact that the exchange breaks the libpq protocol and is not
protected by SSL is the big reason.
Erm, it
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Certainly not just minor adjustments, since we need to do dynamic
loading and checking for the functions. That's the big one, which will
If we're supporting krb5 anyway, and shipping the bits that go along
with that, do we need to do dynamic loading
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
The maintenance part of me suggesting getting rid of krb5 is the
smallest one. It being a non-standard protocol is more important, and
the fact that the exchange breaks the libpq protocol and is not
protected by SSL is the big
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Certainly not just minor adjustments, since we need to do dynamic
loading and checking for the functions. That's the big one, which will
If we're supporting krb5 anyway, and shipping the bits that go along
with that, do we
Stephen Frost wrote:
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
OK, well thats a problem. pgAdmin supports back to 7.3...
How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
No, no requirement. But you would certainly expect it to use it if you
have SSL on the connection.
Uhh, perhaps, but my recollection is that it's generally *not* done that
way in other things.. Honestly, it doesn't matter to me, just wanted to
clear
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Certainly not just minor adjustments, since we need to do dynamic
loading and checking for the functions. That's the big one, which will
If we're supporting krb5 anyway, and
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who cares.
AOL,
Stephen Frost wrote:
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
Oh, yea, and every place that uses Active Directory ..
Note that we are talking about Kerberos + PostgreSQL, not Kerberose in
general.
I was referring to your first question, which, in my view, is the more
appropriate one
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Certainly not just minor adjustments, since we need to do dynamic
loading and checking for the functions. That's the big one, which will
If we're supporting
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Well, since you're the only one who've asked for the feature, I guess
that's good enough for me unless someone else complains. If you have a
good suggestion for a name for it, let me know, otherwise I'll just cook
something up.
Mozilla uses
Stephen Frost wrote:
Honestly, for now I'm happy w/ it being a connectionstring option. It
seems the most appropriate place for it to go. That does mean that
applications may need to be modified to support gssapi (where they might
not have to be for sspi since it's the default), but since
Heikki Linnakangas wrote:
Stephen Frost wrote:
Honestly, for now I'm happy w/ it being a connectionstring option. It
seems the most appropriate place for it to go. That does mean that
applications may need to be modified to support gssapi (where they might
not have to be for sspi since it's
Magnus Hagander wrote:
Heikki Linnakangas wrote:
Stephen Frost wrote:
Honestly, for now I'm happy w/ it being a connectionstring option. It
seems the most appropriate place for it to go. That does mean that
applications may need to be modified to support gssapi (where they might
not have
* Heikki Linnakangas ([EMAIL PROTECTED]) wrote:
Uh, this is really confusing. Let's see if I got this right. So we're
talking about two orthogonal changes here:
It is kinda confusing. :)
1. Wire protocol. In 8.2 and below, we used the krb5 protocol. 8.3
server and libpq will use the GSSAPI
Heikki Linnakangas [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
The wire protocol is the same for them. It's a matter of which *client
library* should be used to produce the packets that go over the network.
...
On Windows, why would you need GSSAPI, if SSPI comes with the operation
Magnus Hagander [EMAIL PROTECTED] writes:
The issue is *not* about GSSAPI vs krb5. It's with GSSAPI vs SSPI.
The wire protocol is the same for them. It's a matter of which *client
library* should be used to produce the packets that go over the network.
Oh, they're fully interchangeable at the
* Gregory Stark ([EMAIL PROTECTED]) wrote:
Am I right in thinking that while the client-postgres protocol may be the
same the actual authentication tokens are different? That is, if you have a
Windows Active Directory server then using SSPI will use your Windows
credentials obtained from that
* Tom Lane ([EMAIL PROTECTED]) wrote:
Oh, they're fully interchangeable at the wire level? Is this true both
with respect to the PG client/backend protocol and the protocol to the
authentication server?
I believe that's the case, yes.
If there's no interoperability issues then I
agree that
52 matches
Mail list logo
