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 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.
Thanks! > 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'll leave the autoconf-fu to someone else if possible, but I can look at it later if nobody does (will look at the rest too). The docs need to be moved from README into the proper docs as well, but I can take care of that once the code is settled. >> 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. 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) But I won't fight for it, it's not that important to me :-) (And whether it's recommended or not depends on the environment - there are a cases where it's just unnecessary to add it. Say if you're employing ipsec across your network, adding a second layer of encryption will just make things slower for no gain - and it makes things more complex. Even if you're not talking high volume.) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate