On Fri, Sep 23, 2011 at 14:49, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 23, 2011 at 8:38 AM, Magnus Hagander <mag...@hagander.net> wrote: >> On Fri, Sep 23, 2011 at 14:35, Lou Picciano <loupicci...@comcast.net> wrote: >>> On Wed, Aug 31, 2011 at 11:59, Srinivas Aji <srinivas....@emc.com> wrote: >>>> >>>> The following bug has been logged online: >>>> >>>> Bug reference: 6189 >>>> Logged by: Srinivas Aji >>>> Email address: srinivas....@emc.com >>>> PostgreSQL version: 9.0.4 >>>> Operating system: Linux >>>> Description: libpq: sslmode=require verifies server certificate if >>>> root.crt is present >>>> Details: >>>> >>> ... >>>> >>>> The observed behaviour is a bit different. If the ~/.postgresql/root.crt >>>> file (or any other filename set through sslrootcert option) is found, >>>> sslmode=require also performs the same level of certificate verification >>>> as >>>> verify-ca. The difference between require and verify-ca is that it is an >>>> error for the file to not exist when sslmode is verify-ca. >>> >>> I looked at this again, and I'm pretty sure we did this intentionally. >>> The idea being that before we had the verify-ca/verify-full options, >>> adding the root cert would enable the verification. And we didn't want >>> to turn installations that previously did verify the certificate to >>> stop doing so in the new version. >>> >>> So basically, the behaviour that is by design is: >>> * require: if certificate exists, verify. if certificate doesn't >>> exist, don't verify. >>> * verify-ca: if certificate exists, verify. if certificate doesn't >>> exist, disconnect. >>> >>> The question is, have we had the new options long enough now that we >>> should change it so that we don't verify the cert in the case of >>> cert-exists-but-verification-wasn't-explicitly-asked-for? >>> >>> Or should we just update the documentation to mention how this works? >>> >>> Magnus, If you're accepting votes on this: I would say 'yes' - change the >>> behavior to the most logically consistent ones; ie, isolate the verification >>> bits a bit more explicitly. And, in documentation, indicate the deprecation >>> of the old behavior. >>> >>> Our mileage, in practical terms, is that the perceived inconsistencies >>> create a minor support hassle - we don't want to present any - even trivial >>> - hurdle to adoption of SSL to our clients. >> >> There are really two options to this as well - we can backpatch such a >> change, or we can change it only in 9.2. I'm leaning towards a "no" on >> the backport, because that will change things for existing users. So >> probably a doc change in backbranches and a behaviour change in 9.2 >> would be the reasonable choice in this case. > > I definitely don't think we should back-patch a behavior change that > silently weakens security. That's not good. > > But what about not doing it in master, either? It seems to me that we > could avoid ever breaking backward compatibility by adding a new > option "require-no-verify".
Hmm. Intersting. and we could then deprecate the "require" option and kill it off 4 releases later or so, I guess... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers