Magnus Hagander wrote:
Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.
How long ago did you check? I've been using OpenSSL on windows for many
years. Actually, it was supported just fine on Windows back when it was
added to PostgreSQL *at least*.
I didn't say
On Tue, May 01, 2007 at 04:26:13PM -0700, Henry B. Hotz wrote:
On May 1, 2007, at 3:11 PM, Magnus Hagander wrote:
Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.
How long ago did you check? I've been using OpenSSL on windows
for many
years. Actually,
On May 2, 2007, at 3:11 AM, Magnus Hagander wrote:
As to the question of GSSAPI vs SSL, I would never argue we don't
want both.
Part of what made the GSSAPI encryption mods difficult was my intent
to insert them above the SSL encryption/buffering layer. That way
you could double-encrypt the
Tom Lane wrote:
Henry B. Hotz [EMAIL PROTECTED] writes:
Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least?
Hm, you mean that what you called a C API change actually
break^H^H^H^H^Hchanges the on-the-wire protocol as well?
That
Henry B. Hotz wrote:
OK, so posted. ;-)
snip
Would you like a new version of the patch with the incomplete
functionality commented out (or otherwise removed)?
Yes please :-) I was going to try to do one of those myself, but since
you already know your way around the code, please do it. And
On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:
Henry B. Hotz wrote:
OK, so posted. ;-)
snip
Would you like a new version of the patch with the incomplete
functionality commented out (or otherwise removed)?
Yes please :-) I was going to try to do one of those myself, but since
you
Magnus,
I'd also vote for changing the name of the non encrypted version to
just gss instead of gss-np.
I don't. We'll want to support GSS encryption once we have the code, so we
should leave the namespace open to address that.
Oh, and I do think putting in GSSAPI authentication only (and
Henry B. Hotz wrote:
On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:
Henry B. Hotz wrote:
Would you like a new version of the patch with the incomplete
functionality commented out (or otherwise removed)?
Yes please :-) I was going to try to do one of those myself, but since
you
Josh Berkus wrote:
Magnus,
I'd also vote for changing the name of the non encrypted version to
just gss instead of gss-np.
I don't. We'll want to support GSS encryption once we have the code, so we
should leave the namespace open to address that.
I agree that we should do this, I'm
Josh Berkus wrote:
Magnus,
I'd also vote for changing the name of the non encrypted version to
just gss instead of gss-np.
I don't. We'll want to support GSS encryption once we have the code, so we
should leave the namespace open to address that.
Oh, and I do think putting in GSSAPI
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Josh Berkus wrote:
For now, yes. In the long run, we want to provide users with other methods
of encrypted connections than the rather flaky and
not-available-on-every-platform OpenSSL.
I'm curious - on what platform is OpenSSL NOT available
Magnus Hagander [EMAIL PROTECTED] writes:
I would call them gss and gss-sec. Or possibly gss-enc. I think
that's a lot more clear than gss-np (something ending with -sec is a
giveaway)
+1
regards, tom lane
---(end of
Tom,
And even more curious to see you defend that offhanded bashing of
OpenSSL, a tool a whole lot of people (including me) depend on all day
every day. If Postgres had the market penetration of OpenSSL, our lives
would be a lot different. Have you got even a shred of evidence that
GSSAPI
On May 1, 2007, at 1:33 PM, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I would call them gss and gss-sec. Or possibly gss-enc. I think
that's a lot more clear than gss-np (something ending with -sec
is a
giveaway)
+1
If we settle on gss-np and gss-sec is that a good
Josh Berkus wrote:
Tom,
And even more curious to see you defend that offhanded bashing of
OpenSSL, a tool a whole lot of people (including me) depend on all day
every day. If Postgres had the market penetration of OpenSSL, our lives
would be a lot different. Have you got even a shred of
Henry B. Hotz wrote:
On May 1, 2007, at 1:33 PM, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I would call them gss and gss-sec. Or possibly gss-enc. I think
that's a lot more clear than gss-np (something ending with -sec is a
giveaway)
+1
If we settle on gss-np and
On May 1, 2007, at 2:30 PM, Magnus Hagander wrote:
Henry B. Hotz wrote:
On May 1, 2007, at 1:33 PM, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I would call them gss and gss-sec. Or possibly gss-enc. I
think
that's a lot more clear than gss-np (something ending with -
sec
Henry B. Hotz wrote:
I would call them gss and gss-sec. Or possibly gss-enc. I think
that's a lot more clear than gss-np (something ending with -sec is a
giveaway)
+1
If we settle on gss-np and gss-sec is that a good compromise?
I still think the -np part is unclear - it's not easily
On May 1, 2007, at 1:32 PM, Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Josh Berkus wrote:
For now, yes. In the long run, we want to provide users with
other methods
of encrypted connections than the rather flaky and
not-available-on-every-platform OpenSSL.
I'm
Josh Berkus [EMAIL PROTECTED] writes:
Long Answer:
I've been dealing with OpenSSL binary incompatibility issues for the last
few Solaris builds and it's made me very unhappy with the
upgrade/versioning/linking of OpenSSL, and explained a lot of issues I've
had around using OpenSSL with
Short answer:
Existing Kerberos libs with GSSAPI may have the same issues; I don't know.
What I was speaking in favor of was having several encryption mechanisms
available so that at least one of them would be available on the user's
system at installation time. For that matter, I think we
Henry B. Hotz [EMAIL PROTECTED] writes:
Windows? I don't do Windows, so I'm guessing.
If you accept that Microsoft's SSPI is a flavor of GSSAPI, then
GSSAPI is more widely supported and probably more stable on Windows
machines than OpenSSL is.
I can't speak to the situation on Windows
Tom, Josh, Magnus.
I can't speak to the situation on Windows either; if OpenSSL isn't
commonly used on Windows that may be a sufficient reason for supporting
GSSAPI too. I'm just unconvinced by any argument that suggests we'll
replace our SSL support with it.
I can't imagine we will either.
Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.
How long ago did you check? I've been using OpenSSL on windows for many
years. Actually, it was supported just fine on Windows back when it was
added to PostgreSQL *at least*.
I didn't say *available for
On May 1, 2007, at 3:11 PM, Magnus Hagander wrote:
Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.
How long ago did you check? I've been using OpenSSL on windows
for many
years. Actually, it was supported just fine on Windows back when
it was
added to
Excuse me for replying to myself, but maybe it would be clearer if I
said this the other way around:
The existing Kerberos support uses a C API that is not supported in
Java or on Windows, and probably never will be. If we want to
support Kerberos on *all* platforms (and if we want
Henry B. Hotz [EMAIL PROTECTED] writes:
I tend to regard this as a comparable migration to the Kerb4 - Kerb5
one. In time it should be a complete replacement. In time we will
be able to rip out the existing Kerb5 code.
Why in time and not immediately? Are there platforms that don't
Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least? If you put my patches in 8.3,
and they work as well as I hope, then in time could be as soon as
8.4, I suppose.
To answer the question more directly: I do not know of any platform
Henry B. Hotz [EMAIL PROTECTED] writes:
Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least?
Hm, you mean that what you called a C API change actually
break^H^H^H^H^Hchanges the on-the-wire protocol as well?
That sounds not very nice :-(
Yes, the wire protocol is different. Sorry. I can't help that.
As I said, I'm not adding any new functionality yet, just lots of
potential compatibility that isn't possible with the Kerberos API now
used. While there's no significant new functionality yet, at least
there's no regression
30 matches
Mail list logo