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@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 Hagander
Me: 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 Hagander
Me: 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
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/
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 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/
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
