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. -- 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