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
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 man
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 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 Pos
>>> 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 *avai
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 eith
"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 Wi
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
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 wi
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 curi
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 "-
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 wit
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
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 sh
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
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
> GSSA
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 broadcast)-
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 a
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 p
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
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,
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 on
On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:
Henry B. Hotz wrote:
OK, so posted. ;-)
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 alread
Henry B. Hotz wrote:
> OK, so posted. ;-)
>>> 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. An
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?
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
"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
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:
> 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 d
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 expanda
OK, so posted. ;-)
To clarify for the larger audience: without the plain "gss"
mechanism, the "gss-np" mechanism provides exactly the same
functionality as the existing krb5 mechanism. It will properly
secure the initial connection, but will not do anything once the
connection is estab
31 matches
Mail list logo
