Re: [PATCH v20] GSSAPI encryption support
Robbie Harwood <rharwood@redhat.com>
From: Robbie Harwood <rharwood@redhat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
David Steele <david@pgmasters.net>, Joe Conway <mail@joeconway.com>,
Magnus Hagander <magnus@hagander.net>, Michael Paquier <michael@paquier.xyz>,
Nico Williams <nico@cryptonector.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-04-04T17:14:32Z
Lists: pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes: > Stephen Frost <sfrost@snowman.net> writes: >> * Tom Lane (tgl@sss.pgh.pa.us) wrote: >>> Well, if the caller thinks what is being passed back is an int, >>> it will do a 32-to-64-bit widening, which is almost certainly >>> going to result in a corrupted pointer. > >> Oh, good point. Interesting that it still works then. > > There must be something about the x86_64 ABI that allows this to > accidentally work -- maybe integers are presumed to be sign-extended > to 64 bits by callee not caller? I added some logging and verified > that pgstat.c is seeing the correct string value, so it's working > somehow. > >> I've got a fix for the missing prototypes, I hadn't noticed the issue >> previously due to always building with SSL enabled as well. > > Yeah, I'd just come to the conclusion that it's because I didn't > include --with-openssl, and libpq-be.h's #ifdef nest doesn't expect > that. > > BTW, the kerberos test suite takes nearly 4 minutes for me, is > it supposed to be so slow? My guess is entropy problems as well. If available, configuring /dev/urandom passthrough from the host is a generally helpful thing to do. My (Fedora, Centos/RHEL 7+) krb5 builds use getrandom() for entropy, so they shouldn't be slow; I believe Debian also has started doing so recently as well. I don't know what other distros/OSs do for this. Thanks, --Robbie
Commits
-
GSSAPI encryption support
- b0b39f72b990 12.0 landed
-
Fix typo
- 57c932475504 9.6.0 cited