On Wed, May 31, 2017 at 7:59 PM, Stephen Frost <sfr...@snowman.net> wrote: > If your comments regarding the requirement that we have interoperability > testing of this feature before accepting it were intended to mean that > we need to make sure that the JDBC driver is able to work with the > chosen solution (or, perhaps, that we support multuple options, one of > which works with the JDBC changes), and that we review the other TLS > libraries with the goal of making sure that what we agree on in core > should work with those also, then that's great and exactly what I'd like > to see also.
OK, great. That's what I mean (mostly - see below). > If your comments regarding the requirement that we have interoperability > testing of this feature before accepting it were intended to mean that > we must have a complete alternative TLS solution, while that would > actually play a great deal to a goal I've had for a while to have PG > support multiple TLS implementations (LibNSS being top-of-mind, at least > for me, as I've mentioned a couple times), I can't agree that we should > require that before accepting channel binding as a feature. To do so > would be akin to requiring that we support multiple TLS implementations > before we agreed to support client-side certificates, in my opinion. I don't think that we need to have a committed patch allowing multiple SSL implementations before we accept a patch for channel binding, but I think it might be a good idea for someone to hack either libpq or the server enough to make it work with some other SSL implementation (Windows SSL would probably be the best candidate) and test that what we think will work for channel binding actually does work. It wouldn't need to be a committable patch, but it should be enough to make a successful connection in the laboratory. Now, there might also be other ways besides that of testing that interoperability is possible, so don't take me as being of the view that someone has to necessarily do exactly that thing that I just said. But I do think that we probably should do more than say "hey, we've got this undocumented SSL API, and this other Windows API, and it looks like they do about the same thing, so we're good". There's sometimes a big difference between what sounds like it should work on paper and what actually does work. > I would be rather surprised if the solution which Michael and Alvaro > come to results in a solution which requires us to break compatibility > down the road, though it's of course a risk we need to consider. The > ongoing discussion around finding a way to support both methods outlined > in the RFC sounds exactly correct to me and I encourage further > discussion there. Sure, I have no objection to the discussion. Discussion is always cool; what I'm worried about is a tls-unique implementation that is supremely unportable, and there's no current evidence that the currently-proposed patch is anything else. There is some optimism, but optimism <> evidence. > I'm certainly on-board with the general idea of having a way for the > client to require both SCRAM and channel binding and I agree that's a > hole in our current system, but that is really an orthogonal concern. Orthogonal but *very* closely related. > entirely technical perspective. If I were one of the individuals > working on this feature, I'd be rather put-off and upset at the > suggestion that the good work they're doing is viewed by the PostgreSQL > community and one of our major committers as only being done to check a > box or to be "buzzword compliant" and ultimately without technical > merit. I did not say that the feature was "ultimately without technical merit"; I said that the patch as submitted seemed like it might not interoperate, and that without a libpq option to force it to be used it wouldn't add any real security. I stand by those statements and I think it is 100% appropriate for me to raise those issues. Other people, including you, do the same thing about other patches all the time. It is not a broadside against the contributors or the patch; it is a short, specific list of concerns that are IMHO quite justifiable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
