Re: Deprecations in authentication

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/

On 18 October 2012 12:20, Magnus Hagander <magnus(at)hagander(dot)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

On Thu, Oct 18, 2012 at 1:32 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 18 October 2012 12:20, Magnus Hagander <magnus(at)hagander(dot)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/

On 18 October 2012 12:37, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Thu, Oct 18, 2012 at 1:32 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On 18 October 2012 12:20, Magnus Hagander <magnus(at)hagander(dot)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

On 18 October 2012 12:20, Magnus Hagander <magnus(at)hagander(dot)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

Simon Riggs wrote:
> On 18 October 2012 12:20, Magnus Hagander <magnus(at)hagander(dot)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

On 18 October 2012 12:43, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 18 October 2012 12:20, Magnus Hagander <magnus(at)hagander(dot)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

On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander <magnus(at)hagander(dot)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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander <magnus(at)hagander(dot)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

On 10/18/2012 04:43 AM, Simon Riggs wrote:
>
> On 18 October 2012 12:20, Magnus Hagander <magnus(at)hagander(dot)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

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.

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.

On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander <magnus(at)hagander(dot)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/

Magnus, all,

* Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas <robertmhaas(at)gmail(dot)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

On Mon, Oct 22, 2012 at 4:24 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Magnus, all,
>
> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> > On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas <robertmhaas(at)gmail(dot)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/

Magnus,

* Magnus Hagander (magnus(at)hagander(dot)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

On Mon, Nov 5, 2012 at 9:57 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Magnus,
>
> * Magnus Hagander (magnus(at)hagander(dot)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

On Mon, Nov 5, 2012 at 6:10 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Nov 5, 2012 at 9:57 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Magnus,
> >
> > * Magnus Hagander (magnus(at)hagander(dot)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/

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&dt=2012-11-02%2011%3A38%3A04

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

On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 11/05/2012 12:13 PM, Magnus Hagander wrote:
>
>>
>>
>> http://www.pgbuildfarm.org/**cgi-bin/show_status.pl<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...

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

On 11/05/2012 01:53 PM, Magnus Hagander wrote:
>
> On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan <andrew(at)dunslane(dot)net
> <mailto:andrew(at)dunslane(dot)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

On Mon, Nov 5, 2012 at 10:21 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 11/05/2012 01:53 PM, Magnus Hagander wrote:
>
>
>> On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan <andrew(at)dunslane(dot)net<mailto:
>> andrew(at)dunslane(dot)net>> wrote:
>>
>>
>> On 11/05/2012 12:13 PM, Magnus Hagander wrote:
>>
>>
>>
>> http://www.pgbuildfarm.org/**cgi-bin/show_status.pl<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?

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

On 11/05/2012 04:54 PM, Magnus Hagander wrote:
> On Mon, Nov 5, 2012 at 10:21 PM, Andrew Dunstan <andrew(at)dunslane(dot)net
> <mailto:andrew(at)dunslane(dot)net>> wrote:
>
>
> On 11/05/2012 01:53 PM, Magnus Hagander wrote:
>
>
> On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan
> <andrew(at)dunslane(dot)net <mailto:andrew(at)dunslane(dot)net>
> <mailto:andrew(at)dunslane(dot)net <mailto:andrew(at)dunslane(dot)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

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.

On Thu, Oct 24, 2013 at 8:35 PM, Peter Eisentraut <peter_e(at)gmx(dot)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/

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.

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(at)gmx(dot)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?

On Sat, Jan 11, 2014 at 9:45 PM, Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmx(dot)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/

On Sun, Jan 12, 2014 at 4:35 PM, Magnus Hagander <magnus(at)hagander(dot)net>wrote:

> On Sat, Jan 11, 2014 at 9:45 PM, Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmx(dot)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/

Magnus Hagander <magnus(at)hagander(dot)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

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

> Magnus Hagander <magnus(at)hagander(dot)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/

On 01/16/2014 08:01 AM, Magnus Hagander wrote:
>
> On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>
> Magnus Hagander <magnus(at)hagander(dot)net <mailto:magnus(at)hagander(dot)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

On Sat, Jan 18, 2014 at 3:59 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 01/16/2014 08:01 AM, Magnus Hagander wrote:
>
>>
>> On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us <mailto:
>> tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>>
>> Magnus Hagander <magnus(at)hagander(dot)net <mailto:magnus(at)hagander(dot)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/

On Sat, Jan 18, 2014 at 2:59 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 01/16/2014 08:01 AM, Magnus Hagander wrote:
>>
>>
>> On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
>> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>>
>> Magnus Hagander <magnus(at)hagander(dot)net <mailto:magnus(at)hagander(dot)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/