Re: Proposal: Save user's original authenticated identity for logging

On Mon, 2021-03-22 at 18:22 +0100, Magnus Hagander wrote:
> On Mon, Mar 22, 2021 at 7:16 AM Michael Paquier <michael@paquier.xyz> wrote:
> > 
> > I have briefly looked at 0002 (0001 in the attached set), and it seems
> > sane to me.  I still need to look at 0003 (well, now 0002) in details,
> > which is very sensible as one mistake would likely be a CVE-class
> > bug.
> 
> The 0002/0001/whateveritisaftertherebase is tracked over at
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.postgresql.org%2Fmessage-id%2Fflat%2F92e70110-9273-d93c-5913-0bccb6562740%40dunslane.net&amp;data=04%7C01%7Cpchampion%40vmware.com%7Cd085c1e56ff045c7af3308d8ed57279a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637520305878415422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=kyW9O1jD0z14z0rC%2BYY9UhIKb7D6bg0nCWoVBJkF8oQ%3D&amp;reserved=0
> isn't it? I've assumed the expectation is to have that one committed
> from that thread, and then rebase using that.

I think the primary thing that needs to be greenlit for both is the
idea of using the RFC 2253/4514 format for Subject DNs.

Other than that, the version here should only contain the changes
necessary for both features (that is, port->peer_dn), so there's no
hard dependency between the two. It's just on me to make sure my
version is up-to-date. Which I believe it is, as of today.

--Jacob