Date: Sat, 23 Feb 2019 11:27:51 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Robbie Harwood <rharwood@redhat.com>, pgsql-hackers@postgresql.org,
	Nico Williams <nico@cryptonector.com>,
	Michael Paquier <michael@paquier.xyz>,
	Alvaro Herrera <alvherre@2ndquadrant.com>,
	David Steele <david@pgmasters.net>
Subject: Re: [PATCH v20] GSSAPI encryption support
Message-ID: <20190223162751.GO6197@tamriel.snowman.net>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
 <jlgy38mir81.fsf@redhat.com>
 <5ec3f734-810e-36e0-030f-af92efe135da@2ndquadrant.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="SorlIzCW0DSU55cr"
Content-Disposition: inline
In-Reply-To: <5ec3f734-810e-36e0-030f-af92efe135da@2ndquadrant.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--SorlIzCW0DSU55cr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> I don't know much about GSSAPI, but from what I can tell, this seems an
> attractive feature, and the implementation is compact enough.  I have
> done a bit of work on the internal SSL API refactoring, so I have some
> thoughts on this patch.
>=20
> Looking at the file structure, we would have
>=20
> be-secure.c
> be-secure-openssl.c
> be-secure-[othersslimpl].c
> be-secure-gssapi.c
> be-secure-common.c
>=20
> This implies a code structure that isn't really there.
> be-secure-common.c is used by SSL implementations but not by the GSSAPI
> implementation.

be-secure-common.c seems very clearly mis-named, I mean, look at the
comment at the top of the file:

* common implementation-independent SSL support code

Seems we've been conflating SSL and "Secure" and we should probably fix
that.

What I also really don't like is that "secure_read()" is really only
*maybe* secure.  be-secure.c is really just an IO-abstraction layer that
lets other things hook in and implement the read/write themselves.

> Perhaps we should rename be-secure-openssl.c to be-ssl-openssl.c and
> be-secure-common.c to be-ssl-common.c.

This might be overly pedantic, but what we do in other parts of the tree
is use these things called directories..

I do think we need to rename be-secure-common since it's just flat out
wrong as-is, but that's independent of the GSSAPI encryption work,
really.

> Or maybe we avoid that, and you rename be-secure-gssapi.c to just
> be-gssapi.c and also combine that with the contents of be-gssapi-common.c.

I don't know why we would need to, or want to, combine
be-secure-gssapi.c and be-gssapi-common.c, they do have different roles
in that be-gssapi-common.c is used even if you aren't doing encryption,
while bs-secure-gssapi.c is specifically for handling the encryption
side of things.

Then again, be-gssapi-common.c does currently only have the one function
in it, and it's not like there's an option to compile for *just* GSS
authentication (and not encryption), or at least, I don't think that
would be a useful option to have..  Robbie?

> (And similarly in libpq.)

I do agree that we should try to keep the frontend and backend code
structures similar in this area, that seems to make sense.

> About pg_hba.conf: The "hostgss" keyword seems a bit confusing.  It only
> applies to encrypted gss-using connections, not all of them.  Maybe
> "hostgssenc" or "hostgsswrap"?

Not quite sure what you mean here, but 'hostgss' seems to be quite well
in-line with what we do for SSL...  as in, we have 'hostssl', we don't
say 'hostsslenc'.  I feel like I'm just not understanding what you mean
by "not all of them".

> I don't see any tests in the patch.  We have a Kerberos test suite at
> src/test/kerberos/ and an SSL test suite at src/test/ssl/.  You can get
> some ideas there.

Yeah, I was going to comment on that as well.  We definitely should
implement tests around this.

Thanks!

Stephen

--SorlIzCW0DSU55cr
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJccXSHAAoJEO1sijiDR2RVlOEP/3K708q7s9FZzBnnFj9td9ni
wf1m4lraj9Z/a9lN1cYEB2nmVABpvmqeR+fSZK8k5ggOz3pDosgkwyzOv4XZvDxS
r5HiZsctx0DNv9EWS7Cd2xM+plyUcvCW2T1NyF/YGMZFmuMqVXl9cy8Vqav45Tgm
JNCNNRhH788G+ezFU+cOyEk6jmpmld8SXPH3SoQJM1kJgLG7ivrRj/1B2wcBay+Z
Yg3VwGToKjIgo4wc3g5f9/Ckq/VkjuBeobiPIQroEmVJIx0SjUUy9MOtPR/GFAC2
qP3MP/CjmzuK3wavjB8+m5fF4wyLc+sIaMS3qH6mNViyRdTxZa8acXWVs8Gt6moW
1jfHcTHTmku5Uh1lMPb/xUpSUWa/FM/Uf2SYDsmZu0WbAzoe72SZ0U73pzEfdhav
JUJYpu290wkaukDC1iIjG5eIak90oEkg0Z+wwAT11OLHksIDT/zZl0243dTYGgO2
FQzBcaB6dkYKiTlsIP5OpJ4z719id9V+DNIOh30nxNbgFLew8t+bXbZNU/x161bB
kHtUwCw7oFoPA5Vo2sDw0gLtIpFMr+11Xq6aLt1zb0T84On01/DreVllGKxFEq2V
iLgddrZecJMPOICO1+HXI7+TlUB8zGpPmi4Z2M2D6dlAbG6pyeM96UuP2+tpoy8y
3gyjnQhHTWhIHud9rppe
=6Tmm
-----END PGP SIGNATURE-----

--SorlIzCW0DSU55cr--