From: Robbie Harwood <rharwood@redhat.com>
To: Andres Freund <andres@anarazel.de>
Cc: Stephen Frost <sfrost@snowman.net>,
 PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
 Craig Ringer <craig@2ndquadrant.com>,
 Michael Paquier <michael.paquier@gmail.com>
Subject: Re: [PATCH v3] GSSAPI encryption support
In-Reply-To: <jlgwpufj7h8.fsf@thriss.redhat.com>
References: <jlg1tcw6owo.fsf@thriss.redhat.com>
 <CAMsr+YH0jamGmOM=mwziYQg=J-0XVp4BosPEv1n+UMaNMj4aMA@mail.gmail.com>
 <20151016133459.GL3685@tamriel.snowman.net>
 <CAMsr+YG1+HQ-V_kdBKkFX+XRV+bND0pJOygns-nbAuHEn2pj2w@mail.gmail.com>
 <20151017021105.GP3685@tamriel.snowman.net>
 <jlgwpuin3fm.fsf@thriss.redhat.com>
 <CAB7nPqT+URED7yZUPc_Soj=vfhf_r7MJD7=VonWpOFiiJE6zgg@mail.gmail.com>
 <CAB7nPqTL1SjaYn7pwb86mW1M+469=ofyyRt1Oh9dyFC_bAf_iw@mail.gmail.com>
 <jlgbnbskwya.fsf@thriss.redhat.com>
 <CAB7nPqSRFG=U3Q_R-7FPvMjNH4TsGfTdZPa7c6x868iw_h0cvw@mail.gmail.com>
 <20151022090026.GB8952@awork2.anarazel.de>
 <jlgwpufj7h8.fsf@thriss.redhat.com>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1
 (x86_64-pc-linux-gnu)
Date: Fri, 30 Oct 2015 15:38:47 -0400
Message-ID: <jlglhakxi2g.fsf@thriss.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--=-=-=
Content-Type: text/plain

Andreas, can you please weigh in here since your voice is important to
this process?

Robbie Harwood <rharwood@redhat.com> writes:

> Andres Freund <andres@anarazel.de> writes:
>
>> On 2015-10-22 16:47:09 +0900, Michael Paquier wrote:
>>> Hm, and that's why you chose this way of going. My main concern about
>>> this patch is that it adds on top of the existing Postgres protocol a
>>> layer to encrypt and decrypt the messages between server and client
>>> based on GSSAPI. All messages transmitted between client and server
>>> are changed to 'g' messages on the fly and switched back to their
>>> original state at reception. This is symbolized by the four routines
>>> you added in the patch in this purpose, two for frontend and two for
>>> backend, each one for encryption and decryption. I may be wrong of
>>> course, but it seems to me that this approach will not survive
>>> committer-level screening because of the fact that context-level
>>> things invade higher level protocol messages.
>>
>> Agreed. At least one committer here indeed thinks this approach is not
>> acceptable (and I've said so upthread).
>
> Okay, I'll make some changes.  Before I do, though, since this is not
> the approach I came up with, can you explicitly state what you're
> looking for here?  It subjectively seems that I'm getting a lot of
> feedback of "this feels wrong" without suggestion for improvement.
>
> To be clear, what I need to know is:
>
> - What changes do you want to see in the wire protocol?  (And how will
>   fallback be supported if that's affected?)
>
> - Since this seems to be an important sticking point, what files am I
>   encouraged to change (or prohibited from changing)?  (Fallback makes
>   this complex.)
>
> - I've been assuming that we care about fallback, but I'd like to be
>   told that it's something postgres actually wants to see because it's
>   the most intricate part of these changes.  (I'm reasonably confident
>   that the code becomes simpler without it, and I myself have no use for
>   it.)
>
> If I understand what you're asking for (and the above is intended to be
> sure that I will), this will not be a trivial rework, so I want to be
> really sure before doing that because writing this code a third time is
> something I don't relish.
>
> Thanks,
> --Robbie

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

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

iQIcBAEBAgAGBQJWM8dHAAoJECUy+RdqlaRC+0wQAK/I4YMdFPUmyc9wPxXgyrBM
NJDMkNslfeUrSGzmkRe6j8Hhq3XDeMMPuft8z7oqwGL5eHUlYqXgm2vCyXcVd24G
BQMfVxtyQDUG1oEYQsOKNOtjsNjpk2DnHeOYb1yj0N1hAE2dXtUnk9vh+zeLYRGX
xCmu3tQf5p/32u0rGgFyDKESvJ6Q6bhLc+zY1B28mn9OkYv2TN/3Z+rcmEgvoxF+
Q49haBLnbHpnteMdDhQ0Yx1NblPkoYF1VAdjsjpN29uDRoem8BNtTPcUdVwxnTkK
lFX+lTj6dGhJHjJsnv9JdbTFZ7d9BiG26cGrINe/jGkENvfs/AKB7zJPNv1J1ahE
roOIj2Z68vjJJ5Z3t1nCY+XNb6U3JPD8oqYAm9fMd5fWAXwaGOdNT6Wh6FGMkWWz
qskYDxZptnPR39Lp7A082J6RXSEyriry4dV3jTgKsWIixK8Db0WQ1gsG2j00zQ5d
YfmZ+Z/o5CKaut0iir8bIdBLJAS5uZ94IgFhULlRuWqTF9ZdHXDHTcxC4F5qHiXi
Ie6RSFpSJ28L2MgTvR9dXYbwp3ID42VUq5WzpKbuPFlpEbHiHjZk78jjUu9BVKyb
0gDb/vJbLOv30xxEkQIqJC6Gj0NNWL75Ixyc9sngsRiEGmOq+zFTDuIUxIbZRH62
9HDbG9TPY34ClecM7f9C
=9x2V
-----END PGP SIGNATURE-----
--=-=-=--