Re: Fwd: [PATCHES] Preliminary GSSAPI Patches - Mailing list pgsql-hackers

From Henry B. Hotz
Subject Re: Fwd: [PATCHES] Preliminary GSSAPI Patches
Date
Msg-id E3F59261-20D6-4D25-9652-29C44580EF95@jpl.nasa.gov
Whole thread Raw
In response to Re: Fwd: [PATCHES] Preliminary GSSAPI Patches  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Fwd: [PATCHES] Preliminary GSSAPI Patches
List pgsql-hackers
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 already know your way around the code, please do it. And please go
> for removing it alltogether instead of just commenting it out -  
> it's in
> the list archives and can be referred to there if/when we want to  
> add it
> back in.

I can do that.

Could I ask you, or someone else, to look at what needs to happen to  
configure?  The way you capture `krb5-config --libs gssapi` into a  
variable is completely different in BSD and GNU make, and I don't  
know how to deal with that.  (The configure logic for mod_auth_kerb  
suffers from that problem, too.)  The README.GSSAPI file in the patch  
has reasonable notes, and it should be pretty simple otherwise.

> I'd also vote for changing the name of the "non encrypted" version to
> just "gss" instead of "gss-np".

I happen to disagree on this point.  There are a whole class of  
attacks that become possible if the encryption from the original  
authentication exchange isn't used for the on-going channel  
encryption/integrity.  They may be impossible in practice, but how  
many cans of worms do you want to deal with when you recommend a  
"secure" configuration to an average admin?  I would rather not hide  
the distinction by changing the name that way.

Also, if I *do* get the buffering disentangled and create a working  
"gss" mechanism, what would I call it if the name is already taken?   
At that point it would become the recommended mechanism unless high- 
volume performance made it impractical.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Feature freeze progress report
Next
From: Tom Lane
Date:
Subject: Re: Heap page diagnostic functions