Deprecations in authentication

Started by Magnus Haganderabout 13 years ago35 messages
#1Magnus Hagander
magnus@hagander.net

Since Simon stirred up a hornets nest suggesting deprecation of a
number of features, I figured I'd take it one step further and suggest
removal of some previously deprecated features :)

In particular, we made a couple of changes over sveral releases back
in the authentication config, that we should perhaps consider
finishing by removing the old stuff now?

1. krb5 authentication. We've had gssapi since 8.3 (which means in all
supported versions). krb5 has been deprecated, also since 8.3. Time to
remove it?

2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
syntax deprecated but still mapping to the new one. Has it been there
long enough that we should start throwing an error for ident on unix?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#2Simon Riggs
simon@2ndQuadrant.com
In reply to: Magnus Hagander (#1)
Re: Deprecations in authentication

On 18 October 2012 12:20, Magnus Hagander <magnus@hagander.net> wrote:

2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
syntax deprecated but still mapping to the new one. Has it been there
long enough that we should start throwing an error for ident on unix?

Any reason to remove? Having two names for same thing is a happy place
for users with bad/fond memories. It costs little and no errors are
associated with using the old name (are there?).

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

#3Magnus Hagander
magnus@hagander.net
In reply to: Simon Riggs (#2)
Re: Deprecations in authentication

On Thu, Oct 18, 2012 at 1:32 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

On 18 October 2012 12:20, Magnus Hagander <magnus@hagander.net> wrote:

2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
syntax deprecated but still mapping to the new one. Has it been there
long enough that we should start throwing an error for ident on unix?

Any reason to remove? Having two names for same thing is a happy place
for users with bad/fond memories. It costs little and no errors are
associated with using the old name (are there?).

The only real reason for that one would be confusion. e.g. using ident
over tcp is for most people very insecure, whereas ident over unix
sockets is very secure. there are exceptions to both those, but for
the majority of cases we are using the same name for one thing that
has very good security and one that has very bad. And confusion when
it comes to security is usually not a good thing.

The krb5 one is more about maintaining code, but there is not much
cost to keeping ident-over-unix, that's true.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#4Simon Riggs
simon@2ndQuadrant.com
In reply to: Magnus Hagander (#3)
Re: Deprecations in authentication

On 18 October 2012 12:37, Magnus Hagander <magnus@hagander.net> wrote:

On Thu, Oct 18, 2012 at 1:32 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

On 18 October 2012 12:20, Magnus Hagander <magnus@hagander.net> wrote:

2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
syntax deprecated but still mapping to the new one. Has it been there
long enough that we should start throwing an error for ident on unix?

Any reason to remove? Having two names for same thing is a happy place
for users with bad/fond memories. It costs little and no errors are
associated with using the old name (are there?).

The only real reason for that one would be confusion. e.g. using ident
over tcp is for most people very insecure, whereas ident over unix
sockets is very secure. there are exceptions to both those, but for
the majority of cases we are using the same name for one thing that
has very good security and one that has very bad. And confusion when
it comes to security is usually not a good thing.

I'll go with that.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

#5Simon Riggs
simon@2ndquadrant.com
In reply to: Magnus Hagander (#1)
Re: Deprecations in authentication

On 18 October 2012 12:20, Magnus Hagander <magnus@hagander.net> wrote:

Since Simon stirred up a hornets nest suggesting deprecation of a
number of features, I figured I'd take it one step further and suggest
removal of some previously deprecated features :)

I'm laughing at the analogy that angry and unintelligent agents
responded to my proposals, but there was no stirring action from me.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

#6Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Simon Riggs (#5)
Re: Deprecations in authentication

Simon Riggs wrote:

On 18 October 2012 12:20, Magnus Hagander <magnus@hagander.net> wrote:

Since Simon stirred up a hornets nest suggesting deprecation of a
number of features, I figured I'd take it one step further and suggest
removal of some previously deprecated features :)

I'm laughing at the analogy that angry and unintelligent agents
responded to my proposals, but there was no stirring action from me.

We may all be stupid individually, but it's the swarm that matters.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

#7Simon Riggs
simon@2ndQuadrant.com
In reply to: Simon Riggs (#5)
Re: Deprecations in authentication

On 18 October 2012 12:43, Simon Riggs <simon@2ndquadrant.com> wrote:

On 18 October 2012 12:20, Magnus Hagander <magnus@hagander.net> wrote:

Since Simon stirred up a hornets nest suggesting deprecation of a
number of features, I figured I'd take it one step further and suggest
removal of some previously deprecated features :)

I'm laughing at the analogy that angry and unintelligent agents
responded to my proposals, but there was no stirring action from me.

Hmm, this looks like a stirring action in itself, so I withdraw and apologise.

You are right that some people are angry and so IMHO it was wrong of
me to try to joke about that. My point was only that I had acted in
good faith, rather than to deliberately cause annoyance.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

#8Robert Haas
robertmhaas@gmail.com
In reply to: Magnus Hagander (#1)
Re: Deprecations in authentication

On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander <magnus@hagander.net> wrote:

Since Simon stirred up a hornets nest suggesting deprecation of a
number of features, I figured I'd take it one step further and suggest
removal of some previously deprecated features :)

In particular, we made a couple of changes over sveral releases back
in the authentication config, that we should perhaps consider
finishing by removing the old stuff now?

1. krb5 authentication. We've had gssapi since 8.3 (which means in all
supported versions). krb5 has been deprecated, also since 8.3. Time to
remove it?

That seems like a sufficiently long deprecation window, but is gssapi
a full substitute for krb5? I don't really have a strong opinion on
this, not being a user myself.

2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
syntax deprecated but still mapping to the new one. Has it been there
long enough that we should start throwing an error for ident on unix?

Definitely not. I see no reason to change that, well, really ever.
But certainly not after just two releases. It seems to me like a
useful convenience that does no real harm.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#9Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#8)
Re: Deprecations in authentication

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander <magnus@hagander.net> wrote:

2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
syntax deprecated but still mapping to the new one. Has it been there
long enough that we should start throwing an error for ident on unix?

Definitely not. I see no reason to change that, well, really ever.
But certainly not after just two releases. It seems to me like a
useful convenience that does no real harm.

I think the argument that it causes user confusion is a fairly strong
one, though.

regards, tom lane

#10Joshua D. Drake
jd@commandprompt.com
In reply to: Simon Riggs (#5)
Re: Deprecations in authentication

On 10/18/2012 04:43 AM, Simon Riggs wrote:

On 18 October 2012 12:20, Magnus Hagander <magnus@hagander.net> wrote:

Since Simon stirred up a hornets nest suggesting deprecation of a
number of features, I figured I'd take it one step further and suggest
removal of some previously deprecated features :)

I'm laughing at the analogy that angry and unintelligent agents
responded to my proposals, but there was no stirring action from me.

I believe the stirring occurred when you dropped the idea in the
proverbial bucket. It is not possible to drop even the tiniest pebble
into any ideology of our community without some plague causing flying
insects swarming just in case. You and I, included.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579

#11Peter Eisentraut
peter_e@gmx.net
In reply to: Magnus Hagander (#1)
Re: Deprecations in authentication

On Thu, 2012-10-18 at 13:20 +0200, Magnus Hagander wrote:

In particular, we made a couple of changes over sveral releases back
in the authentication config, that we should perhaps consider
finishing by removing the old stuff now?

1. krb5 authentication. We've had gssapi since 8.3 (which means in all
supported versions). krb5 has been deprecated, also since 8.3. Time to
remove it?

2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
syntax deprecated but still mapping to the new one. Has it been there
long enough that we should start throwing an error for ident on unix?

The hba syntax changes between 8.3 and 8.4 continue to annoy me to this
day, so I'd like to avoid these in the future, especially if they are
for mostly cosmetic reasons. I think any change should be backward
compatible to all supported versions, or alternatively to 8.4, since
that's incompatible with 8.3 anyway. (Those two will be the same before
9.3 goes out.)

So, in my opinion, krb5 could be removed, assuming that gssapi is a full
substitute. But ident-over-unix-sockets should stay, at least until 9.0
is EOL.

#12Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#9)
Re: Deprecations in authentication

On Thu, 2012-10-18 at 12:38 -0400, Tom Lane wrote:

I think the argument that it causes user confusion is a fairly strong
one, though.

What is confusing, IMO, is changing the hba syntax all the time.

#13Magnus Hagander
magnus@hagander.net
In reply to: Robert Haas (#8)
Re: Deprecations in authentication

On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander <magnus@hagander.net> wrote:

Since Simon stirred up a hornets nest suggesting deprecation of a
number of features, I figured I'd take it one step further and suggest
removal of some previously deprecated features :)

In particular, we made a couple of changes over sveral releases back
in the authentication config, that we should perhaps consider
finishing by removing the old stuff now?

1. krb5 authentication. We've had gssapi since 8.3 (which means in all
supported versions). krb5 has been deprecated, also since 8.3. Time to
remove it?

That seems like a sufficiently long deprecation window, but is gssapi
a full substitute for krb5? I don't really have a strong opinion on
this, not being a user myself.

I'm pretty sure that it is.

Stephen, you usually have comments about the Kerberos stuff - want to
comment on this one? :)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#14Stephen Frost
sfrost@snowman.net
In reply to: Magnus Hagander (#13)
Re: Deprecations in authentication

Magnus, all,

* Magnus Hagander (magnus@hagander.net) wrote:

On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:

That seems like a sufficiently long deprecation window, but is gssapi
a full substitute for krb5? I don't really have a strong opinion on
this, not being a user myself.

I'm pretty sure that it is.

Stephen, you usually have comments about the Kerberos stuff - want to
comment on this one? :)

The biggest risk that I can think of regarding deprecating krb5 would be
platforms (if any still exist...) which don't have GSSAPI. Is it
possible to see that from the buildfarm information or from the
configure results that people have for any strange/different platforms
out there? The other question would be if we think anyone's actually
using krb5 on those platforms and/or would people in those situations be
willing/able to move to a different library which supports GSSAPI.

I'm all for deprecating krb5 myself, but I wouldn't want to break things
for people without good cause.

Thanks,

Stephen

#15Magnus Hagander
magnus@hagander.net
In reply to: Stephen Frost (#14)
Re: Deprecations in authentication

On Mon, Oct 22, 2012 at 4:24 PM, Stephen Frost <sfrost@snowman.net> wrote:

Magnus, all,

* Magnus Hagander (magnus@hagander.net) wrote:

On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas <robertmhaas@gmail.com>

wrote:

That seems like a sufficiently long deprecation window, but is gssapi
a full substitute for krb5? I don't really have a strong opinion on
this, not being a user myself.

I'm pretty sure that it is.

Stephen, you usually have comments about the Kerberos stuff - want to
comment on this one? :)

The biggest risk that I can think of regarding deprecating krb5 would be
platforms (if any still exist...) which don't have GSSAPI. Is it

I have no idea what platform that would be. Both the standard
implementations of krb5 have supported gssapi since forever. The only
nonstandard environment we support there is Windows, and that one *only*
has support for GSSAPI/SSPI.

possible to see that from the buildfarm information or from the
configure results that people have for any strange/different platforms
out there? The other question would be if we think anyone's actually

Well, we can remove it and see if it breaks :)

using krb5 on those platforms and/or would people in those situations be
willing/able to move to a different library which supports GSSAPI.

I'm all for deprecating krb5 myself, but I wouldn't want to break things
for people without good cause.

It's been deprecated for *years*. This is about removing it.

The cause would be to keep the code clean and less maintenance of security
code in general, is a good thing.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#16Stephen Frost
sfrost@snowman.net
In reply to: Magnus Hagander (#15)
Re: Deprecations in authentication

Magnus,

* Magnus Hagander (magnus@hagander.net) wrote:

I have no idea what platform that would be. Both the standard
implementations of krb5 have supported gssapi since forever. The only
nonstandard environment we support there is Windows, and that one *only*
has support for GSSAPI/SSPI.

There are some older unixes that had their own Kerberos libraries,
that's what I was specifically referring to. I agree that there's
really only 2 implementations among the major free/open source
distributions and that those have supported GSSAPI for a long time.

Well, we can remove it and see if it breaks :)

That was more-or-less what I was encouraging.. :D

The only question there is if we're even building w/ krb5 and/or
gssapi support on the buildfarm by default today..?

Thanks,

Stephen

#17Robert Haas
robertmhaas@gmail.com
In reply to: Stephen Frost (#16)
Re: Deprecations in authentication

On Mon, Nov 5, 2012 at 9:57 AM, Stephen Frost <sfrost@snowman.net> wrote:

Magnus,

* Magnus Hagander (magnus@hagander.net) wrote:

I have no idea what platform that would be. Both the standard
implementations of krb5 have supported gssapi since forever. The only
nonstandard environment we support there is Windows, and that one *only*
has support for GSSAPI/SSPI.

There are some older unixes that had their own Kerberos libraries,
that's what I was specifically referring to. I agree that there's
really only 2 implementations among the major free/open source
distributions and that those have supported GSSAPI for a long time.

Well, we can remove it and see if it breaks :)

That was more-or-less what I was encouraging.. :D

The only question there is if we're even building w/ krb5 and/or
gssapi support on the buildfarm by default today..?

Well, looking at the BF:

http://www.pgbuildfarm.org/cgi-bin/show_status.pl

...it seems there are LOTS of machines building with krb5, and NONE with gssapi.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#18Magnus Hagander
magnus@hagander.net
In reply to: Robert Haas (#17)
Re: Deprecations in authentication

On Mon, Nov 5, 2012 at 6:10 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Mon, Nov 5, 2012 at 9:57 AM, Stephen Frost <sfrost@snowman.net> wrote:

Magnus,

* Magnus Hagander (magnus@hagander.net) wrote:

I have no idea what platform that would be. Both the standard
implementations of krb5 have supported gssapi since forever. The only
nonstandard environment we support there is Windows, and that one *only*
has support for GSSAPI/SSPI.

There are some older unixes that had their own Kerberos libraries,
that's what I was specifically referring to. I agree that there's
really only 2 implementations among the major free/open source
distributions and that those have supported GSSAPI for a long time.

Well, we can remove it and see if it breaks :)

That was more-or-less what I was encouraging.. :D

The only question there is if we're even building w/ krb5 and/or
gssapi support on the buildfarm by default today..?

Well, looking at the BF:

http://www.pgbuildfarm.org/cgi-bin/show_status.pl

...it seems there are LOTS of machines building with krb5, and NONE with
gssapi.

AFAICS there is no icon for gssapi. So your first statement is correct, but
the second one isn't.

That said, if we don't have animals building with gssapi, that's a problem
regardless of what we're doing here. What's the easiest way to make that
happen?

And can we get stats somehow of how many actually do build with gssapi even
though there is no icon for it? Andrew?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#19Peter Eisentraut
peter_e@gmx.net
In reply to: Magnus Hagander (#18)
Re: Deprecations in authentication

On 11/5/12 12:13 PM, Magnus Hagander wrote:

AFAICS there is no icon for gssapi. So your first statement is correct,
but the second one isn't.

Yeah, for example it's used here:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=smew&amp;dt=2012-11-02%2011%3A38%3A04

#20Andrew Dunstan
andrew@dunslane.net
In reply to: Magnus Hagander (#18)
Re: Deprecations in authentication

On 11/05/2012 12:13 PM, Magnus Hagander wrote:

http://www.pgbuildfarm.org/cgi-bin/show_status.pl

...it seems there are LOTS of machines building with krb5, and
NONE with gssapi.

AFAICS there is no icon for gssapi. So your first statement is
correct, but the second one isn't.

If someone would like to give me an icon I'll add it.

cheers

andrew

#21Magnus Hagander
magnus@hagander.net
In reply to: Andrew Dunstan (#20)
Re: Deprecations in authentication

On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 11/05/2012 12:13 PM, Magnus Hagander wrote:

http://www.pgbuildfarm.org/**cgi-bin/show_status.pl&lt;http://www.pgbuildfarm.org/cgi-bin/show_status.pl&gt;

...it seems there are LOTS of machines building with krb5, and
NONE with gssapi.

AFAICS there is no icon for gssapi. So your first statement is correct,
but the second one isn't.

If someone would like to give me an icon I'll add it.

Well, if we're removing krb5 we could reuse that one :)

And no, I don't have any good ideas icon-wise to distinct gssapi from
krb5...

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#22Andrew Dunstan
andrew@dunslane.net
In reply to: Magnus Hagander (#21)
Re: Deprecations in authentication

On 11/05/2012 01:53 PM, Magnus Hagander wrote:

On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan <andrew@dunslane.net
<mailto:andrew@dunslane.net>> wrote:

On 11/05/2012 12:13 PM, Magnus Hagander wrote:

http://www.pgbuildfarm.org/cgi-bin/show_status.pl

...it seems there are LOTS of machines building with krb5, and
NONE with gssapi.

AFAICS there is no icon for gssapi. So your first statement is
correct, but the second one isn't.

If someone would like to give me an icon I'll add it.

Well, if we're removing krb5 we could reuse that one :)

And no, I don't have any good ideas icon-wise to distinct gssapi from
krb5...

OK, I have added one - it's the same as krb5 but red.

cheers

andrew

#23Magnus Hagander
magnus@hagander.net
In reply to: Andrew Dunstan (#22)
Re: Deprecations in authentication

On Mon, Nov 5, 2012 at 10:21 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 11/05/2012 01:53 PM, Magnus Hagander wrote:

On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan <andrew@dunslane.net<mailto:
andrew@dunslane.net>> wrote:

On 11/05/2012 12:13 PM, Magnus Hagander wrote:

http://www.pgbuildfarm.org/**cgi-bin/show_status.pl&lt;http://www.pgbuildfarm.org/cgi-bin/show_status.pl&gt;

...it seems there are LOTS of machines building with krb5, and
NONE with gssapi.

AFAICS there is no icon for gssapi. So your first statement is
correct, but the second one isn't.

If someone would like to give me an icon I'll add it.

Well, if we're removing krb5 we could reuse that one :)

And no, I don't have any good ideas icon-wise to distinct gssapi from
krb5...

OK, I have added one - it's the same as krb5 but red.

Thanks.

Is there something we can do to get more animals to build with it by
default, or is that something that each individual animal-owner has to
change?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#24Andrew Dunstan
andrew@dunslane.net
In reply to: Magnus Hagander (#23)
Re: Deprecations in authentication

On 11/05/2012 04:54 PM, Magnus Hagander wrote:

On Mon, Nov 5, 2012 at 10:21 PM, Andrew Dunstan <andrew@dunslane.net
<mailto:andrew@dunslane.net>> wrote:

On 11/05/2012 01:53 PM, Magnus Hagander wrote:

On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan
<andrew@dunslane.net <mailto:andrew@dunslane.net>
<mailto:andrew@dunslane.net <mailto:andrew@dunslane.net>>> wrote:

On 11/05/2012 12:13 PM, Magnus Hagander wrote:

http://www.pgbuildfarm.org/cgi-bin/show_status.pl

...it seems there are LOTS of machines building
with krb5, and
NONE with gssapi.

AFAICS there is no icon for gssapi. So your first
statement is
correct, but the second one isn't.

If someone would like to give me an icon I'll add it.

Well, if we're removing krb5 we could reuse that one :)

And no, I don't have any good ideas icon-wise to distinct
gssapi from krb5...

OK, I have added one - it's the same as krb5 but red.

Thanks.

Is there something we can do to get more animals to build with it by
default, or is that something that each individual animal-owner has to
change?

Well, I can add change the defaults in the sample config file which will
be picked up in the new release later this week. And we can ask existing
owners on the owners' mailing list.

cheers

andrew

#25Peter Eisentraut
peter_e@gmx.net
In reply to: Magnus Hagander (#1)
Re: Deprecations in authentication

On 10/18/12, 7:20 AM, Magnus Hagander wrote:

1. krb5 authentication. We've had gssapi since 8.3 (which means in all
supported versions). krb5 has been deprecated, also since 8.3. Time to
remove it?

OS X Mavericks has now marked just about everything in krb5.h as
deprecated, leading to compiler warnings. Which reminded me of this
thread. Maybe it's time.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#26Magnus Hagander
magnus@hagander.net
In reply to: Peter Eisentraut (#25)
Re: Deprecations in authentication

On Thu, Oct 24, 2013 at 8:35 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

On 10/18/12, 7:20 AM, Magnus Hagander wrote:

1. krb5 authentication. We've had gssapi since 8.3 (which means in all
supported versions). krb5 has been deprecated, also since 8.3. Time to
remove it?

OS X Mavericks has now marked just about everything in krb5.h as
deprecated, leading to compiler warnings. Which reminded me of this
thread. Maybe it's time.

Yeah, it's still sitting on my TODO to get done for 9.4. I guess
that's another reason...

They're not causing compiler warnings when you just build with gssapi,
correct? Only if you enable the native krb5?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#27Peter Eisentraut
peter_e@gmx.net
In reply to: Magnus Hagander (#26)
Re: Deprecations in authentication

On 10/24/13, 2:37 PM, Magnus Hagander wrote:

They're not causing compiler warnings when you just build with gssapi,
correct? Only if you enable the native krb5?

Well, actually I was just about to reply that gssapi is also deprecated.
They want you to use some framework instead.

That's something we'll have to look into at some point, if we want to
support gssapi on this platform in the future.

The issue about removing krb5 is valid independent of this, I think.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#28Peter Eisentraut
peter_e@gmx.net
In reply to: Magnus Hagander (#26)
Re: Deprecations in authentication

On Thu, 2013-10-24 at 20:37 +0200, Magnus Hagander wrote:

On Thu, Oct 24, 2013 at 8:35 PM, Peter Eisentraut <peter_e@gmx.net>
wrote:

On 10/18/12, 7:20 AM, Magnus Hagander wrote:

1. krb5 authentication. We've had gssapi since 8.3 (which means in

all

supported versions). krb5 has been deprecated, also since 8.3. Time

to

remove it?

OS X Mavericks has now marked just about everything in krb5.h as
deprecated, leading to compiler warnings. Which reminded me of this
thread. Maybe it's time.

Yeah, it's still sitting on my TODO to get done for 9.4. I guess
that's another reason...

Are you still planning to do this?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#29Magnus Hagander
magnus@hagander.net
In reply to: Peter Eisentraut (#28)
Re: Deprecations in authentication

On Sat, Jan 11, 2014 at 9:45 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

On Thu, 2013-10-24 at 20:37 +0200, Magnus Hagander wrote:

On Thu, Oct 24, 2013 at 8:35 PM, Peter Eisentraut <peter_e@gmx.net>
wrote:

On 10/18/12, 7:20 AM, Magnus Hagander wrote:

1. krb5 authentication. We've had gssapi since 8.3 (which means in

all

supported versions). krb5 has been deprecated, also since 8.3. Time

to

remove it?

OS X Mavericks has now marked just about everything in krb5.h as
deprecated, leading to compiler warnings. Which reminded me of this
thread. Maybe it's time.

Yeah, it's still sitting on my TODO to get done for 9.4. I guess
that's another reason...

Are you still planning to do this?

I am. So I really need to pick up the ball on that :S

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#30Magnus Hagander
magnus@hagander.net
In reply to: Magnus Hagander (#29)
1 attachment(s)
Re: Deprecations in authentication

On Sun, Jan 12, 2014 at 4:35 PM, Magnus Hagander <magnus@hagander.net>wrote:

On Sat, Jan 11, 2014 at 9:45 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

On Thu, 2013-10-24 at 20:37 +0200, Magnus Hagander wrote:

On Thu, Oct 24, 2013 at 8:35 PM, Peter Eisentraut <peter_e@gmx.net>
wrote:

On 10/18/12, 7:20 AM, Magnus Hagander wrote:

1. krb5 authentication. We've had gssapi since 8.3 (which means in

all

supported versions). krb5 has been deprecated, also since 8.3. Time

to

remove it?

OS X Mavericks has now marked just about everything in krb5.h as
deprecated, leading to compiler warnings. Which reminded me of this
thread. Maybe it's time.

Yeah, it's still sitting on my TODO to get done for 9.4. I guess
that's another reason...

Are you still planning to do this?

I am. So I really need to pick up the ball on that :S

Here's a patch that removes the deprecated krb5 authentication, and leaves
just GSSAPI.

I haven't actually tested GSSAPI *working* after this as my krb env is
broken, but it does compile. And I don't see why the workings should be
affected. But if somebody with a working GSSAPI environment could test it,
that would be much appreciated (I'll get mine fixed of course, but right
now I'd like to get it on the buildfarm sooner rather than later to pick up
build issues).

The large changes to the docs is sections moved with copy/paste from the
old kerberos section to the gssapi section - I didn't rewrite that much
docs :)

One thing I noticed - in MSVC, the config parameter "krb5" (equivalent of
the removed --with-krb5) enabled *both* krb5 and gssapi, and there is no
separate config parameter for gssapi. Do we want to rename that one to
"gss", or do we want to keep it as "krb5"? Renaming it would break
otherwise working environments, but it's kind of weird to leave it...
There's already a "GetFakeConfigure" function there that does the wrong
thing.

I think we should rename it, but I wanted to raise the issue for discussion.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Attachments:

remove_krb5.patchtext/x-patch; charset=US-ASCII; name=remove_krb5.patchDownload
*** a/configure
--- b/configure
***************
*** 817,823 **** with_tclconfig
  with_perl
  with_python
  with_gssapi
- with_krb5
  with_krb_srvnam
  with_pam
  with_ldap
--- 817,822 ----
***************
*** 1502,1509 **** Optional Packages:
    --with-perl             build Perl modules (PL/Perl)
    --with-python           build Python modules (PL/Python)
    --with-gssapi           build with GSSAPI support
!   --with-krb5             build with Kerberos 5 support
!   --with-krb-srvnam=NAME  default service principal name in Kerberos
                            [postgres]
    --with-pam              build with PAM support
    --with-ldap             build with LDAP support
--- 1501,1507 ----
    --with-perl             build Perl modules (PL/Perl)
    --with-python           build Python modules (PL/Python)
    --with-gssapi           build with GSSAPI support
!   --with-krb-srvnam=NAME  default service principal name in Kerberos (GSSAPI)
                            [postgres]
    --with-pam              build with PAM support
    --with-ldap             build with LDAP support
***************
*** 5336,5378 **** fi
  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $with_gssapi" >&5
  $as_echo "$with_gssapi" >&6; }
  
- #
- # Kerberos 5
- #
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to build with Kerberos 5 support" >&5
- $as_echo_n "checking whether to build with Kerberos 5 support... " >&6; }
- 
- 
- 
- # Check whether --with-krb5 was given.
- if test "${with_krb5+set}" = set; then :
-   withval=$with_krb5;
-   case $withval in
-     yes)
- 
- 
- $as_echo "#define KRB5 1" >>confdefs.h
- 
-   krb_srvtab="FILE:\$(sysconfdir)/krb5.keytab"
- 
-       ;;
-     no)
-       :
-       ;;
-     *)
-       as_fn_error $? "no argument expected for --with-krb5 option" "$LINENO" 5
-       ;;
-   esac
- 
- else
-   with_krb5=no
- 
- fi
- 
- 
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $with_krb5" >&5
- $as_echo "$with_krb5" >&6; }
- 
  
  
  
--- 5334,5339 ----
***************
*** 8395,8580 **** fi
    fi
  fi
  
- if test "$with_krb5" = yes ; then
-   if test "$PORTNAME" != "win32"; then
-      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing com_err" >&5
- $as_echo_n "checking for library containing com_err... " >&6; }
- if ${ac_cv_search_com_err+:} false; then :
-   $as_echo_n "(cached) " >&6
- else
-   ac_func_search_save_LIBS=$LIBS
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
- /* end confdefs.h.  */
- 
- /* Override any GCC internal prototype to avoid an error.
-    Use char because int might match the return type of a GCC
-    builtin and then its argument prototype would still apply.  */
- #ifdef __cplusplus
- extern "C"
- #endif
- char com_err ();
- int
- main ()
- {
- return com_err ();
-   ;
-   return 0;
- }
- _ACEOF
- for ac_lib in '' krb5 'krb5 -lcrypto -ldes -lasn1 -lroken' com_err 'com_err -lssl -lcrypto'; do
-   if test -z "$ac_lib"; then
-     ac_res="none required"
-   else
-     ac_res=-l$ac_lib
-     LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
-   fi
-   if ac_fn_c_try_link "$LINENO"; then :
-   ac_cv_search_com_err=$ac_res
- fi
- rm -f core conftest.err conftest.$ac_objext \
-     conftest$ac_exeext
-   if ${ac_cv_search_com_err+:} false; then :
-   break
- fi
- done
- if ${ac_cv_search_com_err+:} false; then :
- 
- else
-   ac_cv_search_com_err=no
- fi
- rm conftest.$ac_ext
- LIBS=$ac_func_search_save_LIBS
- fi
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_com_err" >&5
- $as_echo "$ac_cv_search_com_err" >&6; }
- ac_res=$ac_cv_search_com_err
- if test "$ac_res" != no; then :
-   test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
- 
- else
-   as_fn_error $? "could not find function 'com_err' required for Kerberos 5" "$LINENO" 5
- fi
- 
-      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing krb5_sendauth" >&5
- $as_echo_n "checking for library containing krb5_sendauth... " >&6; }
- if ${ac_cv_search_krb5_sendauth+:} false; then :
-   $as_echo_n "(cached) " >&6
- else
-   ac_func_search_save_LIBS=$LIBS
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
- /* end confdefs.h.  */
- 
- /* Override any GCC internal prototype to avoid an error.
-    Use char because int might match the return type of a GCC
-    builtin and then its argument prototype would still apply.  */
- #ifdef __cplusplus
- extern "C"
- #endif
- char krb5_sendauth ();
- int
- main ()
- {
- return krb5_sendauth ();
-   ;
-   return 0;
- }
- _ACEOF
- for ac_lib in '' krb5 'krb5 -lcrypto -ldes -lasn1 -lroken'; do
-   if test -z "$ac_lib"; then
-     ac_res="none required"
-   else
-     ac_res=-l$ac_lib
-     LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
-   fi
-   if ac_fn_c_try_link "$LINENO"; then :
-   ac_cv_search_krb5_sendauth=$ac_res
- fi
- rm -f core conftest.err conftest.$ac_objext \
-     conftest$ac_exeext
-   if ${ac_cv_search_krb5_sendauth+:} false; then :
-   break
- fi
- done
- if ${ac_cv_search_krb5_sendauth+:} false; then :
- 
- else
-   ac_cv_search_krb5_sendauth=no
- fi
- rm conftest.$ac_ext
- LIBS=$ac_func_search_save_LIBS
- fi
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_krb5_sendauth" >&5
- $as_echo "$ac_cv_search_krb5_sendauth" >&6; }
- ac_res=$ac_cv_search_krb5_sendauth
- if test "$ac_res" != no; then :
-   test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
- 
- else
-   as_fn_error $? "could not find function 'krb5_sendauth' required for Kerberos 5" "$LINENO" 5
- fi
- 
-   else
-      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing com_err" >&5
- $as_echo_n "checking for library containing com_err... " >&6; }
- if ${ac_cv_search_com_err+:} false; then :
-   $as_echo_n "(cached) " >&6
- else
-   ac_func_search_save_LIBS=$LIBS
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
- /* end confdefs.h.  */
- 
- /* Override any GCC internal prototype to avoid an error.
-    Use char because int might match the return type of a GCC
-    builtin and then its argument prototype would still apply.  */
- #ifdef __cplusplus
- extern "C"
- #endif
- char com_err ();
- int
- main ()
- {
- return com_err ();
-   ;
-   return 0;
- }
- _ACEOF
- for ac_lib in '' 'comerr32 -lkrb5_32'; do
-   if test -z "$ac_lib"; then
-     ac_res="none required"
-   else
-     ac_res=-l$ac_lib
-     LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
-   fi
-   if ac_fn_c_try_link "$LINENO"; then :
-   ac_cv_search_com_err=$ac_res
- fi
- rm -f core conftest.err conftest.$ac_objext \
-     conftest$ac_exeext
-   if ${ac_cv_search_com_err+:} false; then :
-   break
- fi
- done
- if ${ac_cv_search_com_err+:} false; then :
- 
- else
-   ac_cv_search_com_err=no
- fi
- rm conftest.$ac_ext
- LIBS=$ac_func_search_save_LIBS
- fi
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_com_err" >&5
- $as_echo "$ac_cv_search_com_err" >&6; }
- ac_res=$ac_cv_search_com_err
- if test "$ac_res" != no; then :
-   test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
- 
- else
-   as_fn_error $? "could not find function 'com_err' required for Kerberos 5" "$LINENO" 5
- fi
- 
-   fi
- fi
- 
  if test "$with_openssl" = yes ; then
      if test "$PORTNAME" != "win32"; then
       { $as_echo "$as_me:${as_lineno-$LINENO}: checking for CRYPTO_new_ex_data in -lcrypto" >&5
--- 8356,8361 ----
***************
*** 9496,9512 **** done
  
  fi
  
- if test "$with_krb5" = yes ; then
-   ac_fn_c_check_header_mongrel "$LINENO" "krb5.h" "ac_cv_header_krb5_h" "$ac_includes_default"
- if test "x$ac_cv_header_krb5_h" = xyes; then :
- 
- else
-   as_fn_error $? "header file <krb5.h> is required for Kerberos 5" "$LINENO" 5
- fi
- 
- 
- fi
- 
  if test "$with_openssl" = yes ; then
    ac_fn_c_check_header_mongrel "$LINENO" "openssl/ssl.h" "ac_cv_header_openssl_ssl_h" "$ac_includes_default"
  if test "x$ac_cv_header_openssl_ssl_h" = xyes; then :
--- 9277,9282 ----
***************
*** 10772,10859 **** fi
  
  fi
  
- if test "$with_krb5" = yes; then
- # Check for differences between MIT and Heimdal (KTH) releases
-   ac_fn_c_check_member "$LINENO" "krb5_ticket" "enc_part2" "ac_cv_member_krb5_ticket_enc_part2" "#include <krb5.h>
- "
- if test "x$ac_cv_member_krb5_ticket_enc_part2" = xyes; then :
- 
- cat >>confdefs.h <<_ACEOF
- #define HAVE_KRB5_TICKET_ENC_PART2 1
- _ACEOF
- 
- 
- else
-   ac_fn_c_check_member "$LINENO" "krb5_ticket" "client" "ac_cv_member_krb5_ticket_client" "#include <krb5.h>
- "
- if test "x$ac_cv_member_krb5_ticket_client" = xyes; then :
- 
- cat >>confdefs.h <<_ACEOF
- #define HAVE_KRB5_TICKET_CLIENT 1
- _ACEOF
- 
- 
- else
-   as_fn_error $? "could not determine how to get client name from Kerberos 5 ticket" "$LINENO" 5
- fi
- 
- fi
- 
-   ac_fn_c_check_member "$LINENO" "krb5_error" "text.data" "ac_cv_member_krb5_error_text_data" "#include <krb5.h>
- "
- if test "x$ac_cv_member_krb5_error_text_data" = xyes; then :
- 
- cat >>confdefs.h <<_ACEOF
- #define HAVE_KRB5_ERROR_TEXT_DATA 1
- _ACEOF
- 
- 
- else
-   ac_fn_c_check_member "$LINENO" "krb5_error" "e_data" "ac_cv_member_krb5_error_e_data" "#include <krb5.h>
- "
- if test "x$ac_cv_member_krb5_error_e_data" = xyes; then :
- 
- cat >>confdefs.h <<_ACEOF
- #define HAVE_KRB5_ERROR_E_DATA 1
- _ACEOF
- 
- 
- else
-   as_fn_error $? "could not determine how to extract Kerberos 5 error messages" "$LINENO" 5
- fi
- 
- fi
- 
- 
- # Win32 requires headers to be loaded for __stdcall, so can't use
- # AC_CHECK_FUNCS here.
-   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for krb5_free_unparsed_name" >&5
- $as_echo_n "checking for krb5_free_unparsed_name... " >&6; }
-   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
- /* end confdefs.h.  */
- #include <krb5.h>
- int
- main ()
- {
- krb5_free_unparsed_name(NULL,NULL);
-   ;
-   return 0;
- }
- _ACEOF
- if ac_fn_c_try_link "$LINENO"; then :
- 
- $as_echo "#define HAVE_KRB5_FREE_UNPARSED_NAME 1" >>confdefs.h
- 
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
- $as_echo "yes" >&6; }
- else
-   { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
- $as_echo "no" >&6; }
- fi
- rm -f core conftest.err conftest.$ac_objext \
-     conftest$ac_exeext conftest.$ac_ext
- fi
- 
  # On PPC, check if assembler supports LWARX instruction's mutex hint bit
  case $host_cpu in
    ppc*|powerpc*)
--- 10542,10547 ----
*** a/configure.in
--- b/configure.in
***************
*** 608,624 **** PGAC_ARG_BOOL(with, gssapi, no, [build with GSSAPI support],
  ])
  AC_MSG_RESULT([$with_gssapi])
  
- #
- # Kerberos 5
- #
- AC_MSG_CHECKING([whether to build with Kerberos 5 support])
- PGAC_ARG_BOOL(with, krb5, no, [build with Kerberos 5 support],
- [
-   AC_DEFINE(KRB5, 1, [Define to build with Kerberos 5 support. (--with-krb5)])
-   krb_srvtab="FILE:\$(sysconfdir)/krb5.keytab"
- ])
- AC_MSG_RESULT([$with_krb5])
- 
  
  AC_SUBST(krb_srvtab)
  
--- 608,613 ----
***************
*** 627,637 **** AC_SUBST(krb_srvtab)
  # Kerberos configuration parameters
  #
  PGAC_ARG_REQ(with, krb-srvnam,
!              [NAME], [default service principal name in Kerberos [postgres]],
               [],
               [with_krb_srvnam="postgres"])
  AC_DEFINE_UNQUOTED([PG_KRB_SRVNAM], ["$with_krb_srvnam"],
!                    [Define to the name of the default PostgreSQL service principal in Kerberos. (--with-krb-srvnam=NAME)])
  
  
  #
--- 616,626 ----
  # Kerberos configuration parameters
  #
  PGAC_ARG_REQ(with, krb-srvnam,
!              [NAME], [default service principal name in Kerberos (GSSAPI) [postgres]],
               [],
               [with_krb_srvnam="postgres"])
  AC_DEFINE_UNQUOTED([PG_KRB_SRVNAM], ["$with_krb_srvnam"],
!                    [Define to the name of the default PostgreSQL service principal in Kerberos (GSSAPI). (--with-krb-srvnam=NAME)])
  
  
  #
***************
*** 929,946 **** if test "$with_gssapi" = yes ; then
    fi
  fi
  
- if test "$with_krb5" = yes ; then
-   if test "$PORTNAME" != "win32"; then
-      AC_SEARCH_LIBS(com_err, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken' com_err 'com_err -lssl -lcrypto'], [],
-                     [AC_MSG_ERROR([could not find function 'com_err' required for Kerberos 5])])
-      AC_SEARCH_LIBS(krb5_sendauth, [krb5 'krb5 -lcrypto -ldes -lasn1 -lroken'], [],
-                     [AC_MSG_ERROR([could not find function 'krb5_sendauth' required for Kerberos 5])])
-   else
-      AC_SEARCH_LIBS(com_err, 'comerr32 -lkrb5_32', [],
-                     [AC_MSG_ERROR([could not find function 'com_err' required for Kerberos 5])])
-   fi
- fi
- 
  if test "$with_openssl" = yes ; then
    dnl Order matters!
    if test "$PORTNAME" != "win32"; then
--- 918,923 ----
***************
*** 1061,1070 **** if test "$with_gssapi" = yes ; then
  	[AC_CHECK_HEADERS(gssapi.h, [], [AC_MSG_ERROR([gssapi.h header file is required for GSSAPI])])])
  fi
  
- if test "$with_krb5" = yes ; then
-   AC_CHECK_HEADER(krb5.h, [], [AC_MSG_ERROR([header file <krb5.h> is required for Kerberos 5])])
- fi
- 
  if test "$with_openssl" = yes ; then
    AC_CHECK_HEADER(openssl/ssl.h, [], [AC_MSG_ERROR([header file <openssl/ssl.h> is required for OpenSSL])])
    AC_CHECK_HEADER(openssl/err.h, [], [AC_MSG_ERROR([header file <openssl/err.h> is required for OpenSSL])])
--- 1038,1043 ----
***************
*** 1160,1188 **** Use --without-zlib to disable zlib support.])],
                  [#include <zlib.h>])
  fi
  
- if test "$with_krb5" = yes; then
- # Check for differences between MIT and Heimdal (KTH) releases
-   AC_CHECK_MEMBERS(krb5_ticket.enc_part2, [],
-                    [AC_CHECK_MEMBERS(krb5_ticket.client, [],
-                                      [AC_MSG_ERROR([could not determine how to get client name from Kerberos 5 ticket])],
-                                      [#include <krb5.h>])],
-                    [#include <krb5.h>])
-   AC_CHECK_MEMBERS(krb5_error.text.data, [],
-                    [AC_CHECK_MEMBERS(krb5_error.e_data, [],
-                                      [AC_MSG_ERROR([could not determine how to extract Kerberos 5 error messages])],
-                                      [#include <krb5.h>])],
-                    [#include <krb5.h>])
- 
- # Win32 requires headers to be loaded for __stdcall, so can't use
- # AC_CHECK_FUNCS here.
-   AC_MSG_CHECKING(for krb5_free_unparsed_name)
-   AC_TRY_LINK([#include <krb5.h>],
-               [krb5_free_unparsed_name(NULL,NULL);],
-               [AC_DEFINE(HAVE_KRB5_FREE_UNPARSED_NAME, 1, [Define to 1 if you have krb5_free_unparsed_name.])
- AC_MSG_RESULT(yes)],
-               [AC_MSG_RESULT(no)])
- fi
- 
  # On PPC, check if assembler supports LWARX instruction's mutex hint bit
  case $host_cpu in
    ppc*|powerpc*)
--- 1133,1138 ----
*** a/doc/src/sgml/client-auth.sgml
--- b/doc/src/sgml/client-auth.sgml
***************
*** 451,467 **** hostnossl  <replaceable>database</replaceable>  <replaceable>user</replaceable>
         </varlistentry>
  
         <varlistentry>
-         <term><literal>krb5</></term>
-         <listitem>
-          <para>
-           Use Kerberos V5 to authenticate the user. This is only
-           available for TCP/IP connections.  See <xref
-           linkend="kerberos-auth"> for details.
-          </para>
-         </listitem>
-        </varlistentry>
- 
-        <varlistentry>
          <term><literal>ident</></term>
          <listitem>
           <para>
--- 451,456 ----
***************
*** 650,662 **** host    all             all             .example.com            md5
  
  # In the absence of preceding "host" lines, these two lines will
  # reject all connections from 192.168.54.1 (since that entry will be
! # matched first), but allow Kerberos 5 connections from anywhere else
  # on the Internet.  The zero mask causes no bits of the host IP
  # address to be considered, so it matches any host.
  #
  # TYPE  DATABASE        USER            ADDRESS                 METHOD
  host    all             all             192.168.54.1/32         reject
! host    all             all             0.0.0.0/0               krb5
  
  # Allow users from 192.168.x.x hosts to connect to any database, if
  # they pass the ident check.  If, for example, ident says the user is
--- 639,651 ----
  
  # In the absence of preceding "host" lines, these two lines will
  # reject all connections from 192.168.54.1 (since that entry will be
! # matched first), but allow GSSAPI connections from anywhere else
  # on the Internet.  The zero mask causes no bits of the host IP
  # address to be considered, so it matches any host.
  #
  # TYPE  DATABASE        USER            ADDRESS                 METHOD
  host    all             all             192.168.54.1/32         reject
! host    all             all             0.0.0.0/0               gss
  
  # Allow users from 192.168.x.x hosts to connect to any database, if
  # they pass the ident check.  If, for example, ident says the user is
***************
*** 925,940 **** omicron         bryanh                  guest1
     </para>
  
     <para>
      When <productname>GSSAPI</productname> uses
      <productname>Kerberos</productname>, it uses a standard principal
      in the format
!     <literal><replaceable>servicename</>/<replaceable>hostname</>@<replaceable>realm</></literal>. For information about the parts of the principal, and
!     how to set up the required keys, see <xref linkend="kerberos-auth">.
     </para>
  
     <para>
!     GSSAPI support has to be enabled when <productname>PostgreSQL</> is built;
!     see <xref linkend="installation"> for more information.
     </para>
  
     <para>
--- 914,987 ----
     </para>
  
     <para>
+     GSSAPI support has to be enabled when <productname>PostgreSQL</> is built;
+     see <xref linkend="installation"> for more information.
+    </para>
+ 
+    <para>
      When <productname>GSSAPI</productname> uses
      <productname>Kerberos</productname>, it uses a standard principal
      in the format
!     <literal><replaceable>servicename</>/<replaceable>hostname</>@<replaceable>realm</></literal>.
!     <replaceable>servicename</> can be set on the server side using the
!     <xref linkend="guc-krb-srvname"> configuration parameter, and on the
!     client side using the <literal>krbsrvname</> connection parameter. (See
!     also <xref linkend="libpq-paramkeywords">.) The installation default can be
!     changed from the default <literal>postgres</literal> at build time using
!     <literal>./configure --with-krb-srvnam=</><replaceable>whatever</>.
!     In most environments,
!     this parameter never needs to be changed. However, it is necessary
!     when supporting multiple <productname>PostgreSQL</> installations
!     on the same host.
!     Some Kerberos implementations might also require a different service name,
!     such as Microsoft Active Directory which requires the service name
!     to be in upper case (<literal>POSTGRES</literal>).
!    </para>
!    <para>
!     <replaceable>hostname</> is the fully qualified host name of the
!     server machine. The service principal's realm is the preferred realm
!     of the server machine.
     </para>
  
     <para>
!     Client principals must have their <productname>PostgreSQL</> database user
!     name as their first component, for example
!     <literal>pgusername@realm</>.  Alternatively, you can use a user name
!     mapping to map from the first component of the principal name to the
!     database user name.  By default, the realm of the client is
!     not checked by <productname>PostgreSQL</>. If you have cross-realm
!     authentication enabled and need to verify the realm, use the
!     <literal>krb_realm</> parameter, or enable <literal>include_realm</>
!     and use user name mapping to check the realm.
!    </para>
! 
!    <para>
!     Make sure that your server keytab file is readable (and preferably
!     only readable) by the <productname>PostgreSQL</productname> server
!     account.  (See also <xref linkend="postgres-user">.) The location
!     of the key file is specified by the <xref
!     linkend="guc-krb-server-keyfile"> configuration
!     parameter. The default is
!     <filename>/usr/local/pgsql/etc/krb5.keytab</> (or whatever
!     directory was specified as <varname>sysconfdir</> at build time).
!    </para>
!    <para>
!     The keytab file is generated by the Kerberos software; see the
!     Kerberos documentation for details. The following example is
!    for MIT-compatible Kerberos 5 implementations:
! <screen>
! <prompt>kadmin% </><userinput>ank -randkey postgres/server.my.domain.org</>
! <prompt>kadmin% </><userinput>ktadd -k krb5.keytab postgres/server.my.domain.org</>
! </screen>
!    </para>
! 
!    <para>
!     When connecting to the database make sure you have a ticket for a
!     principal matching the requested database user name. For example, for
!     database user name <literal>fred</>, principal
!     <literal>fred@EXAMPLE.COM</> would be able to connect. To also allow
!     principal <literal>fred/users.example.com@EXAMPLE.COM</>, use a user name
!     map, as described in <xref linkend="auth-username-maps">.
     </para>
  
     <para>
***************
*** 1050,1227 **** omicron         bryanh                  guest1
     </para>
    </sect2>
  
-   <sect2 id="kerberos-auth">
-    <title>Kerberos Authentication</title>
- 
-    <indexterm zone="kerberos-auth">
-     <primary>Kerberos</primary>
-    </indexterm>
- 
-    <note>
-     <para>
-      Native Kerberos authentication has been deprecated and should be used
-      only for backward compatibility. New and upgraded installations are
-      encouraged to use the industry-standard <productname>GSSAPI</productname>
-      authentication method (see <xref linkend="gssapi-auth">) instead.
-     </para>
-    </note>
- 
-    <para>
-     <productname>Kerberos</productname> is an industry-standard secure
-     authentication system suitable for distributed computing over a public
-     network. A description of the <productname>Kerberos</productname> system
-     is beyond the scope of this document; in full generality it can be
-     quite complex (yet powerful). The
-     <ulink url="http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html">
-     Kerberos <acronym>FAQ</></ulink> or
-     <ulink url="http://web.mit.edu/kerberos/www/">MIT Kerberos page</ulink>
-     can be good starting points for exploration.
-     Several sources for <productname>Kerberos</> distributions exist.
-     <productname>Kerberos</productname> provides secure authentication but
-     does not encrypt queries or data passed over the network;  for that
-     use <acronym>SSL</acronym>.
-    </para>
- 
-    <para>
-     <productname>PostgreSQL</> supports Kerberos version 5.  Kerberos
-     support has to be enabled when <productname>PostgreSQL</> is built;
-     see <xref linkend="installation"> for more information.
-    </para>
- 
-    <para>
-     <productname>PostgreSQL</> operates like a normal Kerberos service.
-     The name of the service principal is
-     <literal><replaceable>servicename</>/<replaceable>hostname</>@<replaceable>realm</></literal>.
-    </para>
- 
-    <para>
-     <replaceable>servicename</> can be set on the server side using the
-     <xref linkend="guc-krb-srvname"> configuration parameter, and on the
-     client side using the <literal>krbsrvname</> connection parameter. (See
-     also <xref linkend="libpq-paramkeywords">.) The installation default can be
-     changed from the default <literal>postgres</literal> at build time using
-     <literal>./configure --with-krb-srvnam=</><replaceable>whatever</>.
-     In most environments,
-     this parameter never needs to be changed. However, it is necessary
-     when supporting multiple <productname>PostgreSQL</> installations
-     on the same host.
-     Some Kerberos implementations might also require a different service name,
-     such as Microsoft Active Directory which requires the service name
-     to be in upper case (<literal>POSTGRES</literal>).
-    </para>
- 
-    <para>
-     <replaceable>hostname</> is the fully qualified host name of the
-     server machine. The service principal's realm is the preferred realm
-     of the server machine.
-    </para>
- 
-    <para>
-     Client principals must have their <productname>PostgreSQL</> database user
-     name as their first component, for example
-     <literal>pgusername@realm</>.  Alternatively, you can use a user name
-     mapping to map from the first component of the principal name to the
-     database user name.  By default, the realm of the client is
-     not checked by <productname>PostgreSQL</>. If you have cross-realm
-     authentication enabled and need to verify the realm, use the
-     <literal>krb_realm</> parameter, or enable <literal>include_realm</>
-     and use user name mapping to check the realm.
-    </para>
- 
-    <para>
-     Make sure that your server keytab file is readable (and preferably
-     only readable) by the <productname>PostgreSQL</productname> server
-     account.  (See also <xref linkend="postgres-user">.) The location
-     of the key file is specified by the <xref
-     linkend="guc-krb-server-keyfile"> configuration
-     parameter. The default is
-     <filename>/usr/local/pgsql/etc/krb5.keytab</> (or whatever
-     directory was specified as <varname>sysconfdir</> at build time).
-    </para>
- 
-    <para>
-     The keytab file is generated by the Kerberos software; see the
-     Kerberos documentation for details. The following example is
-    for MIT-compatible Kerberos 5 implementations:
- <screen>
- <prompt>kadmin% </><userinput>ank -randkey postgres/server.my.domain.org</>
- <prompt>kadmin% </><userinput>ktadd -k krb5.keytab postgres/server.my.domain.org</>
- </screen>
-    </para>
- 
-    <para>
-     When connecting to the database make sure you have a ticket for a
-     principal matching the requested database user name. For example, for
-     database user name <literal>fred</>, principal
-     <literal>fred@EXAMPLE.COM</> would be able to connect. To also allow
-     principal <literal>fred/users.example.com@EXAMPLE.COM</>, use a user name
-     map, as described in <xref linkend="auth-username-maps">.
-    </para>
- 
-    <para>
-     If you use <ulink url="http://modauthkerb.sf.net">
-     <application>mod_auth_kerb</application></ulink>
-     and <application>mod_perl</application> on your
-     <productname>Apache</productname> web server, you can use
-     <literal>AuthType KerberosV5SaveCredentials</literal> with a
-     <application>mod_perl</application> script. This gives secure
-     database access over the web, with no additional passwords required.
-    </para>
- 
-    <para>
-     The following configuration options are supported for
-     <productname>Kerberos</productname>:
-     <variablelist>
-      <varlistentry>
-       <term><literal>map</literal></term>
-       <listitem>
-        <para>
-         Allows for mapping between system and database user names. See
-         <xref linkend="auth-username-maps"> for details.
-        </para>
-       </listitem>
-      </varlistentry>
- 
-      <varlistentry>
-       <term><literal>include_realm</literal></term>
-       <listitem>
-        <para>
-         If set to 1, the realm name from the authenticated user
-         principal is included in the system user name that's passed through
-         user name mapping (<xref linkend="auth-username-maps">). This is
-         useful for handling users from multiple realms.
-        </para>
-       </listitem>
-      </varlistentry>
- 
-      <varlistentry>
-       <term><literal>krb_realm</literal></term>
-       <listitem>
-        <para>
-         Sets the realm to match user principal names against. If this parameter
-         is set, only users of that realm will be accepted.  If it is not set,
-         users of any realm can connect, subject to whatever user name mapping
-         is done.
-        </para>
-       </listitem>
-      </varlistentry>
- 
-      <varlistentry>
-       <term><literal>krb_server_hostname</literal></term>
-       <listitem>
-        <para>
-         Sets the host name part of the service principal.
-         This, combined with <varname>krb_srvname</>, is used to generate
-         the complete service principal, that is
-         <varname>krb_srvname</><literal>/</><varname>krb_server_hostname</><literal>@</>REALM.
-         If not set, the default is the server host name.
-        </para>
-       </listitem>
-      </varlistentry>
-     </variablelist>
-    </para>
-   </sect2>
- 
    <sect2 id="auth-ident">
     <title>Ident Authentication</title>
  
--- 1097,1102 ----
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***************
*** 964,970 **** include 'filename'
        <listitem>
         <para>
          Sets the location of the Kerberos server key file. See
!         <xref linkend="kerberos-auth"> or <xref linkend="gssapi-auth">
          for details. This parameter can only be set in the
          <filename>postgresql.conf</> file or on the server command line.
         </para>
--- 964,970 ----
        <listitem>
         <para>
          Sets the location of the Kerberos server key file. See
!         <xref linkend="gssapi-auth">
          for details. This parameter can only be set in the
          <filename>postgresql.conf</> file or on the server command line.
         </para>
***************
*** 978,984 **** include 'filename'
        </indexterm>
        <listitem>
         <para>
!         Sets the Kerberos service name. See <xref linkend="kerberos-auth">
          for details. This parameter can only be set in the
          <filename>postgresql.conf</> file or on the server command line.
         </para>
--- 978,984 ----
        </indexterm>
        <listitem>
         <para>
!         Sets the Kerberos service name. See <xref linkend="gssapi-auth">
          for details. This parameter can only be set in the
          <filename>postgresql.conf</> file or on the server command line.
         </para>
***************
*** 992,998 **** include 'filename'
        </indexterm>
        <listitem>
         <para>
!         Sets whether Kerberos and GSSAPI user names should be treated
          case-insensitively.
          The default is <literal>off</> (case sensitive). This parameter can only be
          set in the <filename>postgresql.conf</> file or on the server command line.
--- 992,998 ----
        </indexterm>
        <listitem>
         <para>
!         Sets whether GSSAPI user names should be treated
          case-insensitively.
          The default is <literal>off</> (case sensitive). This parameter can only be
          set in the <filename>postgresql.conf</> file or on the server command line.
*** a/doc/src/sgml/install-windows.sgml
--- b/doc/src/sgml/install-windows.sgml
***************
*** 269,275 **** $ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
      <varlistentry>
       <term><productname>MIT Kerberos</productname></term>
       <listitem><para>
!       Required for Kerberos authentication support. MIT Kerberos can be
        downloaded from
        <ulink url="http://web.mit.edu/Kerberos/dist/index.html"></>.
       </para></listitem>
--- 269,275 ----
      <varlistentry>
       <term><productname>MIT Kerberos</productname></term>
       <listitem><para>
!       Required for GSSAPI authentication support. MIT Kerberos can be
        downloaded from
        <ulink url="http://web.mit.edu/Kerberos/dist/index.html"></>.
       </para></listitem>
*** a/doc/src/sgml/installation.sgml
--- b/doc/src/sgml/installation.sgml
***************
*** 772,798 **** su - postgres
        </varlistentry>
  
        <varlistentry>
-        <term><option>--with-krb5</option></term>
-        <listitem>
-         <para>
-          Build with support for Kerberos 5 authentication. On many
-          systems, the Kerberos system is not installed in a location
-          that is searched by default (e.g., <filename>/usr/include</>,
-          <filename>/usr/lib</>), so you must use the options
-          <option>--with-includes</> and <option>--with-libraries</> in
-          addition to this option.  <filename>configure</> will check
-          for the required header files and libraries to make sure that
-          your Kerberos installation is sufficient before proceeding.
-         </para>
-        </listitem>
-       </varlistentry>
- 
-       <varlistentry>
         <term><option>--with-krb-srvnam=<replaceable>NAME</></option></term>
         <listitem>
          <para>
!          The default name of the Kerberos service principal (also used
!          by GSSAPI).
           <literal>postgres</literal> is the default. There's usually no
           reason to change this unless you have a Windows environment,
           in which case it must be set to upper case
--- 772,782 ----
        </varlistentry>
  
        <varlistentry>
         <term><option>--with-krb-srvnam=<replaceable>NAME</></option></term>
         <listitem>
          <para>
!          The default name of the Kerberos service principal used
!          by GSSAPI.
           <literal>postgres</literal> is the default. There's usually no
           reason to change this unless you have a Windows environment,
           in which case it must be set to upper case
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
***************
*** 896,902 **** postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
          Using <literal>hostaddr</> instead of <literal>host</> allows the
          application to avoid a host name look-up, which might be important
          in applications with time constraints. However, a host name is
!         required for Kerberos, GSSAPI, or SSPI authentication
          methods, as well as for <literal>verify-full</> SSL
          certificate verification.  The following rules are used:
          <itemizedlist>
--- 896,902 ----
          Using <literal>hostaddr</> instead of <literal>host</> allows the
          application to avoid a host name look-up, which might be important
          in applications with time constraints. However, a host name is
!         required for GSSAPI or SSPI authentication
          methods, as well as for <literal>verify-full</> SSL
          certificate verification.  The following rules are used:
          <itemizedlist>
***************
*** 1331,1341 **** postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
        <term><literal>krbsrvname</literal></term>
        <listitem>
         <para>
!         Kerberos service name to use when authenticating with Kerberos 5
!         or GSSAPI.
          This must match the service name specified in the server
          configuration for Kerberos authentication to succeed. (See also
!         <xref linkend="kerberos-auth"> and <xref linkend="gssapi-auth">.)
         </para>
        </listitem>
       </varlistentry>
--- 1331,1340 ----
        <term><literal>krbsrvname</literal></term>
        <listitem>
         <para>
!         Kerberos service name to use when authenticating with GSSAPI.
          This must match the service name specified in the server
          configuration for Kerberos authentication to succeed. (See also
!         <xref linkend="gssapi-auth">.)
         </para>
        </listitem>
       </varlistentry>
***************
*** 6652,6658 **** myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
        <application>libpq</application> applications will attempt
        authentication  with  servers for this realm and use separate ticket
        files to avoid conflicts with local ticket files.   This
!       environment  variable is only used if Kerberos authentication is
        selected by the server.
       </para>
      </listitem>
--- 6651,6657 ----
        <application>libpq</application> applications will attempt
        authentication  with  servers for this realm and use separate ticket
        files to avoid conflicts with local ticket files.   This
!       environment  variable is only used if GSSAPI authentication is
        selected by the server.
       </para>
      </listitem>
*** a/doc/src/sgml/passwordcheck.sgml
--- b/doc/src/sgml/passwordcheck.sgml
***************
*** 48,54 ****
     module, because in that case it can only try to guess the password.
     For this reason, <filename>passwordcheck</filename> is not
     recommended if your security requirements are high.
!    It is more secure to use an external authentication method such as Kerberos
     (see <xref linkend="client-authentication">) than to rely on
     passwords within the database.
    </para>
--- 48,54 ----
     module, because in that case it can only try to guess the password.
     For this reason, <filename>passwordcheck</filename> is not
     recommended if your security requirements are high.
!    It is more secure to use an external authentication method such as GSSAPI
     (see <xref linkend="client-authentication">) than to rely on
     passwords within the database.
    </para>
*** a/doc/src/sgml/protocol.sgml
--- b/doc/src/sgml/protocol.sgml
***************
*** 271,277 ****
          authentication dialog (not described here, part of the
          Kerberos specification) with the server.  If this is
          successful, the server responds with an AuthenticationOk,
!         otherwise it responds with an ErrorResponse.
         </para>
        </listitem>
       </varlistentry>
--- 271,278 ----
          authentication dialog (not described here, part of the
          Kerberos specification) with the server.  If this is
          successful, the server responds with an AuthenticationOk,
!         otherwise it responds with an ErrorResponse. This is no
!         longer supported. This is not supported any more.
         </para>
        </listitem>
       </varlistentry>
*** a/src/backend/libpq/auth.c
--- b/src/backend/libpq/auth.c
***************
*** 134,162 **** bool		pg_krb_caseins_users;
  
  
  /*----------------------------------------------------------------
-  * MIT Kerberos authentication system - protocol version 5
-  *----------------------------------------------------------------
-  */
- #ifdef KRB5
- static int	pg_krb5_recvauth(Port *port);
- 
- #include <krb5.h>
- /* Some old versions of Kerberos do not include <com_err.h> in <krb5.h> */
- #if !defined(__COM_ERR_H) && !defined(__COM_ERR_H__)
- #include <com_err.h>
- #endif
- /*
-  * Various krb5 state which is not connection specific, and a flag to
-  * indicate whether we have initialised it yet.
-  */
- static int	pg_krb5_initialised;
- static krb5_context pg_krb5_context;
- static krb5_keytab pg_krb5_keytab;
- static krb5_principal pg_krb5_server;
- #endif   /* KRB5 */
- 
- 
- /*----------------------------------------------------------------
   * GSSAPI Authentication
   *----------------------------------------------------------------
   */
--- 134,139 ----
***************
*** 257,265 **** auth_failed(Port *port, int status)
  		case uaImplicitReject:
  			errstr = gettext_noop("authentication failed for user \"%s\": host rejected");
  			break;
- 		case uaKrb5:
- 			errstr = gettext_noop("Kerberos 5 authentication failed for user \"%s\"");
- 			break;
  		case uaTrust:
  			errstr = gettext_noop("\"trust\" authentication failed for user \"%s\"");
  			break;
--- 234,239 ----
***************
*** 497,511 **** ClientAuthentication(Port *port)
  				break;
  			}
  
- 		case uaKrb5:
- #ifdef KRB5
- 			sendAuthRequest(port, AUTH_REQ_KRB5);
- 			status = pg_krb5_recvauth(port);
- #else
- 			Assert(false);
- #endif
- 			break;
- 
  		case uaGSS:
  #ifdef ENABLE_GSS
  			sendAuthRequest(port, AUTH_REQ_GSS);
--- 471,476 ----
***************
*** 735,922 **** recv_and_check_password_packet(Port *port)
  }
  
  
- /*----------------------------------------------------------------
-  * MIT Kerberos authentication system - protocol version 5
-  *----------------------------------------------------------------
-  */
- #ifdef KRB5
- 
- static int
- pg_krb5_init(Port *port)
- {
- 	krb5_error_code retval;
- 	char	   *khostname;
- 
- 	if (pg_krb5_initialised)
- 		return STATUS_OK;
- 
- 	retval = krb5_init_context(&pg_krb5_context);
- 	if (retval)
- 	{
- 		ereport(LOG,
- 				(errmsg("Kerberos initialization returned error %d",
- 						retval)));
- 		com_err("postgres", retval, "while initializing krb5");
- 		return STATUS_ERROR;
- 	}
- 
- 	retval = krb5_kt_resolve(pg_krb5_context, pg_krb_server_keyfile, &pg_krb5_keytab);
- 	if (retval)
- 	{
- 		ereport(LOG,
- 				(errmsg("Kerberos keytab resolving returned error %d",
- 						retval)));
- 		com_err("postgres", retval, "while resolving keytab file \"%s\"",
- 				pg_krb_server_keyfile);
- 		krb5_free_context(pg_krb5_context);
- 		return STATUS_ERROR;
- 	}
- 
- 	/*
- 	 * If no hostname was specified, pg_krb_server_hostname is already NULL.
- 	 * If it's set to blank, force it to NULL.
- 	 */
- 	khostname = port->hba->krb_server_hostname;
- 	if (khostname && khostname[0] == '\0')
- 		khostname = NULL;
- 
- 	retval = krb5_sname_to_principal(pg_krb5_context,
- 									 khostname,
- 									 pg_krb_srvnam,
- 									 KRB5_NT_SRV_HST,
- 									 &pg_krb5_server);
- 	if (retval)
- 	{
- 		ereport(LOG,
- 				(errmsg("Kerberos sname_to_principal(\"%s\", \"%s\") returned error %d",
- 		 khostname ? khostname : "server hostname", pg_krb_srvnam, retval)));
- 		com_err("postgres", retval,
- 		"while getting server principal for server \"%s\" for service \"%s\"",
- 				khostname ? khostname : "server hostname", pg_krb_srvnam);
- 		krb5_kt_close(pg_krb5_context, pg_krb5_keytab);
- 		krb5_free_context(pg_krb5_context);
- 		return STATUS_ERROR;
- 	}
- 
- 	pg_krb5_initialised = 1;
- 	return STATUS_OK;
- }
- 
- 
- /*
-  * pg_krb5_recvauth -- server routine to receive authentication information
-  *					   from the client
-  *
-  * We still need to compare the username obtained from the client's setup
-  * packet to the authenticated name.
-  *
-  * We have our own keytab file because postgres is unlikely to run as root,
-  * and so cannot read the default keytab.
-  */
- static int
- pg_krb5_recvauth(Port *port)
- {
- 	krb5_error_code retval;
- 	int			ret;
- 	krb5_auth_context auth_context = NULL;
- 	krb5_ticket *ticket;
- 	char	   *kusername;
- 	char	   *cp;
- 
- 	ret = pg_krb5_init(port);
- 	if (ret != STATUS_OK)
- 		return ret;
- 
- 	retval = krb5_recvauth(pg_krb5_context, &auth_context,
- 						   (krb5_pointer) & port->sock, pg_krb_srvnam,
- 						   pg_krb5_server, 0, pg_krb5_keytab, &ticket);
- 	if (retval)
- 	{
- 		ereport(LOG,
- 				(errmsg("Kerberos recvauth returned error %d",
- 						retval)));
- 		com_err("postgres", retval, "from krb5_recvauth");
- 		return STATUS_ERROR;
- 	}
- 
- 	/*
- 	 * The "client" structure comes out of the ticket and is therefore
- 	 * authenticated.  Use it to check the username obtained from the
- 	 * postmaster startup packet.
- 	 */
- #if defined(HAVE_KRB5_TICKET_ENC_PART2)
- 	retval = krb5_unparse_name(pg_krb5_context,
- 							   ticket->enc_part2->client, &kusername);
- #elif defined(HAVE_KRB5_TICKET_CLIENT)
- 	retval = krb5_unparse_name(pg_krb5_context,
- 							   ticket->client, &kusername);
- #else
- #error "bogus configuration"
- #endif
- 	if (retval)
- 	{
- 		ereport(LOG,
- 				(errmsg("Kerberos unparse_name returned error %d",
- 						retval)));
- 		com_err("postgres", retval, "while unparsing client name");
- 		krb5_free_ticket(pg_krb5_context, ticket);
- 		krb5_auth_con_free(pg_krb5_context, auth_context);
- 		return STATUS_ERROR;
- 	}
- 
- 	cp = strchr(kusername, '@');
- 	if (cp)
- 	{
- 		/*
- 		 * If we are not going to include the realm in the username that is
- 		 * passed to the ident map, destructively modify it here to remove the
- 		 * realm. Then advance past the separator to check the realm.
- 		 */
- 		if (!port->hba->include_realm)
- 			*cp = '\0';
- 		cp++;
- 
- 		if (port->hba->krb_realm != NULL && strlen(port->hba->krb_realm))
- 		{
- 			/* Match realm against configured */
- 			if (pg_krb_caseins_users)
- 				ret = pg_strcasecmp(port->hba->krb_realm, cp);
- 			else
- 				ret = strcmp(port->hba->krb_realm, cp);
- 
- 			if (ret)
- 			{
- 				elog(DEBUG2,
- 					 "krb5 realm (%s) and configured realm (%s) don't match",
- 					 cp, port->hba->krb_realm);
- 
- 				krb5_free_ticket(pg_krb5_context, ticket);
- 				krb5_auth_con_free(pg_krb5_context, auth_context);
- 				return STATUS_ERROR;
- 			}
- 		}
- 	}
- 	else if (port->hba->krb_realm && strlen(port->hba->krb_realm))
- 	{
- 		elog(DEBUG2,
- 			 "krb5 did not return realm but realm matching was requested");
- 
- 		krb5_free_ticket(pg_krb5_context, ticket);
- 		krb5_auth_con_free(pg_krb5_context, auth_context);
- 		return STATUS_ERROR;
- 	}
- 
- 	ret = check_usermap(port->hba->usermap, port->user_name, kusername,
- 						pg_krb_caseins_users);
- 
- 	krb5_free_ticket(pg_krb5_context, ticket);
- 	krb5_auth_con_free(pg_krb5_context, auth_context);
- 	free(kusername);
- 
- 	return ret;
- }
- #endif   /* KRB5 */
- 
  
  /*----------------------------------------------------------------
   * GSSAPI authentication system
--- 700,705 ----
*** a/src/backend/libpq/hba.c
--- b/src/backend/libpq/hba.c
***************
*** 1177,1188 **** parse_hba_line(List *line, int line_num, char *raw_line)
  		parsedline->auth_method = uaPeer;
  	else if (strcmp(token->string, "password") == 0)
  		parsedline->auth_method = uaPassword;
- 	else if (strcmp(token->string, "krb5") == 0)
- #ifdef KRB5
- 		parsedline->auth_method = uaKrb5;
- #else
- 		unsupauth = "krb5";
- #endif
  	else if (strcmp(token->string, "gss") == 0)
  #ifdef ENABLE_GSS
  		parsedline->auth_method = uaGSS;
--- 1177,1182 ----
***************
*** 1262,1278 **** parse_hba_line(List *line, int line_num, char *raw_line)
  
  	/* Invalid authentication combinations */
  	if (parsedline->conntype == ctLocal &&
- 		parsedline->auth_method == uaKrb5)
- 	{
- 		ereport(LOG,
- 				(errcode(ERRCODE_CONFIG_FILE_ERROR),
- 			 errmsg("krb5 authentication is not supported on local sockets"),
- 				 errcontext("line %d of configuration file \"%s\"",
- 							line_num, HbaFileName)));
- 		return NULL;
- 	}
- 
- 	if (parsedline->conntype == ctLocal &&
  		parsedline->auth_method == uaGSS)
  	{
  		ereport(LOG,
--- 1256,1261 ----
***************
*** 1417,1427 **** parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline, int line_num)
  	{
  		if (hbaline->auth_method != uaIdent &&
  			hbaline->auth_method != uaPeer &&
- 			hbaline->auth_method != uaKrb5 &&
  			hbaline->auth_method != uaGSS &&
  			hbaline->auth_method != uaSSPI &&
  			hbaline->auth_method != uaCert)
! 			INVALID_AUTH_OPTION("map", gettext_noop("ident, peer, krb5, gssapi, sspi, and cert"));
  		hbaline->usermap = pstrdup(val);
  	}
  	else if (strcmp(name, "clientcert") == 0)
--- 1400,1409 ----
  	{
  		if (hbaline->auth_method != uaIdent &&
  			hbaline->auth_method != uaPeer &&
  			hbaline->auth_method != uaGSS &&
  			hbaline->auth_method != uaSSPI &&
  			hbaline->auth_method != uaCert)
! 			INVALID_AUTH_OPTION("map", gettext_noop("ident, peer, gssapi, sspi, and cert"));
  		hbaline->usermap = pstrdup(val);
  	}
  	else if (strcmp(name, "clientcert") == 0)
***************
*** 1578,1602 **** parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline, int line_num)
  		REQUIRE_AUTH_OPTION(uaLDAP, "ldapsuffix", "ldap");
  		hbaline->ldapsuffix = pstrdup(val);
  	}
- 	else if (strcmp(name, "krb_server_hostname") == 0)
- 	{
- 		REQUIRE_AUTH_OPTION(uaKrb5, "krb_server_hostname", "krb5");
- 		hbaline->krb_server_hostname = pstrdup(val);
- 	}
  	else if (strcmp(name, "krb_realm") == 0)
  	{
! 		if (hbaline->auth_method != uaKrb5 &&
! 			hbaline->auth_method != uaGSS &&
  			hbaline->auth_method != uaSSPI)
! 			INVALID_AUTH_OPTION("krb_realm", gettext_noop("krb5, gssapi, and sspi"));
  		hbaline->krb_realm = pstrdup(val);
  	}
  	else if (strcmp(name, "include_realm") == 0)
  	{
! 		if (hbaline->auth_method != uaKrb5 &&
! 			hbaline->auth_method != uaGSS &&
  			hbaline->auth_method != uaSSPI)
! 			INVALID_AUTH_OPTION("include_realm", gettext_noop("krb5, gssapi, and sspi"));
  		if (strcmp(val, "1") == 0)
  			hbaline->include_realm = true;
  		else
--- 1560,1577 ----
  		REQUIRE_AUTH_OPTION(uaLDAP, "ldapsuffix", "ldap");
  		hbaline->ldapsuffix = pstrdup(val);
  	}
  	else if (strcmp(name, "krb_realm") == 0)
  	{
! 		if (hbaline->auth_method != uaGSS &&
  			hbaline->auth_method != uaSSPI)
! 			INVALID_AUTH_OPTION("krb_realm", gettext_noop("gssapi and sspi"));
  		hbaline->krb_realm = pstrdup(val);
  	}
  	else if (strcmp(name, "include_realm") == 0)
  	{
! 		if (hbaline->auth_method != uaGSS &&
  			hbaline->auth_method != uaSSPI)
! 			INVALID_AUTH_OPTION("include_realm", gettext_noop("gssapi and sspi"));
  		if (strcmp(val, "1") == 0)
  			hbaline->include_realm = true;
  		else
*** a/src/backend/libpq/pg_hba.conf.sample
--- b/src/backend/libpq/pg_hba.conf.sample
***************
*** 43,49 ****
  # directly connected to.
  #
  # METHOD can be "trust", "reject", "md5", "password", "gss", "sspi",
! # "krb5", "ident", "peer", "pam", "ldap", "radius" or "cert".  Note that
  # "password" sends passwords in clear text; "md5" is preferred since
  # it sends encrypted passwords.
  #
--- 43,49 ----
  # directly connected to.
  #
  # METHOD can be "trust", "reject", "md5", "password", "gss", "sspi",
! # "ident", "peer", "pam", "ldap", "radius" or "cert".  Note that
  # "password" sends passwords in clear text; "md5" is preferred since
  # it sends encrypted passwords.
  #
*** a/src/bin/initdb/initdb.c
--- b/src/bin/initdb/initdb.c
***************
*** 76,84 **** static const char *auth_methods_host[] = {"trust", "reject", "md5", "password",
  #ifdef ENABLE_SSPI
  	"sspi",
  #endif
- #ifdef KRB5
- 	"krb5",
- #endif
  #ifdef USE_PAM
  	"pam", "pam ",
  #endif
--- 76,81 ----
*** a/src/include/libpq/hba.h
--- b/src/include/libpq/hba.h
***************
*** 20,26 **** typedef enum UserAuth
  {
  	uaReject,
  	uaImplicitReject,
- 	uaKrb5,
  	uaTrust,
  	uaIdent,
  	uaPassword,
--- 20,25 ----
*** a/src/include/libpq/pqcomm.h
--- b/src/include/libpq/pqcomm.h
***************
*** 164,170 **** extern bool Db_user_namespace;
  
  #define AUTH_REQ_OK			0	/* User is authenticated  */
  #define AUTH_REQ_KRB4		1	/* Kerberos V4. Not supported any more. */
! #define AUTH_REQ_KRB5		2	/* Kerberos V5 */
  #define AUTH_REQ_PASSWORD	3	/* Password */
  #define AUTH_REQ_CRYPT		4	/* crypt password. Not supported any more. */
  #define AUTH_REQ_MD5		5	/* md5 password */
--- 164,170 ----
  
  #define AUTH_REQ_OK			0	/* User is authenticated  */
  #define AUTH_REQ_KRB4		1	/* Kerberos V4. Not supported any more. */
! #define AUTH_REQ_KRB5		2	/* Kerberos V5. Not supported any more. */
  #define AUTH_REQ_PASSWORD	3	/* Password */
  #define AUTH_REQ_CRYPT		4	/* crypt password. Not supported any more. */
  #define AUTH_REQ_MD5		5	/* md5 password */
*** a/src/include/pg_config.h.in
--- b/src/include/pg_config.h.in
***************
*** 260,280 ****
  /* Define to 1 if you have isinf(). */
  #undef HAVE_ISINF
  
- /* Define to 1 if `e_data' is a member of `krb5_error'. */
- #undef HAVE_KRB5_ERROR_E_DATA
- 
- /* Define to 1 if `text.data' is a member of `krb5_error'. */
- #undef HAVE_KRB5_ERROR_TEXT_DATA
- 
- /* Define to 1 if you have krb5_free_unparsed_name. */
- #undef HAVE_KRB5_FREE_UNPARSED_NAME
- 
- /* Define to 1 if `client' is a member of `krb5_ticket'. */
- #undef HAVE_KRB5_TICKET_CLIENT
- 
- /* Define to 1 if `enc_part2' is a member of `krb5_ticket'. */
- #undef HAVE_KRB5_TICKET_ENC_PART2
- 
  /* Define to 1 if you have the <langinfo.h> header file. */
  #undef HAVE_LANGINFO_H
  
--- 260,265 ----
*** a/src/include/pg_config.h.win32
--- b/src/include/pg_config.h.win32
***************
*** 193,210 ****
  /* Define to 1 if you have isinf(). */
  #define HAVE_ISINF 1
  
- /* Define to 1 if `e_data' is member of `krb5_error'. */
- /* #undef HAVE_KRB5_ERROR_E_DATA */
- 
- /* Define to 1 if `text.data' is member of `krb5_error'. */
- /* #undef HAVE_KRB5_ERROR_TEXT_DATA */
- 
- /* Define to 1 if `client' is member of `krb5_ticket'. */
- /* #undef HAVE_KRB5_TICKET_CLIENT */
- 
- /* Define to 1 if `enc_part2' is member of `krb5_ticket'. */
- /* #undef HAVE_KRB5_TICKET_ENC_PART2 */
- 
  /* Define to 1 if you have the <langinfo.h> header file. */
  /* #undef HAVE_LANGINFO_H */
  
--- 193,198 ----
*** a/src/interfaces/libpq/fe-auth.c
--- b/src/interfaces/libpq/fe-auth.c
***************
*** 43,300 ****
  #include "libpq/md5.h"
  
  
- #ifdef KRB5
- /*
-  * MIT Kerberos authentication system - protocol version 5
-  */
- 
- #include <krb5.h>
- /* Some old versions of Kerberos do not include <com_err.h> in <krb5.h> */
- #if !defined(__COM_ERR_H) && !defined(__COM_ERR_H__)
- #include <com_err.h>
- #endif
- 
- /*
-  * Heimdal doesn't have a free function for unparsed names. Just pass it to
-  * standard free() which should work in these cases.
-  */
- #ifndef HAVE_KRB5_FREE_UNPARSED_NAME
- static void
- krb5_free_unparsed_name(krb5_context context, char *val)
- {
- 	free(val);
- }
- #endif
- 
- /*
-  * pg_an_to_ln -- return the local name corresponding to an authentication
-  *				  name
-  *
-  * XXX Assumes that the first aname component is the user name.  This is NOT
-  *	   necessarily so, since an aname can actually be something out of your
-  *	   worst X.400 nightmare, like
-  *		  ORGANIZATION=U. C. Berkeley/NAME=Paul M. Aoki@CS.BERKELEY.EDU
-  *	   Note that the MIT an_to_ln code does the same thing if you don't
-  *	   provide an aname mapping database...it may be a better idea to use
-  *	   krb5_an_to_ln, except that it punts if multiple components are found,
-  *	   and we can't afford to punt.
-  *
-  * For WIN32, convert username to lowercase because the Win32 kerberos library
-  * generates tickets with the username as the user entered it instead of as
-  * it is entered in the directory.
-  */
- static char *
- pg_an_to_ln(char *aname)
- {
- 	char	   *p;
- 
- 	if ((p = strchr(aname, '/')) || (p = strchr(aname, '@')))
- 		*p = '\0';
- #ifdef WIN32
- 	for (p = aname; *p; p++)
- 		*p = pg_tolower((unsigned char) *p);
- #endif
- 
- 	return aname;
- }
- 
- 
- /*
-  * Various krb5 state which is not connection specific, and a flag to
-  * indicate whether we have initialised it yet.
-  */
- /*
- static int	pg_krb5_initialised;
- static krb5_context pg_krb5_context;
- static krb5_ccache pg_krb5_ccache;
- static krb5_principal pg_krb5_client;
- static char *pg_krb5_name;
- */
- 
- struct krb5_info
- {
- 	int			pg_krb5_initialised;
- 	krb5_context pg_krb5_context;
- 	krb5_ccache pg_krb5_ccache;
- 	krb5_principal pg_krb5_client;
- 	char	   *pg_krb5_name;
- };
- 
- 
- static int
- pg_krb5_init(PQExpBuffer errorMessage, struct krb5_info * info)
- {
- 	krb5_error_code retval;
- 
- 	if (info->pg_krb5_initialised)
- 		return STATUS_OK;
- 
- 	retval = krb5_init_context(&(info->pg_krb5_context));
- 	if (retval)
- 	{
- 		printfPQExpBuffer(errorMessage,
- 						  "pg_krb5_init: krb5_init_context: %s\n",
- 						  error_message(retval));
- 		return STATUS_ERROR;
- 	}
- 
- 	retval = krb5_cc_default(info->pg_krb5_context, &(info->pg_krb5_ccache));
- 	if (retval)
- 	{
- 		printfPQExpBuffer(errorMessage,
- 						  "pg_krb5_init: krb5_cc_default: %s\n",
- 						  error_message(retval));
- 		krb5_free_context(info->pg_krb5_context);
- 		return STATUS_ERROR;
- 	}
- 
- 	retval = krb5_cc_get_principal(info->pg_krb5_context, info->pg_krb5_ccache,
- 								   &(info->pg_krb5_client));
- 	if (retval)
- 	{
- 		printfPQExpBuffer(errorMessage,
- 						  "pg_krb5_init: krb5_cc_get_principal: %s\n",
- 						  error_message(retval));
- 		krb5_cc_close(info->pg_krb5_context, info->pg_krb5_ccache);
- 		krb5_free_context(info->pg_krb5_context);
- 		return STATUS_ERROR;
- 	}
- 
- 	retval = krb5_unparse_name(info->pg_krb5_context, info->pg_krb5_client, &(info->pg_krb5_name));
- 	if (retval)
- 	{
- 		printfPQExpBuffer(errorMessage,
- 						  "pg_krb5_init: krb5_unparse_name: %s\n",
- 						  error_message(retval));
- 		krb5_free_principal(info->pg_krb5_context, info->pg_krb5_client);
- 		krb5_cc_close(info->pg_krb5_context, info->pg_krb5_ccache);
- 		krb5_free_context(info->pg_krb5_context);
- 		return STATUS_ERROR;
- 	}
- 
- 	info->pg_krb5_name = pg_an_to_ln(info->pg_krb5_name);
- 
- 	info->pg_krb5_initialised = 1;
- 	return STATUS_OK;
- }
- 
- static void
- pg_krb5_destroy(struct krb5_info * info)
- {
- 	krb5_free_principal(info->pg_krb5_context, info->pg_krb5_client);
- 	krb5_cc_close(info->pg_krb5_context, info->pg_krb5_ccache);
- 	krb5_free_unparsed_name(info->pg_krb5_context, info->pg_krb5_name);
- 	krb5_free_context(info->pg_krb5_context);
- }
- 
- 
- /*
-  * pg_krb5_sendauth -- client routine to send authentication information to
-  *					   the server
-  */
- static int
- pg_krb5_sendauth(PGconn *conn)
- {
- 	krb5_error_code retval;
- 	int			ret;
- 	krb5_principal server;
- 	krb5_auth_context auth_context = NULL;
- 	krb5_error *err_ret = NULL;
- 	struct krb5_info info;
- 
- 	info.pg_krb5_initialised = 0;
- 
- 	if (!(conn->pghost && conn->pghost[0] != '\0'))
- 	{
- 		printfPQExpBuffer(&conn->errorMessage,
- 						  libpq_gettext("host name must be specified\n"));
- 		return STATUS_ERROR;
- 	}
- 
- 	ret = pg_krb5_init(&conn->errorMessage, &info);
- 	if (ret != STATUS_OK)
- 		return ret;
- 
- 	retval = krb5_sname_to_principal(info.pg_krb5_context, conn->pghost,
- 									 conn->krbsrvname,
- 									 KRB5_NT_SRV_HST, &server);
- 	if (retval)
- 	{
- 		printfPQExpBuffer(&conn->errorMessage,
- 						  "pg_krb5_sendauth: krb5_sname_to_principal: %s\n",
- 						  error_message(retval));
- 		pg_krb5_destroy(&info);
- 		return STATUS_ERROR;
- 	}
- 
- 	/*
- 	 * libpq uses a non-blocking socket. But kerberos needs a blocking socket,
- 	 * and we have to block somehow to do mutual authentication anyway. So we
- 	 * temporarily make it blocking.
- 	 */
- 	if (!pg_set_block(conn->sock))
- 	{
- 		char		sebuf[256];
- 
- 		printfPQExpBuffer(&conn->errorMessage,
- 						  libpq_gettext("could not set socket to blocking mode: %s\n"), pqStrerror(errno, sebuf, sizeof(sebuf)));
- 		krb5_free_principal(info.pg_krb5_context, server);
- 		pg_krb5_destroy(&info);
- 		return STATUS_ERROR;
- 	}
- 
- 	retval = krb5_sendauth(info.pg_krb5_context, &auth_context,
- 					  (krb5_pointer) & conn->sock, (char *) conn->krbsrvname,
- 						   info.pg_krb5_client, server,
- 						   AP_OPTS_MUTUAL_REQUIRED,
- 						   NULL, 0,		/* no creds, use ccache instead */
- 						   info.pg_krb5_ccache, &err_ret, NULL, NULL);
- 	if (retval)
- 	{
- 		if (retval == KRB5_SENDAUTH_REJECTED && err_ret)
- 		{
- #if defined(HAVE_KRB5_ERROR_TEXT_DATA)
- 			printfPQExpBuffer(&conn->errorMessage,
- 				  libpq_gettext("Kerberos 5 authentication rejected: %*s\n"),
- 							  (int) err_ret->text.length, err_ret->text.data);
- #elif defined(HAVE_KRB5_ERROR_E_DATA)
- 			printfPQExpBuffer(&conn->errorMessage,
- 				  libpq_gettext("Kerberos 5 authentication rejected: %*s\n"),
- 							  (int) err_ret->e_data->length,
- 							  (const char *) err_ret->e_data->data);
- #else
- #error "bogus configuration"
- #endif
- 		}
- 		else
- 		{
- 			printfPQExpBuffer(&conn->errorMessage,
- 							  "krb5_sendauth: %s\n", error_message(retval));
- 		}
- 
- 		if (err_ret)
- 			krb5_free_error(info.pg_krb5_context, err_ret);
- 
- 		ret = STATUS_ERROR;
- 	}
- 
- 	krb5_free_principal(info.pg_krb5_context, server);
- 
- 	if (!pg_set_noblock(conn->sock))
- 	{
- 		char		sebuf[256];
- 
- 		printfPQExpBuffer(&conn->errorMessage,
- 		 libpq_gettext("could not restore nonblocking mode on socket: %s\n"),
- 						  pqStrerror(errno, sebuf, sizeof(sebuf)));
- 		ret = STATUS_ERROR;
- 	}
- 	pg_krb5_destroy(&info);
- 
- 	return ret;
- }
- #endif   /* KRB5 */
- 
  #ifdef ENABLE_GSS
  /*
   * GSSAPI authentication system.
--- 43,48 ----
***************
*** 816,836 **** pg_fe_sendauth(AuthRequest areq, PGconn *conn)
  			return STATUS_ERROR;
  
  		case AUTH_REQ_KRB5:
- #ifdef KRB5
- 			pglock_thread();
- 			if (pg_krb5_sendauth(conn) != STATUS_OK)
- 			{
- 				/* Error message already filled in */
- 				pgunlock_thread();
- 				return STATUS_ERROR;
- 			}
- 			pgunlock_thread();
- 			break;
- #else
  			printfPQExpBuffer(&conn->errorMessage,
  				 libpq_gettext("Kerberos 5 authentication not supported\n"));
  			return STATUS_ERROR;
- #endif
  
  #if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
  		case AUTH_REQ_GSS:
--- 564,572 ----
*** a/src/interfaces/libpq/fe-connect.c
--- b/src/interfaces/libpq/fe-connect.c
***************
*** 278,284 **** static const internalPQconninfoOption PQconninfoOptions[] = {
  		"Require-Peer", "", 10,
  	offsetof(struct pg_conn, requirepeer)},
  
! #if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
  	/* Kerberos and GSSAPI authentication support specifying the service name */
  	{"krbsrvname", "PGKRBSRVNAME", PG_KRB_SRVNAM, NULL,
  		"Kerberos-service-name", "", 20,
--- 278,284 ----
  		"Require-Peer", "", 10,
  	offsetof(struct pg_conn, requirepeer)},
  
! #if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
  	/* Kerberos and GSSAPI authentication support specifying the service name */
  	{"krbsrvname", "PGKRBSRVNAME", PG_KRB_SRVNAM, NULL,
  		"Kerberos-service-name", "", 20,
***************
*** 2823,2829 **** freePGconn(PGconn *conn)
  		free(conn->sslcompression);
  	if (conn->requirepeer)
  		free(conn->requirepeer);
! #if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
  	if (conn->krbsrvname)
  		free(conn->krbsrvname);
  #endif
--- 2823,2829 ----
  		free(conn->sslcompression);
  	if (conn->requirepeer)
  		free(conn->requirepeer);
! #if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
  	if (conn->krbsrvname)
  		free(conn->krbsrvname);
  #endif
*** a/src/interfaces/libpq/libpq-int.h
--- b/src/interfaces/libpq/libpq-int.h
***************
*** 331,337 **** struct pg_conn
  	char	   *sslcrl;			/* certificate revocation list filename */
  	char	   *requirepeer;	/* required peer credentials for local sockets */
  
! #if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
  	char	   *krbsrvname;		/* Kerberos service name */
  #endif
  
--- 331,337 ----
  	char	   *sslcrl;			/* certificate revocation list filename */
  	char	   *requirepeer;	/* required peer credentials for local sockets */
  
! #if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
  	char	   *krbsrvname;		/* Kerberos service name */
  #endif
  
*** a/src/tools/msvc/Solution.pm
--- b/src/tools/msvc/Solution.pm
***************
*** 221,230 **** s{PG_VERSION_STR "[^"]+"}{__STRINGIFY(x) #x\n#define __STRINGIFY2(z) __STRINGIFY
  		}
  		if ($self->{options}->{krb5})
  		{
- 			print O "#define KRB5 1\n";
- 			print O "#define HAVE_KRB5_ERROR_TEXT_DATA 1\n";
- 			print O "#define HAVE_KRB5_TICKET_ENC_PART2 1\n";
- 			print O "#define HAVE_KRB5_FREE_UNPARSED_NAME 1\n";
  			print O "#define ENABLE_GSS 1\n";
  		}
  		if (my $port = $self->{options}->{"--with-pgport"})
--- 221,226 ----
***************
*** 625,631 **** sub GetFakeConfigure
  	$cfg .= ' --with-ossp-uuid' if ($self->{options}->{uuid});
  	$cfg .= ' --with-libxml'    if ($self->{options}->{xml});
  	$cfg .= ' --with-libxslt'   if ($self->{options}->{xslt});
! 	$cfg .= ' --with-krb5'      if ($self->{options}->{krb5});
  	$cfg .= ' --with-tcl'       if ($self->{options}->{tcl});
  	$cfg .= ' --with-perl'      if ($self->{options}->{perl});
  	$cfg .= ' --with-python'    if ($self->{options}->{python});
--- 621,627 ----
  	$cfg .= ' --with-ossp-uuid' if ($self->{options}->{uuid});
  	$cfg .= ' --with-libxml'    if ($self->{options}->{xml});
  	$cfg .= ' --with-libxslt'   if ($self->{options}->{xslt});
! 	$cfg .= ' --with-gssapi'    if ($self->{options}->{krb5});
  	$cfg .= ' --with-tcl'       if ($self->{options}->{tcl});
  	$cfg .= ' --with-perl'      if ($self->{options}->{perl});
  	$cfg .= ' --with-python'    if ($self->{options}->{python});
*** a/src/tools/msvc/config_default.pl
--- b/src/tools/msvc/config_default.pl
***************
*** 15,21 **** our $config = {
  	tcl     => undef,    # --with-tls=<path>
  	perl    => undef,    # --with-perl
  	python  => undef,    # --with-python=<path>
- 	krb5    => undef,    # --with-krb5=<path>
  	openssl => undef,    # --with-ssl=<path>
  	uuid    => undef,    # --with-ossp-uuid
  	xml     => undef,    # --with-libxml=<path>
--- 15,20 ----
#31Tom Lane
tgl@sss.pgh.pa.us
In reply to: Magnus Hagander (#30)
Re: Deprecations in authentication

Magnus Hagander <magnus@hagander.net> writes:

One thing I noticed - in MSVC, the config parameter "krb5" (equivalent of
the removed --with-krb5) enabled *both* krb5 and gssapi, and there is no
separate config parameter for gssapi. Do we want to rename that one to
"gss", or do we want to keep it as "krb5"? Renaming it would break
otherwise working environments, but it's kind of weird to leave it...

+1 for renaming --- anybody who's building with "krb5" and expecting to,
you know, actually *get* krb5 would probably rather find out about this
change at build time instead of down the road a ways.

A compromise position would be to introduce a gss parameter while leaving
krb5 in place as a deprecated (perhaps undocumented?) synonym for it.
But I think that's basically confusing.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#32Magnus Hagander
magnus@hagander.net
In reply to: Tom Lane (#31)
Re: Deprecations in authentication

On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

One thing I noticed - in MSVC, the config parameter "krb5" (equivalent of
the removed --with-krb5) enabled *both* krb5 and gssapi, and there is no
separate config parameter for gssapi. Do we want to rename that one to
"gss", or do we want to keep it as "krb5"? Renaming it would break
otherwise working environments, but it's kind of weird to leave it...

+1 for renaming --- anybody who's building with "krb5" and expecting to,
you know, actually *get* krb5 would probably rather find out about this
change at build time instead of down the road a ways.

A compromise position would be to introduce a gss parameter while leaving
krb5 in place as a deprecated (perhaps undocumented?) synonym for it.
But I think that's basically confusing.

Yeah, I'm not sure it actually helps much.

Andrew - is this going to cause any issues wrt the buildfarm, by any chance?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#33Andrew Dunstan
andrew@dunslane.net
In reply to: Magnus Hagander (#32)
Re: Deprecations in authentication

On 01/16/2014 08:01 AM, Magnus Hagander wrote:

On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>> wrote:

Magnus Hagander <magnus@hagander.net <mailto:magnus@hagander.net>>
writes:

One thing I noticed - in MSVC, the config parameter "krb5"

(equivalent of

the removed --with-krb5) enabled *both* krb5 and gssapi, and

there is no

separate config parameter for gssapi. Do we want to rename that

one to

"gss", or do we want to keep it as "krb5"? Renaming it would break
otherwise working environments, but it's kind of weird to leave

it...

+1 for renaming --- anybody who's building with "krb5" and
expecting to,
you know, actually *get* krb5 would probably rather find out about
this
change at build time instead of down the road a ways.

A compromise position would be to introduce a gss parameter while
leaving
krb5 in place as a deprecated (perhaps undocumented?) synonym for it.
But I think that's basically confusing.

Yeah, I'm not sure it actually helps much.

Andrew - is this going to cause any issues wrt the buildfarm, by any
chance?

None of my Windows buildfarm members builds with krb5. Mastodon does,
although it seems to have gone quiet for 16 days (Dave - might be worth
a check). Probably the result of renaming krb5 would be just that the
build would proceed without it. From memory I don't thing the config
settings are sanity checked.

(We need some more, and more modern, Windows buildfarm members.)

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#34Magnus Hagander
magnus@hagander.net
In reply to: Andrew Dunstan (#33)
Re: Deprecations in authentication

On Sat, Jan 18, 2014 at 3:59 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 01/16/2014 08:01 AM, Magnus Hagander wrote:

On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane <tgl@sss.pgh.pa.us <mailto:
tgl@sss.pgh.pa.us>> wrote:

Magnus Hagander <magnus@hagander.net <mailto:magnus@hagander.net>>

writes:

One thing I noticed - in MSVC, the config parameter "krb5"

(equivalent of

the removed --with-krb5) enabled *both* krb5 and gssapi, and

there is no

separate config parameter for gssapi. Do we want to rename that

one to

"gss", or do we want to keep it as "krb5"? Renaming it would break
otherwise working environments, but it's kind of weird to leave

it...

+1 for renaming --- anybody who's building with "krb5" and
expecting to,
you know, actually *get* krb5 would probably rather find out about
this
change at build time instead of down the road a ways.

A compromise position would be to introduce a gss parameter while
leaving
krb5 in place as a deprecated (perhaps undocumented?) synonym for it.
But I think that's basically confusing.

Yeah, I'm not sure it actually helps much.

Andrew - is this going to cause any issues wrt the buildfarm, by any
chance?

None of my Windows buildfarm members builds with krb5. Mastodon does,
although it seems to have gone quiet for 16 days (Dave - might be worth a
check). Probably the result of renaming krb5 would be just that the build
would proceed without it. From memory I don't thing the config settings are
sanity checked.

(We need some more, and more modern, Windows buildfarm members.)

Thanks, pushed with the rename. That'll keep things less confusing going
forward at least :)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

#35Dave Page
dpage@postgresql.org
In reply to: Andrew Dunstan (#33)
Re: Deprecations in authentication

On Sat, Jan 18, 2014 at 2:59 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 01/16/2014 08:01 AM, Magnus Hagander wrote:

On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>> wrote:

Magnus Hagander <magnus@hagander.net <mailto:magnus@hagander.net>>

writes:

One thing I noticed - in MSVC, the config parameter "krb5"

(equivalent of

the removed --with-krb5) enabled *both* krb5 and gssapi, and

there is no

separate config parameter for gssapi. Do we want to rename that

one to

"gss", or do we want to keep it as "krb5"? Renaming it would break
otherwise working environments, but it's kind of weird to leave

it...

+1 for renaming --- anybody who's building with "krb5" and
expecting to,
you know, actually *get* krb5 would probably rather find out about
this
change at build time instead of down the road a ways.

A compromise position would be to introduce a gss parameter while
leaving
krb5 in place as a deprecated (perhaps undocumented?) synonym for it.
But I think that's basically confusing.

Yeah, I'm not sure it actually helps much.

Andrew - is this going to cause any issues wrt the buildfarm, by any
chance?

None of my Windows buildfarm members builds with krb5. Mastodon does,
although it seems to have gone quiet for 16 days (Dave - might be worth a
check). Probably the result of renaming krb5 would be just that the build
would proceed without it. From memory I don't thing the config settings are
sanity checked.

Yeah, sorry - we had an aircon failure where my animals live, so
they've been down for a couple of weeks. We've got a complete new
system 90% installed, that should be finished today, so hopefully one
of my colleagues can bring everything up again tomorrow (I'm out of
town for a couple of days).

--
Dave Page
PostgreSQL Core Team
http://www.postgresql.org/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers