Future of krb5 authentication

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 work against older server versions, right?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

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 pg_hba.conf?
* Remove krb5 authenticatino completely in 8.4.

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used krb5 auth.
I want to remove it from both libpq and the server.
(8.3 libpq would of course work with older versions, since it's only
deprecated at that point)

I guess a compromise would be to remove it from the server in 8.4 and libpq
in 8.5 or so, if people think that it's a problem. But I think we definitly
want to get it out of libpq as well eventually.

//Magnus

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

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 similar problem there already - 8.1 removed support for Kerberos
4, so if your 7.3 server is configged with krb4, you loose anyway.

//Magnus

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 7.3...

You have a similar problem there already - 8.1 removed support for Kerberos
4, so if your 7.3 server is configged with krb4, you loose anyway.

We never shipped krb4 support in any of our self contained binary
distros (I'm not counting those which rely on external libpq packages).

Regards, Dave

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 7.3...

You have a similar problem there already - 8.1 removed support for Kerberos
4, so if your 7.3 server is configged with krb4, you loose anyway.

Let's be practical here. We're going to have support for both in libpq
for at least one version anyway. What do we gain by removing that
support in a later release? I think we should just keep it around until
we have a pressing reason to remove it, say if it gets in the way of
implementing some new feature.

In the server, I think we could remove it sooner. But even there, is
there a reason why we should?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

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 version used krb5 auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

You have a similar problem there already - 8.1 removed support for Kerberos
4, so if your 7.3 server is configged with krb4, you loose anyway.

Let's be practical here. We're going to have support for both in libpq
for at least one version anyway. What do we gain by removing that
support in a later release? I think we should just keep it around until
we have a pressing reason to remove it, say if it gets in the way of
implementing some new feature.

In the server, I think we could remove it sooner. But even there, is
there a reason why we should?

The main reasons would be to have less code to maintain, and to make life
easier for packagers. For example, win32 would no longer need to ship the
kerberos binaries in the package (and update it properly etc).

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? ;-)

//Magnus

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 connect to a server that uses it,
there's no alternative.

In the server, I don't see a problem with it. What would the deprecation
mean, though? Mention in the docs that it's going to removed sometime in
the future? A warning if you enable it?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

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 would mean in the client-side. You're
going to need it if you want to connect to a server that uses it,
there's no alternative.

No, it would mean nothing on the client.

In the server, I don't see a problem with it. What would the deprecation
mean, though? Mention in the docs that it's going to removed sometime in
the future? A warning if you enable it?

At least a warning in the docs. And possibly also a warning when you enable
it, depending on what people thing is appropriate.

//Magnus

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 plan, then. Asking us to
wait until your oldest version is 8.4 before we rip it out of libpq
doesn't sound too good.

cheers

andrew

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 forward an alternative plan, then. Asking us to
wait until your oldest version is 8.4 before we rip it out of libpq
doesn't sound too good.

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.

Regards, Dave

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 ship the
kerberos binaries in the package (and update it properly etc).

Nobody is forcing anyone to ship anything anyway.

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? ;-)

You might want to inquire about that on -general.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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 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.

Joshua D. Drake

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 you need to put forward an alternative plan, then. Asking us
to wait until your oldest version is 8.4 before we rip it out of libpq
doesn't sound too good.

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.

Joshua D. Drake

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 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.

Regards, Dave

Magnus Hagander <magnus@hagander.net> 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 using it anymore, and AFAIR there was no
significant maintenance burden from that. I don't see a reason to be
harsher on the krb5 case.

The real problem in my mind is this business of the gssapi and krb5
support being mutually exclusive. That is going to cause tremendous
pain because there won't be any convenient upgrade path. Particularly
not for users of binary packages (RPMs etc) --- they'll be screwed
if their packager changes, and have no way to upgrade if he doesn't.
This needs to be fixed.

regards, tom lane

peter_e@gmx.net (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 packagers. For example, win32 would no longer need to ship the
kerberos binaries in the package (and update it properly etc).

Nobody is forcing anyone to ship anything anyway.

But on the other hand, if support for something gets "ripped out,"
that pretty much forces packagers to NOT ship it anymore. So it's not
totally symmetrical...

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? ;-)

You might want to inquire about that on -general.

Good idea...

--
let name="cbbrowne" and tld="linuxfinances.info" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/internet.html
"This must be Thursday. I never could get the hang of Thursdays."
- Arthur Dent

On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> 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 using it anymore, and AFAIR there was no
significant maintenance burden from that. I don't see a reason to be
harsher on the krb5 case.

The real problem in my mind is this business of the gssapi and krb5
support being mutually exclusive. That is going to cause tremendous
pain because there won't be any convenient upgrade path. Particularly
not for users of binary packages (RPMs etc) --- they'll be screwed
if their packager changes, and have no way to upgrade if he doesn't.
This needs to be fixed.

Non, GSSAPI and krb5 are *not* mutually exclusive.

SSPI and GSSAPI are mutually exclusive.

You can use krb5 and GSSAPI or krb5 and SSPI just fine.

//Magnus

Magnus Hagander <magnus@hagander.net> 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?

regards, tom lane