On Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost <sfr...@snowman.net> wrote: > I don't have any issue with asking that Michael, or someone, to go look > at other OpenSSL-using implementations which support channel binding.
I don't see the implementation of other TLS/SSL as a requirement for channel binding with OpenSSL, and I have no plans to investigate that. What is clearly a requirement though is to design a set of API generic enough for the backend and the frontend to fetch the TLS unique message, and what's needed for endpoint so as any implementation can plug in easily with PG's channel binding code. > What I find somewhat objectionable is the notion that if we don't have 5 > different TLS/SSL implementations supported in PG and that we've tested > that channel binding works correctly among all combinations of all of > them, then we can't accept a patch implementing it. I'm exaggerating > for effect here, of course, and you've agreed that a full, committable, > implementation isn't necessary, and I agreed with that, but we still > seem to have a different level of expectation regarding what needs doing > here. I don't know that we'll ever be able to nail down the exact > location of the line in the sand that needs to be crossed here, or agree > to it, so I'd suggest that we let them continue their efforts to work > together and provide a patch which they feel is ready to be commented on > by committers. Perhaps we'll find that, regardless of where the line > was drawn exactly, they've crossed it. As far as I can see, there are a couple of things that I still need to work on to make people happy: - Rework the generic APIs for TLS finish and endpoint so as any implementation can use channel binding without inducing any extra code footprint to be-secure.c and fe-secure.c. - Implement endpoint, as Alvaro is saying for JDBC that would be nicer. - Have a couple of tests for channel binding to allow people to test the feature easily. Those will be in src/test/ssl/. It would be nice as well to be able to enforce the channel binding type on libpq-side, which is useful at least for testing. So we are going to need an environment variable for this purpose, and a connection parameter. -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers