Re: [HACKERS] SSL renegotiation
Renegotiation should be a best practice. Trouble is it's been broken (at the protocol level) three times in the last few years so it's a massive hole in practice. Ideally we should leave the renegotiate in, and only remove it if configure detects a broken version of TLS. Personal email. hbh...@oxy.edu On Feb 23, 2015, at 7:01 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote: I'd say it is best to wait if and how OpenSSL change their API when they implement TLS 1.3. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Plans for 8.4
On Jul 31, 2008, at 7:58 AM, Magnus Hagander wrote: Stephen Frost wrote: * Henry B. Hotz ([EMAIL PROTECTED]) wrote: I'm making no promises, but what would people think of a hostgss hba option? As described, sounds like a win to me. It'd be very nice to be able to just use GSSAPI encryption on the link. That, combined w/ Magnus' work on username/princ mappings, would really bring PostgreSQL up to date wrt GSSAPI support. Yeah, +1 on this feature, it would be quite useful. It'd really be great to have this support in the ODBC and JDBC drivers too.. I think in JDBC it might 'just work', I'm less sure about ODBC. ODBC will need hackery I think. They use libpq for authentication only, but have their own SSL code and such. I do think ODBC would be a fairly major point to it being a success, though, so it'd be good if a plan could be secured for it. But it's not a showstopper, of course. I don't know enough about ODBC. If ODBC does SSL independently of PG then it requires thought by someone who understands ODBC. As a practical question- would you really need a seperate explicit pg_hba option for it? It'd be nice to be able to require it, if desired, but that strikes me as more sensible as an option to the 'gss' auth mechanism? Yeah, if we can get rid of that, that'd be good. The stuff I'm working on will allow us to have multiple parameters for each row in name/ value pairs, so if we could use that, it'd be better. (I've been considering changing how host/hostssl work that way as well - by having a parameter similar to what we have on the client side with sslmode=...) A thought that I came across - is it even possible to use GSSAPI encryption *without* using GSSAPI authentication? If not, it really seems like it should belong more in the parameter part of the field. Since in that case it is also not possible to enable encryption *before* authentication, or is it? You're on the right track. My problem isn't the hba file parsing at all. My problem is the interaction between the buffering logic and the encrypted I/O routines. The technical issue is that to make a GSSAPI security layer independent of SSL you need to invent a whole new buffering layer. That's a lot of work, and it only buys you the ability to do both SSL and GSSAPI at the same time. That doesn't seem worth it. The code being affected is what's currently configured in column 1 of hba. The ability to use the new capability requires that SSL *NOT* be configured in column 1 for the relevant client addresses. In short, no, it doesn't make sense to make it an option to the gss authentication method, even though it requires it. If we make it an option to the gss authentication method it would still need to act like it was specified in column 1, which would be confusing. GSSAPI security layers are negotiated after the authentication (or at least after the start of authentication). There are GSSAPI status flags that indicate if the security layer is available yet. The GSSAPI security layer code would check those flags and gss_wrap() or not accordingly. (-: There's a flush() or two from my original patch that will need to be added back in, otherwise we'll encrypt a message that tells the other end how to decrypt messages. Not a big deal. ;-) -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Plans for 8.4
What's the time frame for 8.4? I'm making no promises, but what would people think of a hostgss hba option? Using it would imply the gssapi/sspi authentication option. It would be mutually exclusive of the ssl link-encryption option. It would support strong encryption of the whole connection without the need to get X509 certs deployed (which would be a big win if you're using gssapi/sspi authentication anyway). The thing that prevented me from including it in the gssapi patches I did for 8.3 was that I couldn't disentangle the program logic to the point of inserting the gssapi security layer code above the SSL code and below everything else. I'm thinking that doing both is pretty much an edge case, so I propose to do gssapi security layers instead of SSL. The mods are a lot more obvious. I'm *NOT* proposing to make build support of gssapi security layers exclusive of SSL. You might, for example, configure a server to support username/password over SSL for intra-net addresses, but support gssapi for Internet addresses. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.3 GSS Issues
On Oct 27, 2007, at 1:36 AM, Magnus Hagander wrote: If this isn't fixed then PG will never be a supported infrastructure service at JPL the way MySQL currently is. I had hoped to use the GSSAPI support as a feature to pry some people away from MySQL, but without the ability to integrate into a multi-realm infrastructure this won't fly. Of course even with proper support it still may never happen, so that isn't a threat. Sure, but that's no reason to pull it from 8.3 if it can only be fixed in 8.4. It's a good reason to work towards having it fixed in 8.3, certainly, but not a reason to pull it if it isn't there. FWIW, I'm fairly certain I can have a match_realm parameter done for beta3. A brief inspection suggests the relevant code from my original patch would work with very little modification. It supports what I need to support. *I* have no need for a match_realm parameter as long as realm matching *is* done and can be done on a per-user basis. Obviously it would be convenient for some other people if realm matching could be disabled or a non-default realm could be made the default and required. I just don't want such extras to create security holes (by equating different users) or prevent support of the full user pool. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.3 GSS Issues
On Oct 26, 2007, at 12:56 AM, Magnus Hagander wrote: On Thu, Oct 25, 2007 at 05:39:37PM -0700, Henry B. Hotz wrote: On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote: * Henry B. Hotz ([EMAIL PROTECTED]) wrote: What you're asking for is basically a krb_match_realm parameter, or do I understand you wrong? I'm asking for name matching to be done i.a.w. the gssapi recommendations. That's all I want, but it's actually necessary for this feature to be at all usable in my environment. If we don't then I suggest we pull this feature until it can be done correctly. I know what you want, that's fairly obvious. I'm only asking about *how* to do it the best way. What the krb5 method does is IMO a documented bug. The realm name is part of the name. As I explained at some length you cannot assume the username (first component of the principal) has any meaning by itself, except in small deployments with no external trust agreements. Kerberos (and AD) are designed to support larger infrastructures with multiple organizations. This isn't unexpected for PG as the current krb5 support does this. I'm not a big fan of it but at the same time I don't feel it's justification to drop it from 8.3. Having it only allow the default realm would be an option which could work in 8.3, imv. I don't think the fact that the existing krb5 code does the wrong thing (and can't be used in an environment with cross-realm agreements) is justification for doing the wrong thing in a new capability. The code in my original patch would do the latter (default realm only). More precisely: if you do a gss_import_name() on smith and [EMAIL PROTECTED] you get the same internal representation, and gss_compare_name() will tell you they're the same. Also gss_compare_name() will tell you [EMAIL PROTECTED] is different from either of the first two. Wouldn't using a specific parameter like krb_match_realm=YOUR.REALM that you set in the config file be more flexible? In that it actually allows scenarios like server/resource domains (not sure how common they are in unix krb setups, but they're certainly not unfamiliar in the Windows AD world)? Yes and no. It certainly would have made it easier to test my original patch since the server was in a test realm and I couldn't use my normal production identity. I'd imagine deployments where the users are in a different realm from the servers are somewhat common. The counter is that (if done naively) it would prevent you from supporting users from multiple realms at all. I never completely tested this, but I think with my original patch you could define both smith (== [EMAIL PROTECTED]) and [EMAIL PROTECTED] as users to PG. They wouldn't be the same user (which you might want), but you could support both of them. Is there any (other) code in PG that would barf on long usernames that contain @ and/or .? If we don't use gss_compare_name(), or some similar mechanism, to compare connection names to PG usernames, then I don't think GSSAPI support should be included in 8.3. I think that's a horrible idea, given that it works perfectly fine the way it is now for the vast majority of users. That said, we should certainly fix it in one way or another for 8.3. But if that fails, I see no reason at all to pull the feature. If this isn't fixed then PG will never be a supported infrastructure service at JPL the way MySQL currently is. I had hoped to use the GSSAPI support as a feature to pry some people away from MySQL, but without the ability to integrate into a multi-realm infrastructure this won't fly. Of course even with proper support it still may never happen, so that isn't a threat. Longer term (since it's likely too late to be accepted now), as I think has been discussed in the past, PG could really use a .k5login-esque, either admin-only (ala pg_hba.conf / ident map) or per-user (some sort of ALTER ROLE that a user could do on himself?), mapping functionality. There has been discussion of a general mapping layer between authentication names and authorization/role names. I think that's the way to go. I haven't thought about who or where the administration of the mapping ought to be. Yeah, I agree that something like that would be a good long-term solution. For those on the periphery: the PG protocol already carries the PG username, and the Kerberos and GSSAPI auth methods carry the authentication name. If you define the PG username to be the authorization name then you have a pretty standard architecture. If anyone has used a kerberized ssh then you have a similar split. You can kinit as A and then ssh [EMAIL PROTECTED]. If you have put A into ~B/.k5login then you get in without a password prompt. For a proper discussion of this topic I recommend the section starting on page 64 of Sun's Security for Developers Guide, document 816-4863. Note that there is a discussion
Re: [HACKERS] 8.3 GSS Issues
On Oct 25, 2007, at 10:22 AM, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote: There's no way to specify the gssapi library to use. I have three on my main development Sun: MIT, Sun, and Heimdal. I might have more than one version of one of those three at some times. Of course there's no way to specify which kerberos 5 library or openssl library you want either, so consider this a feature request for future development. Yeah, that's something that can be done for 8.4, certainly not something we can put in now. But I'll be happy to see a patch once we open the tree for 8.4 :-) Isn't this something you do by specifying include and link search paths to configure? The above argument could be made for *any* library we use, and I surely do not want to put a single-purpose switch for each library into configure. All the other OS packages I've looked at seem to support a per- support-option specification of the relevant installation to use for that support. I expect that's a pain to implement, but it's what I (and presumably other people) expect. As I said this is a request for the future. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.3 GSS Issues
On Oct 25, 2007, at 1:47 AM, Magnus Hagander wrote: On Fri, Oct 19, 2007 at 04:51:04PM -0700, Henry B. Hotz wrote: I know I haven't been very active for a while here, but I just got to testing the October 3 version a bit prior to getting back to the Java GSS client stuff I promised. There seem to be some funny things there. Apologies for not responding to this one sooner. BTW, what's the status on the Java stuff? Will it be around by the time 8.3 is released? Touche. ;-) I hope to get to that in the next couple of weeks. The only serious issue is that the server doesn't require the realm name to match. I haven't looked at how that broke yet, but I know I was careful of that point in my original patches because it's always been wrong in the Kerberos 5 auth method. I honestly don't remember exactly how that became. I think I stripped it out in order to make it work like the krb5 method. What the krb5 method does is IMO a documented bug. The realm name is part of the name. As I explained at some length you cannot assume the username (first component of the principal) has any meaning by itself, except in small deployments with no external trust agreements. Kerberos (and AD) are designed to support larger infrastructures with multiple organizations. What you're asking for is basically a krb_match_realm parameter, or do I understand you wrong? I'm asking for name matching to be done i.a.w. the gssapi recommendations. That's all I want, but it's actually necessary for this feature to be at all usable in my environment. If we don't then I suggest we pull this feature until it can be done correctly. If you want to add a non-default ignore_realm option I have no objection, but the code may not be robust to varying gssapi implementations. Guaranteed it won't work with a non-kerberos mechanism like SPKM (which isn't widely deployed). For a proper discussion of this topic I recommend the section starting on page 64 of Sun's Security for Developers Guide, document 816-4863. Note that there is a discussion of how to do compares efficiently. IIRC my patch did things the easy way described on page 67. In the long run it's possible we'd want to do it the fast way described on page 69, but that's merely an optimization and might not be needed. It appears that you can just put a complete (realm-included) name into postgres, so that's obviously the way to support gssapi connections from non-default realms. In short this is a security hole. IMO it should be fixed prior to release. Can't you also configure the kerberos libraries on your machine not to accept other realms than your own? IIRC, that was something considered at the time, but I can't find a reference to such a discussion. Kerberos is about authenticating (identifying) users, not determining what they're authorized (allowed) to do. At the basic protocol level I can only refuse to exchange cross-realm keys with anybody. There's a NASA interpretation of a Presidential directive that would likely prohibit me from using this option, even if I wanted to. If I have even one user @NASA.GOV that I want to allow in to even one service @JPL.NASA.GOV then I can't use this option. The three major Kerberos implementations, Microsoft, MIT (including Apple and Sun), and Heimdal, all have different degrees of support for authorization control. MIT and Heimdal (and Microsoft, I assume) will let you trust STANFORD.EDU and *.NASA.GOV without (for example) trusting STANFORD.EDU to identify [EMAIL PROTECTED] Microsoft bundles their Kerberos with an LDAP server so they can do fine-grained authorization control from the same place. Every individual user in any trusted realm needs to have an entry in the local LDAP in order to get access to a Windows service. MIT supports an auth_to_local translation service to relate Kerberos principals to local workstation usernames. By default, the local realm is translated to the username by stripping the realm name. Other realms do not translate. The facility is poorly documented, and not standard, so I cannot recommend it. - I notice there are hba options for gss and sspi both. Why? Is there some windows-only functionality it enables? Shouldn't we be using Microsoft's advertised GSSAPI/SSPI compatibility? If you build on Windows then I'm sure you want to link the SSPI libraries rather than require installation of a separate package, but that shouldn't change the functionality or the wire protocol AFAIK. In other words I would expect this to be a build-time option. There was discussion about this, and we were presented with clear cases where you'd want to be able to do either one. Making it a build option doesn't help the 99.9% of Windows users that use a pre-packaged binary distribution. Doesn't exactly answer my question, but I guess there exists a Windows use case where linking
Re: [HACKERS] 8.3 GSS Issues
On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote: * Henry B. Hotz ([EMAIL PROTECTED]) wrote: What the krb5 method does is IMO a documented bug. The realm name is part of the name. As I explained at some length you cannot assume the username (first component of the principal) has any meaning by itself, except in small deployments with no external trust agreements. Kerberos (and AD) are designed to support larger infrastructures with multiple organizations. This isn't unexpected for PG as the current krb5 support does this. I'm not a big fan of it but at the same time I don't feel it's justification to drop it from 8.3. Having it only allow the default realm would be an option which could work in 8.3, imv. I don't think the fact that the existing krb5 code does the wrong thing (and can't be used in an environment with cross-realm agreements) is justification for doing the wrong thing in a new capability. The code in my original patch would do the latter (default realm only). More precisely: if you do a gss_import_name() on smith and [EMAIL PROTECTED] you get the same internal representation, and gss_compare_name() will tell you they're the same. Also gss_compare_name() will tell you [EMAIL PROTECTED] is different from either of the first two. If we don't use gss_compare_name(), or some similar mechanism, to compare connection names to PG usernames, then I don't think GSSAPI support should be included in 8.3. Longer term (since it's likely too late to be accepted now), as I think has been discussed in the past, PG could really use a .k5login-esque, either admin-only (ala pg_hba.conf / ident map) or per-user (some sort of ALTER ROLE that a user could do on himself?), mapping functionality. There has been discussion of a general mapping layer between authentication names and authorization/role names. I think that's the way to go. I haven't thought about who or where the administration of the mapping ought to be. See note about authentication vs authorization in last email. It doesn't strike me as terribly complex or hard to do but it certainly goes beyond the what is currently implemented for GSS in 8.3, and what exists currently for krb5. It's also something which could, technically, be added later. I do think it would be better done now though, if possible, since otherwise we would have to default to the current sub-par behaviour for quite some time (if not forever). Thanks, Stephen The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] 8.3 GSS Issues
I know I haven't been very active for a while here, but I just got to testing the October 3 version a bit prior to getting back to the Java GSS client stuff I promised. There seem to be some funny things there. The only serious issue is that the server doesn't require the realm name to match. I haven't looked at how that broke yet, but I know I was careful of that point in my original patches because it's always been wrong in the Kerberos 5 auth method. If I set up a server I might conceivably get connections from: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] same for every other NASA center, HQ, plus a fake realm relating to how NASA set up AD Now the only two of those that *might* be the same person are the first two, and that's only if the Stanford person has a grant to work on a JPL project and got put in our infrastructure as an affiliate, *and* the username wasn't already taken. It appears that you can just put a complete (realm-included) name into postgres, so that's obviously the way to support gssapi connections from non-default realms. In short this is a security hole. IMO it should be fixed prior to release. - I notice there are hba options for gss and sspi both. Why? Is there some windows-only functionality it enables? Shouldn't we be using Microsoft's advertised GSSAPI/SSPI compatibility? If you build on Windows then I'm sure you want to link the SSPI libraries rather than require installation of a separate package, but that shouldn't change the functionality or the wire protocol AFAIK. In other words I would expect this to be a build-time option. - At the risk of diluting my message: I still think it's a mistake to call it gss instead of something like gss-noprot. I believe this will cause misunderstandings in the future when we get the security layer of gssapi implemented. - There's no way to specify the gssapi library to use. I have three on my main development Sun: MIT, Sun, and Heimdal. I might have more than one version of one of those three at some times. Of course there's no way to specify which kerberos 5 library or openssl library you want either, so consider this a feature request for future development. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GSSAPI patch
On Jul 10, 2007, at 7:49 AM, Magnus Hagander wrote: On Tue, Jul 10, 2007 at 10:43:22AM -0400, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I'd appreciate it if people can run tests with this on some other platforms (I've only tested on Ubuntu linux and Win32). Specifically, I'm certain that the autoconf stuff will need to be expanded a bit in order to work for them all. What sort of tests have you got in mind? The one I'm most looking for is simply being able to build with GSSAPI enabled. I don't foresee any problems between implementations (there could be of course, but the standard defines the protocol), but I'm sure headers and libraries could be in different places and have different names. Actually testing the authentication itself is of course a bonus :-) I've only tested it against Active Directory, but IIRC Henry has used a Unix based Kerberos server. But more testing is always good. //Magnus Yes, I was using a Heimdal Kerberos server and Solaris 9 or MIT GSSAPI client libraries. (Client means Kerberos client so it's both client and server for Postgres.) I just DL'ed the 2007-07-10 08:16:17 snapshot and I don't see any reference to gss or GSS in configure.in. Should I wait for tomorrow's snapshot tarball? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
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 channel. Since GSSAPI and SSL are (probably, not necessarily) referenced to completely different ID infrastructure there are scenarios where that's beneficial. We might want to consider restructuring how SSL works when we do, that might make it easier. The way it is now with #ifdefs all around can lead to a horrible mess if there are too many different things to choose from. Something like transport filters or whatever might be a way to do it. I recall having looked at that at some point, but it was too long ago to remember any details.. //Magnus If someone wants to make it easier, that would be nice, I'm not up for it, I don't think. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
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. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
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 compromise? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
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 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 guessable without reading the documentation, unless you're already familiar with it. //Magnus gss-noprot and gss-prot gss-noenc and gss-enc ?? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
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 curious - on what platform is OpenSSL NOT available ? 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 is more stable than OpenSSL? regards, tom lane 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. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
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 PostgreSQL *at least*. I didn't say *available for download*, I said *ship with*. That is, does a Windows Vista Pro box from the factory come with OpenSSL on it? It does come with Microsoft SSPI, although I don't know compatibility issues. No, of course not. Microsoft OSes don't ship with *any* third party software. So yeah, didn't get what you meant, and you do have a point there. Provided the SSPI stuff actually does gssapi encryption - but I'll trust the people who say it does. I've only ever used the authentication parts myself. The SSPI has encryption and integrity functions, just like the GSSAPI. I don't remember Jeffrey Altman's interop example code well enough to say if he demonstrates that they interoperate as well. Spending 5 seconds looking at it, the SSPI appears to make a distinction between message and stream encryption that the GSSAPI does not make, so there is at least some profiling needed to identify what's common. I suspect that interoperability was intended. If we find bugs and tell the right people Microsoft might even fix them someday. 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 channel. Since GSSAPI and SSL are (probably, not necessarily) referenced to completely different ID infrastructure there are scenarios where that's beneficial. (The other thing that made it hard is that I needed to make changes in different places in the FE and the BE versions of libpq in order to get the same effect.) The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
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 established. If the Kerberos GSSAPI mechanism is used then it will follow exactly the same naming and file location conventions. What you gain is 1) it builds on Solaris 8+ with the built-in system Kerberos support (no separate Kerberos install needed), 2) the mechanism is portable to Java and native Windows clients, and 3) if you have a mechanism other than Kerberos available (e.g. SPKM, or SPNEGO/NTLM) in your GSSAPI then you could use it in place of Kerberos. I'm afraid that the politics at work that might have caused an adoption of a GSSAPI/JGSS Postgres Java client have changed, and they will be using MySQL instead. |-( Given what I've said here, I still feel obligated to provide Java mods, but your timeline will affect mine. Begin forwarded message: From: Bruce Momjian [EMAIL PROTECTED] Date: April 30, 2007 2:22:08 PM PDT To: Henry B. Hotz [EMAIL PROTECTED] Subject: Re: [PATCHES] Preliminary GSSAPI Patches Please post this info to the hackers list and we will deal with it. I am thinking we might just keep this all for 8.4. -- - Henry B. Hotz wrote: Thanks! As noted, the patch is incomplete w.r.t. the gss auth mech because it does not include code to actually encrypt the channel with the key derived from the auth mech. I confess I have so far been unsuccessful in inserting an additional layer of buffering to handle the block encryption. Would you like a new version of the patch with the incomplete functionality commented out (or otherwise removed)? Absent a volunteer to help, I think I should concentrate on getting the gss-np unprotected auth mech supported in the Java client. On Apr 26, 2007, at 4:09 PM, Bruce Momjian wrote: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. -- - Henry B. Hotz wrote: These patches have been reasonably tested (and cross-tested) on Solaris 9 (SPARC) and MacOS 10.4 (both G4 and Intel) with the native GSSAPI libraries. They implement the gss-np and (incompletely) the gss authentication methods. Unlike the current krb5 method gssapi has native support in Java and (with the SSPI) on Windows. I still have bugs in the security layer for the gss method. Hopefully will finish getting them ironed out today or tomorrow. Documentation is in the README.GSSAPI file. Make sure you get it created when you apply the patches. [ Attachment, skipping... ] --- -- --- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http:// www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + - --- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http:// www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
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 expandability to non-Kerberos, non-password authentication methods) then Postgres should use the GSSAPI instead. The submitted patches allow that. 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. On Apr 30, 2007, at 3:23 PM, Henry B. Hotz wrote: 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 established. If the Kerberos GSSAPI mechanism is used then it will follow exactly the same naming and file location conventions. What you gain is 1) it builds on Solaris 8+ with the built-in system Kerberos support (no separate Kerberos install needed), 2) the mechanism is portable to Java and native Windows clients, and 3) if you have a mechanism other than Kerberos available (e.g. SPKM, or SPNEGO/NTLM) in your GSSAPI then you could use it in place of Kerberos. I'm afraid that the politics at work that might have caused an adoption of a GSSAPI/JGSS Postgres Java client have changed, and they will be using MySQL instead. |-( Given what I've said here, I still feel obligated to provide Java mods, but your timeline will affect mine. Begin forwarded message: From: Bruce Momjian [EMAIL PROTECTED] Date: April 30, 2007 2:22:08 PM PDT To: Henry B. Hotz [EMAIL PROTECTED] Subject: Re: [PATCHES] Preliminary GSSAPI Patches Please post this info to the hackers list and we will deal with it. I am thinking we might just keep this all for 8.4. - -- Henry B. Hotz wrote: Thanks! As noted, the patch is incomplete w.r.t. the gss auth mech because it does not include code to actually encrypt the channel with the key derived from the auth mech. I confess I have so far been unsuccessful in inserting an additional layer of buffering to handle the block encryption. Would you like a new version of the patch with the incomplete functionality commented out (or otherwise removed)? Absent a volunteer to help, I think I should concentrate on getting the gss-np unprotected auth mech supported in the Java client. On Apr 26, 2007, at 4:09 PM, Bruce Momjian wrote: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- --- - Henry B. Hotz wrote: These patches have been reasonably tested (and cross-tested) on Solaris 9 (SPARC) and MacOS 10.4 (both G4 and Intel) with the native GSSAPI libraries. They implement the gss-np and (incompletely) the gss authentication methods. Unlike the current krb5 method gssapi has native support in Java and (with the SSPI) on Windows. I still have bugs in the security layer for the gss method. Hopefully will finish getting them ironed out today or tomorrow. Documentation is in the README.GSSAPI file. Make sure you get it created when you apply the patches. [ Attachment, skipping... ] -- --- --- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http:// www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http:// www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
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 that supports the native Kerb5 API that doesn't also support GSSAPI for the simple reason that a Kerberos-only version of GSSAPI has been bundled with both the MIT and Heimdal distributions for as long as I can remember. On Apr 30, 2007, at 4:48 PM, Tom Lane wrote: 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 support the GSSAPI interface? If so, how would we ever retire the old code? regards, tom lane The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Fwd: [PATCHES] Preliminary GSSAPI Patches
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 either. On Apr 30, 2007, at 5:56 PM, 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 sounds not very nice :-( regards, tom lane The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)
On Feb 23, 2007, at 1:24 PM, Joshua D. Drake wrote: Henry Hotz: GSSAPI (with Magnus) Progressing. Had hoped to have alpha patches by March 1, but I just got handed a proposal that I have to do by then. I trust it's OK to send the first version in next week? No real issues, except I haven't disentangled the SSL buffering to disentangle my security layer from theirs. Question: are there any corresponding deadlines for the Java client code that I need to worry about? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: Update Solaris FAQ.
Would you like a krb5.h file for Solaris 9-10 that will allow you to break into the hidden library? Also S10u4 won't be out until this summer. I'd say the answer is currently no. It's known by Sun that Postgres will compile against their Kerberos libraries though. On Feb 23, 2007, at 12:29 PM, Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: Log Message: --- Update Solaris FAQ. Could someone please translate this to English first? Updated text: 9) Can I compile PostgreSQL with Kerberos v5 support? Kerberos is integrated in OpenSolaris and will be integrated in Solaris 10u4. Kerberos v5 support is implemented by the GSS security libary which contains Kerberos v5 functions. However, the library is private and the interface might change without notice. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http:// www.enterprisedb.com The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] log ssl mode with connections?
Anyone making those kind of decisions probably wants a generic connection is encrypted flag. It could be true if a GSSAPI connection has negotiated use of a security layer. Of course I don't have my GSSAPI patches working as well as the SASL ones were yet, and I haven't started on adding security layers yet either. On Jan 30, 2007, at 12:56 PM, Magnus Hagander wrote: On Tue, Jan 30, 2007 at 12:35:01PM -0500, Kris Jurka wrote: On Tue, 30 Jan 2007, Andrew Dunstan wrote: If I am allowing both SSL and non-SSL I might like to know which is used by a particular connection. Other places I've heard people ask for this info: 1) pg_stat_activity to see who's currently connected and how. 2) Via a function (boolean am_i_using_ssl()) so they can make security decisions in views or procedural code. That information is available to the client in the form of the API call PQgetssl(). It will return NULL if no SSL is in use, or something other than NULL if it is (a SSL * pointer, but you don't need to know that if you just want to know if you're on SSL or not). IIRC it was originally disucssed to put it as a function callable, but it was decided that it makes a lot more sense to provide it in the client library. I don't know how many other client libraries provide the SSL information stuff. //Magnus The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 10 weeks to feature freeze (Pending Work)
On Jan 29, 2007, at 9:49 AM, Magnus Hagander wrote: Henry B. Hotz wrote: Henry B. Hotz: GSSAPI authentication method for C (FE/BE) and Java (FE). Magnus Haglander: SSPI (GSSAPI compatible) authentication method for C (FE) on Windows. (That fair Magnus? Or you want to volunteer for BE support as well?) Seems fair and about what we discussed. And no, I won't volunteer as long as you're on it - not sure I'll have the time to do it all in time. I'm only volunteering BE for Unix, not Windows. Not sure we need BE for Windows for 8.3 though. This is enough. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 10 weeks to feature freeze (Pending Work)
Sent directly. Anyone else who's interested can have a copy. Just email me. I *think* it's structurally sound. Please tell me if you find a problem. It lacks a lot: proper specification of required security properties, a way to specify different mechanism lists for local, vice TCP, vice SSL connections, authN name to authZ name mapping, most seriously I didn't implement security layers. Lots of debug checking still needed. OTOH it works on MacOS 10.4 G4 client and Intel server. As to the Postgres password database: If you use the DIGEST-MD5 mechanism, then you could get a secure, encrypted connection with no setup except the PG password. Also it would have made it easier for people to migrate from the current stuff to SASL. SASL *could* do everything that *any* of the current auth methods can do (OK, except ident) and then some. I thought that exporting all that code and functionality to a standard library would be a good thing in the long run. The down side is that completely replacing the existing framework would require SASL libraries readily available on *all* platforms that PG supports, and Windows doesn't. The Windows SASL API's turn out to be only available on 2K3 server, and have never been publicly tested for interoperability with the standard Unix library. I still believe in SASL. I know the Cyrus SASL library has become pretty ubiquitous on Unix platforms. I wish there were a simpler C API than Cyrus. Java 1.4.2 and up supports it. There are ways it could be provided on Windows, but not within the level of effort that Magnus or I can devote to the problem. - For GSSAPI, there is published interop code for the Windows SSPI at http://web.mit.edu/jaltman/Public/kfw/gss/. It's more places than SASL is. Down side is it doesn't do much that the current Krb5 code doesn't do. Structurally the GSSAPI mods will be very similar to the SASL ones I already did. On Jan 26, 2007, at 7:16 PM, Stephen Frost wrote: * Henry B. Hotz ([EMAIL PROTECTED]) wrote: If anyone is interested I currently have working-but-incomplete patches to support SASL in C. I've decided not to finish and submit them because the glue code to make configuration reasonable, and to allow use of existing Postgres password databases with the password- based mechanisms is still significant. I'd certainly like to take a look at it. I'm not entirely sure I follow what you mean by 'allow use of existing Postgres password databases'- I'm not sure SASL support requires that ability (after all, if they want to use the 'md5' or similar mechanism they can with the current protocol). Or am I missing something about how the SASL implementation is done or intended to be used? I'd tend to think it'd mainly be used as a mechanism to support other authentication mechanisms which don't use the internal Postgres passwords... Thanks, Stephen The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 10 weeks to feature freeze (Pending Work)
Henry B. Hotz: GSSAPI authentication method for C (FE/BE) and Java (FE). Magnus Haglander: SSPI (GSSAPI compatible) authentication method for C (FE) on Windows. (That fair Magnus? Or you want to volunteer for BE support as well?) GSSAPI isn't much more than a functional replacement for Kerberos 5, but it's supported on lots more platforms. In particular Java and Windows have native support (as well as Solaris 9). If anyone is interested I currently have working-but-incomplete patches to support SASL in C. I've decided not to finish and submit them because the glue code to make configuration reasonable, and to allow use of existing Postgres password databases with the password- based mechanisms is still significant. On Jan 22, 2007, at 2:16 PM, Joshua D. Drake wrote: Or so... :) Thought I would do a poll of what is happening in the world for 8.3. I have: Alvaro Herrera: Autovacuum improvements (maintenance window etc..) Gavin Sherry: Bitmap Indexes (on disk), possible basic Window functions Jonah Harris: WITH/Recursive Queries? Andrei Kovalesvki: Some Win32 work with Magnus Magnus Hagander: VC++ support (thank goodness) Heikki Linnakangas: Working on Vacuum for Bitmap Indexes? Oleg Bartunov: Tsearch2 in core Neil Conway: Patch Review (including enums), pg_fcache Vertical projects: Pavel Stehule: PLpsm Alexey Klyukin: PLphp Andrei Kovalesvki: ODBCng I am sure there are more, the ones with question marks are unknowns but heard of in the ether somewhere. Any additions or confirmations? Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/ donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Design Considerations for New Authentication Methods
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 you're looking for help, please let me know. Thank you. I will! ;-) Do you know Java? I'm doing this ultimately because I want the JDBC driver to support encrypted connections with Kerberos and without needing SSL. As an added plus a Windows-native client should support it. Interesting, I thought you were going for the authentication only. What's the real gain in doing Kerberos encryption over SSL encryption? Doesn't Java come with SSL support anyway these days? My main hesitation between SASL and GSSAPI is that the Windows equivalent APIs for SASL have not received the same degree of interoperability testing as SSPI--GSSAPI. I don't have a published example to crib from. For general information the relevant calls are at the bottom of http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/secauthn/security/authentication_functions.asp. One reason for this could be that they appear to be available only on server platforms, and not on cilents, if you look at the documentation. That said, I have the DLL file and the export functions on my XP machine, so it's definitly present there - I'm unsure if it *works* or is supported. My registry does indicate that I have the GSSAPI profile for SASL, which would be an indication that it should. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Design Considerations for New Authentication Methods
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 implemented, personally, so if you're looking for help, please let me know. Thank you. I will! ;-) Do you know Java? I'm doing this ultimately because I want the JDBC driver to support encrypted connections with Kerberos and without needing SSL. As an added plus a Windows-native client should support it. Interesting, I thought you were going for the authentication only. What's the real gain in doing Kerberos encryption over SSL encryption? Doesn't Java come with SSL support anyway these days? 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 Web browsers, I haven't looked at what PG has now.) Likewise a client can be fooled into trusting a spoof, if multiple CA's are trusted. It all depends on the policy enforcement rules you implement, and your control of the cert's. 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 identity so I don't have to worry about Man In The Middle attacks. SASL supports Kerberos, of course, but it's actually technology neutral. You can configure it to be as strong or weak as you want. You could e.g. support the SASL_PLAIN mechanism without requiring an encrypted tunnel, and you would sent passwords in the clear. (Not recommended of course.) SSL fans may want to use the SASL_EXTERNAL mechanism, which picks up the client identity from the SSL tunnel it's running in, or from the OS if it's a machine-local connection. (LDAP servers do the latter.) In my case I want the GSSAPI/Kerberos5 mechanism. These days Java comes with SASL, GSSAPI (via GAAS), and SSL/TLS support. Neither Java, nor Windows support the specific MIT Kerberos API functions used by PostgreSQL. This is largely because MIT itself has been encouraging people to use the standardized GSSAPI and SASL functions instead. The bad thing about these APIs is that they push you an abstraction layer or two away from the Kerberos functionality, which makes them a touch harder to learn and use. My main hesitation between SASL and GSSAPI is that the Windows equivalent APIs for SASL have not received the same degree of interoperability testing as SSPI--GSSAPI. I don't have a published example to crib from. For general information the relevant calls are at the bottom of http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/secauthn/security/authentication_functions.asp. One reason for this could be that they appear to be available only on server platforms, and not on cilents, if you look at the documentation. That said, I have the DLL file and the export functions on my XP machine, so it's definitly present there - I'm unsure if it *works* or is supported. My registry does indicate that I have the GSSAPI profile for SASL, which would be an indication that it should. Since those functions are there to support email clients, I would expect them to be widely available (at least on any machine that has an email client installed). Likewise I would expect them to be functional when talking to e.g. sendmail or postfix servers compiled with the Cyrus SASL library. Since I would use the same SASL library for the server side of the implementation, they're pretty likely to work to some degree. //Magnus I guess this discussion makes it sound like I've convinced myself to use SASL. I still need to resolve how to do name translation. PostgreSQL wants a single unix-like name, and I haven't looked at how to properly do that translation from SASL (or GSSAPI) names. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Design Considerations for New Authentication Methods
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 identity so I don't have to worry about Man In The Middle attacks. The encryption of a channel has nothing to do with verifying the client/server is who they say they are. They can be configured independantly. You can block Man-in-the-middle attacks without encrypting the channel, though it is unusual. Not actually true, at least not in a provable, general sense. There is no way to know that the other end of an encrypted channel is connected where you want it unless you have done some kind of client/ server mutual authentication as part of establishing the channel. TLS does (or can do) this. If PostgreSQL can pick up e.g. the UID from the client cert, then this is a very secure setup. Cudos! (Now if only TLS had something better than RFC 2712 to integrate with Kerberos.) You can do a client/server mutual auth exchange without later encrypting the channel, but then there is nothing to prevent someone from later doing a TCP hijack. This is what the current Kerberos support does. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Design Considerations for New Authentication Methods
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 a communications channel with user authentication to be a very poor choice. I gather from the paragraph above that this is a forgone conclusion. Apologies if I'm mistaken. Understand that I'm talking about *real* security here. There are standard protocols and libraries that support real security: SASL and GSSAPI in particular. You may for various reasons decide that it's too hard to do real security. Most people don't, including most people who use SSL. I'm not saying that's *wrong*, just that some possible attack methods have not been prevented. At the level of detail that's appropriate for this list, all I can do is repeat myself. Part of establishing a secure connection is establishing that the end points are the intended ones and there is no Man In the Middle. Establishing the end points means the server has identified the user within the name space of the security mechanism. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Design Considerations for New Authentication Methods
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 important during startup? You needn't bother to submit a patch that breaks it ;-). In other words I can't do the easy thing. OK. But I don't really see that it's such a big deal. You just need some state data to keep track of what to do the next time you receive a message. There's no assumption anywhere that authentication only involves one message exchange. In a sense you're right. The API's are designed to support that. Means I need to some more cases to the huge switch statement inside PWConnectPoll() though. I haven't looked at the corresponding logic on the server side, but I'd assume that it forks before we get to this point so it doesn't matter. Correct, we don't need to worry about multitasking apps there. regards, tom lane The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Design Considerations for New Authentication Methods
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 looking for help, please let me know. Thank you. I will! ;-) Do you know Java? I'm doing this ultimately because I want the JDBC driver to support encrypted connections with Kerberos and without needing SSL. As an added plus a Windows-native client should support it. My main hesitation between SASL and GSSAPI is that the Windows equivalent APIs for SASL have not received the same degree of interoperability testing as SSPI--GSSAPI. I don't have a published example to crib from. For general information the relevant calls are at the bottom of http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/secauthn/security/authentication_functions.asp. I don't do windows (TM). ;-) round trips and network accesses done. 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. I think you're missing a bit about how the design works. PGConnectPoll() is expected to be called multiple times until the connection is established. I think I got it. I just didn't want to get it. I'll probably do the simple, blocking-loop client anyway as a way to debug the server side. Then worry about getting the clients up to snuff. Basically, you can return something to the user that says connection not done yet, but I'm returning because you said to not block. Please call again when more data available or you have the opportunity to. This is a pretty common arrangment when non-blocking systems are implemented. As Tom said, you should just need to have some state stored so that you know what's going on when you're called again. Once I start adding connection state I can add a control for whether data packets need to be wrapped as well. I'm not sure how hard the 8KB case will be to handle though. Probably some hooks in the underlying library, and I hope they make it easier rather than harder. Thanks! Stephen The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Design Considerations for New Authentication Methods
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 authentication mechanisms before you find
one that works.
The question is how do I handle the multiple round-trips where one
trip is now assumed?
The simple approach is for me to just put the loop inside the
relevant fe-auth.c and auth.c sections, corresponding to where the
pg_krb5_{send,recv}auth() calls are. However the comments in the
code make it sound like people are very concerned about the number of
round trips and network accesses done. 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.
Is this behavior important during startup? Or is it only important
once the connection is fully established?
I haven't looked at the corresponding logic on the server side, but
I'd assume that it forks before we get to this point so it doesn't
matter.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] JAVA Support
On Sep 28, 2006, at 9:35 PM, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Is there any reason why we haven't built a generic authentication API? Something like PAM, except cross platform? We're database geeks, not security/crypto/authentication geeks. What makes you think we have any particular competence to do the above? Actually, the part of this proposal that raised my hackles the most was the claim that GSSAPI provides a generic auth API, because that was exactly the bill of goods we were sold in connection with PAM. (So why is this our problem at all --- can't you make a PAM plugin for it??) It didn't help any that that was shortly followed by the lame admission that no one has ever implemented anything except Kerberos underneath it. Word to the wise, guys: go *real* soft on vaporware claims for auth stuff, because we've seen enough of those before. Well, that's why I was pushing SASL instead of GSSAPI. There are multiple mechanisms that are actually in use. PAM turned out not to be sufficiently specified for cross-platform behavioral compatibility, and it only does password checking anyway. Calling it a security solution is a big overstatement IMO. I guess a lot of people use PAM with SSL and don't worry about the gap between the two (which SASL or GSSAPI close). In defense of GSSAPI non-Kerberos mechanisms do exist. They just cost money and they aren't very cross-platform. AFAIK GSSAPI has no simple password mechanisms. There's a Microsoft-compatible SPNEGO mechanism for GSSAPI that's being implemented fairly widely now, but it's just a sub-negotiation mech that lets you choose between a Kerberos 5 (that's practically identical to the direct one), and NTLM. If you allow NTLM you'd better limit it to NTLMv2! The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] JAVA Support
On Sep 29, 2006, at 12:31 AM, Magnus Hagander wrote: However, that doesn't change that some people would like us to support GSSAPI, and there may be some benefit (additional applications, better network authentication, etc.) for doing so. If we can get additional programmers to code the support (i.e. Sun, JPL) I don't see any reason not to support the *additional* authentication methods. Well, as I said already, a lot depends on the size of the patch. As a reductio ad absurdum, if they drop 100K lines of code on us, it *will* get rejected, no matter how cool it is. Oh, absolutely. The current Kerberos support seems to require about 50 lines in configure.in and circa 200 lines of C code in each of the backend and libpq. Plus a dependency on an outside library that happens to be readily available and compatibly licensed. I would expect, without looking at the details of the API, GSSAPI to be about the same amount of code if not less. Probably save some Kerberos bookkeeping. Probably loose it with GSSAPI bookkeeping, including name translation (which is far less obvious). Net, I would expect to lose, but not by very much. What amount of code are we talking about adding here, and what dependencies exactly? What portability and license hazards will be added? The Kerberos5 libraries that we rely on today provide GSSAPI. So it would work with the same external library. Now, it could *also* work with other libraries in some cases (for example, the Win32 SSPI libraries), but with the same libraries it should work fine. //Magnus If I had a lot of time to spend on this I would write a SASL-like wrapper so it could be used on platforms with GSSAPI, but not SASL support in the OS. As you may have noticed, I believe SASL is the way to go. I'm not up for it though. There's probably room in the world for a SASL-lite library though. Cyrus is great, but if your OS doesn't supply it for you, it's supposed to be really hard to build. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] JAVA Support
It appears that the JDBC client doesn't include the Kerberos support that the C clients do. So, two questions: 1) Is there an alternative JDBC client that's just a glue layer instead of a complete re-implementation? 2) If I were willing to add a GSSAPI or SASL layer as an alternative to the bare Krb 5 support would anyone be willing to help with the supporting mods to the pg_hba.conf parsing, and configure? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] JAVA Support
On Sep 28, 2006, at 10:52 AM, Kris Jurka wrote: On Thu, 28 Sep 2006, Henry B. Hotz wrote: It appears that the JDBC client doesn't include the Kerberos support that the C clients do. Java doesn't have accessible Kerberos support. It wraps Kerberos in GSSAPI which requires the server to support GSSAPI instead of plain Kerberos. Looks like Kerberos is the only GSSAPI mechanism supported in Java. OK by me, but that's not the point of the standard (or the SASL standard). So, two questions: 1) Is there an alternative JDBC client that's just a glue layer instead of a complete re-implementation? No, there aren't any Type 2 drivers around. Requiring native code is a giant pain. Kris Jurka Requiring JAVA support for everything you can do with C is also a pain, isn't it? (This incompatibility being an example.) I take it you're not volunteering to help with my second request. ;-) The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Paging Phil Dodderidge
There's an old post from Phil about having GSSAPI support almost working with PostgreSQL. I'd like to ask him about his work, but the email link in the archives doesn't work. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] JAVA Support
On Sep 28, 2006, at 12:42 PM, Magnus Hagander wrote: 2) If I were willing to add a GSSAPI or SASL layer as an alternative to the bare Krb 5 support would anyone be willing to help with the supporting mods to the pg_hba.conf parsing, and configure? Sure, I can help out with that. I've done a bunch of work on the current kerberos stuff (tohugh I'm by no means the author) in order to make it work on win32, so I have a little bit of a clue around that code ATM. As for the other part - will core accept this - I can't answer that. I do beleive that there is a point to it, given that Java will then support it natively, but I'm not core. I'm unsure if there is a clear view on the merits of adding more authentication options.. From the lack of traffic on this list I gather that the core developers no longer hang out here. I've been gone for a few years. For the record here's the arguments: SASL is a standards track RFC (I saw those snide comments in the record, Mr. Lane ;-) which allows you to plug in authentication mechanisms, much like PAM allows you to plug in password checkers. It is well adopted, since it forms the basis of most email protocols' authentication, as well as LDAP and Jabber. SASL provides a unified way for code to support all the authentication options you're likely to want. a) In the absence of OS-provided SASL libraries a simple password- checking mechanism could be implemented as a wire-compatible fallback with less code than the framework would take. (I won't write this, but you could probably steal code from jabberd.) b) SASL includes simple password checking mechanisms. In principle we could use these to check the local postgres passwords. Not sure how much customization that would require. c) If you are using SSL/TLS for client/server connections (or it's a local on-machine connection) you can use the SASL_EXTERNAL mechanism to pick up the identity from the connection, without imposing extra overhead. d) SASL includes enterprise-class authentication support, such as GSSAPI (and Kerberos via GSSAPI). If an enterprise has some unique authentication infrastructure it can be implemented as a SASL (or GSSAPI) plug-in without the need to customize PostgreSQL. e) After the initial connection, SASL can be configured to run the connection fully encrypted, integrity protected, or unprotected. f) SASL support is available in current Java as well as C. SASL libraries are included (or at least loadable) on MacOS, Solaris 10+, and Linux. (I don't do windows, so I can't say there.) While it has a reputation for complexity, that complexity is in building the libraries, not in using them. It can be used to provide most (all?) of the functionality now provided by the assortment of existing mechanisms. If provided as an alternative, it could eventually allow decommissioning of a lot of the other mechanisms. If the number of existing mechanisms is an issue, then this could be a big long-term win. I'll assume the ball is in my court now, unless someone wants to claim I should just do GSSAPI and not bother with the higher level. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] JAVA Support
On Sep 28, 2006, at 2:24 PM, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: As for the other part - will core accept this - I can't answer that. It would depend in part on the size of the patch, and on whether there are any arguments for supporting GSSAPI besides Java can't do Kerberos. What would it buy for a libpq user? Everything that the current Kerberos support provides plus Java. Ability to encrypt or integrity protect the client/server connection (without SSL/TLS tunnels). In theory, you get to plug in other mechanisms than Kerberos. In practice I think this only worked on Solaris, until very recently. The free gssapi implementations in Java, Solaris, MIT Kerberos, and Heimdal Kerberos only supported Kerberos. Sun open sourced their mechanism glue code and it's being incorporated into both MIT (now) and Heimdal (0.8). Entrust sells a PKI mechanism for Solaris. Wire compatibility with a native Windows API (the SSPI), if it's used correctly. (Google for posts by Jeffrey Altman for references to example code.) The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] JAVA Support
I cc'ed Tom Lockhart because he *used* to be core, and I know where he works. No response expected. On Sep 28, 2006, at 2:11 PM, Magnus Hagander wrote: f) SASL support is available in current Java as well as C. SASL libraries are included (or at least loadable) on MacOS, Solaris 10+, and Linux. (I don't do windows, so I can't say there.) While it has a reputation for complexity, that complexity is in building the libraries, not in using them. It can be used to provide most (all?) of the functionality now provided by the assortment of existing mechanisms. Well, it's still a complexity you need to deal with. Plus, just Java and C is far from enough, if you are intending to suggest we replace some of what we have now with it (like passwords and other such things). For example, you need things like perl, python, ruby, C#, etc etc. not sure how many of those would be fine with a C wrapper, I know for a fact that C# (or other .net languages) wouldn't, they need it natively. OK, point taken. OTOH how many of those have GSSAPI support? I don't know, but I'd guess that only going as far as GSSAPI gets you C# (and .net), and Java of course. Perl probably isn't a big deal just using glue for either SASL or GSSAPI. Python and Ruby I don't know. There also used to be some bad portability issues wrt at least some of the SASL libraries (if there is more than one). There's more than one, since the Java one is different from Cyrus. I've seen references to others, but I think they qualify as obscure. The Sun one is related to Cyrus. I know I tried to make it work on win32 once and failed miserably. (Then again, I've failed on Linux as well, but not quite as bad. And it's not included in all Linux distributions, at least it wasn't when I checked a while back) Well, I know Redhat has RPM's that look reasonable. I'm not a big Linux user myself. (More a BSD bigot, to be honest.) And finally, there's backwards compatibility. We're still going to have to support all the existing ones for the forseeable future unless you want to prevent all older clients from connecting (hint: you don't). No question. Just a thought for the future. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] JAVA Support
On Sep 28, 2006, at 3:03 PM, Josh Berkus wrote: Tom, It would depend in part on the size of the patch, and on whether there are any arguments for supporting GSSAPI besides Java can't do Kerberos. What would it buy for a libpq user? According to the Solaris Security engineers, GSSAPI is more secure than using the Kerberos headers. Also, in theory GSSAPI is supposed to support multiple authentication back-ends (ldap, liberty, etc.), but I personally have never seen support for anything but Kerberos. I think that GSSAPI is more tolerant of connections through NAT's. I think it's more robust to current network reality, but I'm not aware it's actually more secure if you're using comparable verification options. As noted elsewhere on this thread it's more available. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] JAVA Support
On Sep 28, 2006, at 3:01 PM, Josh Berkus wrote: Kris, I would if we could get some -hackers buy in on the idea. Adding more and more auth methods is something they're not excited about unless there's a good reason (which I think this is). Actually, I've been trying to get some of the Sun engineers to contribute patches for Solaris authentication methods, of which GSSAPI is one. So in theory someone from Sun should be looking at coding this. Sun demonstrated that you could build the existing Kerberos support with the current Solaris 11 beta's. They opened the native MIT Kerberos API for outside use. See posts on the [ports] list. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PORTS] [COMMITTERS] pgsql-server/src/template bsdi freebsd
At 10:45 AM -0400 10/9/03, Bruce Momjian wrote: Neil Conway wrote: On Thu, 2003-10-09 at 09:35, Bruce Momjian wrote: I only put back what was already there --- not sure why others don't use it. You want it enabled on Linux? Well, why do we have it enabled at all? If it's to speed compilation, we may as well enable it on other platforms where -pipe works, of which Linux is one. My gcc 2.95.3 manual says: -pipe Use pipes rather than temporary files for communi- cation between the various stages of compilation. This fails to work on some systems where the assem- bler cannot read from a pipe; but the GNU assembler has no trouble. so it looks like we can't use it on all platforms without testing. I will enable it for linux. Do people want to test other platforms? It should work on any platform that uses the GNU tools, so that means *BSD is in the same boat as Linux. Does it really speed compilation though? I saw somewhere that it didn't make much difference and might even hurt sometimes. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
At 1:15 AM -0500 11/20/02, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom, can you clarify why -0 is valid. The IEEE spec absolutely thinks that -0 and +0 are distinct entities. I don't remember why, at one in the morning ... but if you insist I'm sure that plenty sufficient numerical-analysis reasons can be produced. The guys who wrote that spec knew what they were doing (that's why it's been adopted so universally). It's so that 1/(1/-infinity) == -infinity. There are probably other reasons as well. I'm just guessing here, but it's possible NetBSD acquired the bug by trying to be functional on non-IEEE hardware. I hope that whoever found the problem (I don't see that in this thread) filed a bug report with NetBSD. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
At 1:51 PM -0500 11/20/02, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: Ah-hah, so it is a version issue --- we could make the resultmap line something like geometry/.*-netbsd1.[0-5]=geometry-positive-zeros NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) Hm, is that elf always there? I'm a little uncomfortable with making the pattern be geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros as this seems way too lax ... A version like 1.6[A-Z] is a -current, not a release version from in between 1.5.x and 1.6. Different NetBSD ports have converted to elf at different times and not all ports are using elf even with 1.6 released. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Re: Call for platforms
At 1:50 AM -0400 4/6/01, Tom Lane wrote: "Henry B. Hotz" [EMAIL PROTECTED] writes: Bottom line: 7.1RC1 passes most of the regression tests on NetBSD/macppc. The only thing that surprised me here was all of the warnings from libreadline calls: tab-complete.c: In function `initialize_readline': tab-complete.c:103: warning: assignment from incompatible pointer type tab-complete.c: In function `psql_completion': tab-complete.c:292: warning: passing arg 2 of `completion_matches' from incompatible pointer type tab-complete.c:296: warning: passing arg 2 of `completion_matches' from incompatible pointer type What version of libreadline do you have installed, and how does it declare completion_matches()? I have whatever is standard on NetBSD 1.5. I noticed that configure found a readline.h include file, but NetBSD doesn't integrate the current GNU implementation. I did not do a test of psql to see if the feature worked. I'm sure you could "fix" this problem if you installed GNU readline and referenced it in the build. Since Solaris had even worse issues with needing GNU support utilities installed this didn't seem like a big deal to me. OTOH it could confuse a new user. Signature held pending an ISO 9000 compliant signature design and approval process. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
