Thread: pgsql: Implement channel binding tls-server-end-point for SCRAM
Implement channel binding tls-server-end-point for SCRAM This adds a second standard channel binding type for SCRAM. It is mainly intended for third-party clients that cannot implement tls-unique, for example JDBC. Author: Michael Paquier <michael.paquier@gmail.com> Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d3fb72ea6de58d285e278459bca9d7cdf7f6a38b Modified Files -------------- doc/src/sgml/protocol.sgml | 17 ++++--- src/backend/libpq/auth-scram.c | 20 ++++++-- src/backend/libpq/be-secure-openssl.c | 61 ++++++++++++++++++++++++ src/include/common/scram-common.h | 1 + src/include/libpq/libpq-be.h | 1 + src/interfaces/libpq/fe-auth-scram.c | 15 ++++++ src/interfaces/libpq/fe-secure-openssl.c | 80 ++++++++++++++++++++++++++++++++ src/interfaces/libpq/libpq-int.h | 1 + src/test/ssl/t/002_scram.pl | 5 +- 9 files changed, 189 insertions(+), 12 deletions(-)
Peter Eisentraut <peter_e@gmx.net> writes:
> Implement channel binding tls-server-end-point for SCRAM
Buildfarm doesn't like this one bit.
regards, tom lane
On Fri, Jan 5, 2018 at 9:36 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > Implement channel binding tls-server-end-point for SCRAM FYI some BF animals are saying: libpq/be-secure-openssl.o: In function `be_tls_get_certificate_hash': /home/pgbuildfarm/buildroot-termite/HEAD/pgsql.build/../pgsql/src/backend/libpq/be-secure-openssl.c:1268: undefined reference to `X509_get_signature_nid' -- Thomas Munro http://www.enterprisedb.com
On 4 January 2018 at 21:02, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> Implement channel binding tls-server-end-point for SCRAM > > Buildfarm doesn't like this one bit. Can't we automate these messages? Seems strange to send manual emails every time. We do know who the commits are coming from and we have their email address. It would be useful to get automatic message giving a summary of buildfarm results at 15, 30 and 60 minute intervals, even if it is just ALL CLEAR. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Buildfarm status monitoring (was Re: pgsql: Implement channel binding tls-server-end-point for SCRAM)
From
Tom Lane
Date:
Simon Riggs <simon@2ndquadrant.com> writes:
> On 4 January 2018 at 21:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> Implement channel binding tls-server-end-point for SCRAM
>> Buildfarm doesn't like this one bit.
> Can't we automate these messages?
It's not that easy. First, the buildfarm gets random failures all the
time, due to this and that. Second, if several commits have occurred
since the critter's last run, it requires some human judgment to figure
out which commit is probably to blame.
You could ameliorate the first problem by waiting for multiple failures
to show up ... but the longer you wait, the worse the second problem
becomes (and the less useful the report would be anyway).
> It would be useful to get automatic message giving a summary of
> buildfarm results at 15, 30 and 60 minute intervals, even if it is
> just ALL CLEAR.
The raw result of that would be too noisy to be useful. I've wondered
about getting the buildfarm status page to filter out the more obvious
classes of "random failure" --- git pull failures would be one, and
another would be if "no space left on device" appears anywhere in any
of the report's log files. Don't know how far that would get us, though.
regards, tom lane
Re: Buildfarm status monitoring (was Re: pgsql: Implement channelbinding tls-server-end-point for SCRAM)
From
Andrew Dunstan
Date:
On 01/08/2018 11:01 AM, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: >> On 4 January 2018 at 21:02, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Peter Eisentraut <peter_e@gmx.net> writes: >>>> Implement channel binding tls-server-end-point for SCRAM >>> Buildfarm doesn't like this one bit. >> Can't we automate these messages? > It's not that easy. First, the buildfarm gets random failures all the > time, due to this and that. Second, if several commits have occurred > since the critter's last run, it requires some human judgment to figure > out which commit is probably to blame. > > You could ameliorate the first problem by waiting for multiple failures > to show up ... but the longer you wait, the worse the second problem > becomes (and the less useful the report would be anyway). > >> It would be useful to get automatic message giving a summary of >> buildfarm results at 15, 30 and 60 minute intervals, even if it is >> just ALL CLEAR. > The raw result of that would be too noisy to be useful. I've wondered > about getting the buildfarm status page to filter out the more obvious > classes of "random failure" --- git pull failures would be one, and > another would be if "no space left on device" appears anywhere in any > of the report's log files. Don't know how far that would get us, though. > > Without triangulating via something like git-bisect I suspect we'd very soon find any automated system very tiresome indeed. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services