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 anything that gssapi doesn't.
* krb5 authentication doesn't follow a published standard. It follows API
examples from MIT later copied by Heimdal, but there is no documented
standard.
* krb5 authentication operates directly on the socket and as such violates
the libpq protocol. This means it's not protected by SSL if you have SSL on
your connection, and that it may misbehave with async sockets.


This was actually on the agenda when we first talked about doig gssapi, but
now that we have it it's time to bring it up again...

Comments?

//Magnus


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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 broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly