Обсуждение: 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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

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

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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

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

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

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

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

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

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

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

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@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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

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

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

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

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

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

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@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 HaganderMe: 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@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?

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

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

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/