Tom,
> I have no corporate commitment to make PG 8.3+ work on ancient Red Hat
> versions, if that's what you mean.
Well, in that case my suggestion is that we plan to transition to GSSAPI and
drop support for raw Kerberos as soon as Henry is ready with a patch (plus
I'm going to try to get the
Josh Berkus writes:
> Yes ... if we were looking to cut down on both code and dependency bugs, we
> might consider desupporting "raw Kerberos". At this point, I think that
> everyone who supports Kerberos supports GSSAPI, unless we're still committed
> to supporting users of Red Hat 7.0 (Tom?
Tom, Josh, etc.:
> But if you're looking for a "big application" that uses Kerberos,
> there's that pesky thing called Windows. Every single Windows machine in
> an active directory domain environment is a Kerberos client, and uses
> Kerberos for authentication to all network services.
Kerberos w
> >> To be honest, I have often wondered *why* we support
> kerberos outside
> >> of the uber l33t geek factor. I have not once in a commercial
> >> deployment had a business requirement for the beast. LDAP?
> Now that
> >> is a whole other issue :)
> >
> > Single sign-on in a Windows/AD envi
>> To be honest, I have often wondered *why* we support kerberos
>> outside of the uber l33t geek factor. I have not once in a
>> commercial deployment had a business requirement for the
>> beast. LDAP? Now that is a whole other issue :)
>
> Single sign-on in a Windows/AD environment (I'm talk
> > > > The same could apply to SSL cert based authentication,
> for users
> > > > connecting from machines outside of my realm. Once you have
> > > "unlocked"
> > > > the certificate, you can authenticate any number of
> times to any
> > > > number of services that will accept this certificate
On Fri, Nov 03, 2006 at 08:05:05AM +0100, Magnus Hagander wrote:
> > > The same could apply to SSL cert based authentication, for users
> > > connecting from machines outside of my realm. Once you have
> > "unlocked"
> > > the certificate, you can authenticate any number of times to any
> > > nu
> > To be honest, I have often wondered *why* we support
> kerberos outside
> > of the uber l33t geek factor. I have not once in a commercial
> > deployment had a business requirement for the beast. LDAP?
> Now that is
> > a whole other issue :)
>
> Isn't NFSv4 a big application that uses Ker
> >> ... Why would we reject a piece of useful functionality based on a
> >> published standard?
> >
> > Well, size and maintainability of the proposed patch are certainly
> > factors in any such decision. As a closely related example, I bet
> > we'd have rejected the original Kerberos-support
> > The same could apply to SSL cert based authentication, for users
> > connecting from machines outside of my realm. Once you have
> "unlocked"
> > the certificate, you can authenticate any number of times to any
> > number of services that will accept this certificate
> *without* having
> >
On Thu, Nov 02, 2006 at 07:49:01PM -0800, Joshua D. Drake wrote:
> To be honest, I have often wondered *why* we support kerberos outside of
> the uber l33t geek factor. I have not once in a commercial deployment
> had a business requirement for the beast. LDAP? Now that is a whole
> other issue :)
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Josh Berkus writes:
> > ... Why would we reject a piece of useful functionality based on a
> > published standard?
>
> Well, size and maintainability of the proposed patch are certainly
> factors in any such decision. As a closely related example, I bet
>
Tom Lane wrote:
> Josh Berkus writes:
>> ... Why would we reject a piece of useful functionality based on a
>> published standard?
>
> Well, size and maintainability of the proposed patch are certainly
> factors in any such decision. As a closely related example, I bet
> we'd have rejected the
Josh Berkus writes:
> ... Why would we reject a piece of useful functionality based on a
> published standard?
Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related example, I bet
we'd have rejected the original Kerberos-support pa
All,
> For what it's worth, I heartily support this effort. For most cases,
> it probably isn't necessary, but I can think of several applications
> for SASL/GSSAPI where something weaker will simply not do; in the
> absence of the proposed functionality, I simply wouldn't be able to
> use Postgr
On Thu, Nov 02, 2006 at 10:48:29PM +0100, Magnus Hagander wrote:
> The same could apply to SSL cert based authentication, for users
> connecting from machines outside of my realm. Once you have "unlocked"
> the certificate, you can authenticate any number of times to any number
> of services that w
On Thu, Nov 02, 2006 at 08:58:37PM +0100, Magnus Hagander wrote:
> > I don't think you can tie the SSL certificate to a specific
> > user though... I certainly can't recall any way to do that
> > today in PG.
>
> You can't. It's been talked about, but never done.
Oops, sorry. You can verify th
On Thu, Nov 02, 2006 at 01:10:14PM -0800, Henry B. Hotz wrote:
> standard protocols and libraries that support real security: SASL
> and GSSAPI in particular. You may for various reasons decide that
[. . .]
> Part of establishing a secure connection is establishing that the end
> points a
> Would signed certificates be preferred? Well, sure, they're
> nice. I don't object, and in fact welcome some improvements
> here. For example, I'd love the choice of taking an
> individual user's certificate and authenticating completely
> based upon that. However, while this _seems_ to simpl
On Nov 2, 2006, at 12:26 PM, Richard Troy wrote:
Well, there's simply no need. While I can agree that more could be
done,
I'm not convinced there's a need because what we have now works
fine. Let
me support my view by stating first that I perceive that combining the
conception of encrypting
* Richard Troy ([EMAIL PROTECTED]) wrote:
> ...I thought you said this _needs_ to be done - by using words like
> "unacceptible" and "required" - and I disagree. There's a difference
> between what needs to be done and what is desired to be done. Further, I
> never said "shouldn't."
For PG to be a
> Username/password is not acceptable in a number of situations. This is
> not intended to replace them. This would be in *addition* to supporting
> the current auth methods. I don't understand at all how you feel it'd
> be nice to have yet shouldn't be done.
>
>Thanks,
>
>
* Richard Troy ([EMAIL PROTECTED]) wrote:
> Would signed certificates be preferred? Well, sure, they're nice. I don't
> object, and in fact welcome some improvements here. For example, I'd love
> the choice of taking an individual user's certificate and authenticating
> completely based upon that.
On Thu, 2 Nov 2006, Magnus Hagander wrote:
> >
> > I expect we'll need a mapping of some sort, or perhaps a
> > sasl_regexp or similar to what is done in OpenLDAP. I don't
> > recall PG supporting using the DN from a client cert in an
> > SSL connection as a PG username but perhaps I missed it som
> > In postgresql the client and server can specify what certificates
> > thay'll accept, there are no default trusted CAs. You can
> require the
> > client to have a certain certificate, for example. The
> client can also
> > verify the server has the expected certificate. How much
> it's us
* Martijn van Oosterhout (kleptog@svana.org) wrote:
> In postgresql the client and server can specify what certificates
> thay'll accept, there are no default trusted CAs. You can require the
> client to have a certain certificate, for example. The client can also
> verify the server has the expect
On Nov 2, 2006, at 11:04 AM, Martijn van Oosterhout wrote:
On Thu, Nov 02, 2006 at 10:45:24AM -0800, Henry B. Hotz wrote:
In my case I have good control over the Kerberos infrastructure, but
none over the Federal PKI infrastructure. I also want the data
channel encryption tied to the client i
On Thu, Nov 02, 2006 at 10:45:24AM -0800, Henry B. Hotz wrote:
> Well, unless you have an unusually good PKI infrastructure, SSL
> doesn't provide any cryptographic connection between the client
> identity and the data received by the server. (At least that's true
> for the way it's used by
Sorry about the premature send.
On Nov 2, 2006, at 1:18 AM, Magnus Hagander wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth
method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that i
On Nov 2, 2006, at 1:18 AM, Magnus Hagander wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth
method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that implemented, personally, so if yo
> > * Henry B. Hotz ([EMAIL PROTECTED]) wrote:
> >> I've been looking at adding SASL or GSSAPI as an auth
> method. I have
> >> some questions about how to handle the flow of control changes.
> >
> > Great! I'd love to see that implemented, personally, so if you're
> > looking for help, please
On Nov 1, 2006, at 6:33 AM, Stephen Frost wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that implemented, personally, so if you're
On Oct 31, 2006, at 8:34 PM, Tom Lane wrote:
"Henry B. Hotz" <[EMAIL PROTECTED]> writes:
I notice that all the
authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
which sounds like something that isn't expected to block on network
access.
That's right.
Is this behavior import
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
> I've been looking at adding SASL or GSSAPI as an auth method. I have
> some questions about how to handle the flow of control changes.
Great! I'd love to see that implemented, personally, so if you're
looking for help, please let me know.
> round t
"Henry B. Hotz" <[EMAIL PROTECTED]> writes:
> I notice that all the
> authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
> which sounds like something that isn't expected to block on network
> access.
That's right.
> Is this behavior important during startup?
You needn't bot
I've been looking at adding SASL or GSSAPI as an auth method. I have
some questions about how to handle the flow of control changes.
When you do one of the above, an authentication is not (necessarily)
a simple one-packet exchange. In fact the exchange may involve
trying several different
36 matches
Mail list logo
