Re: WIP: Data at rest encryption

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Bruce Momjian <bruce@momjian.us>, Ants Aasma <ants.aasma@eesti.ee>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-06-15T16:06:49Z
Lists: pgsql-hackers
On 6/14/17 17:41, Stephen Frost wrote:
>> Relying on environment variables is clearly pretty crappy.  So if that's
>> the proposal, then I think it needs to be better.
> I don't believe that was ever intended to be the final solution, I was
> just pointing out that it's what the WIP patch did.
> 
> The discussion had moved into having a command called which provided the
> key on stdout, as I recall, allowing it to be whatever the user wished,
> including binary of any kind.
> 
> If you have other suggestions, I'm sure they would be well received.  As
> to the question of complexity, it certainly looks like it'll probably be
> quite straight-forward for users to use.

I think the passphrase entry part of the problem is actually a bit
harder than it appears.

Making this work well would be a major part of the usability story that
this is being sold on.  If the proposed solution is that you can cobble
together a few bits of shell, then not only is that not very
user-friendly, it also won't work consistently across platforms, won't
work under systemd (launchd? Windows service?), and might behave
awkwardly under restricted environments where there is no terminal or
only a limited OS environment.  Moreover, it leaves the security aspects
of that part of the solution (keys lingering in memory or in swap) up to
the user.

There was a discussion a while ago about how to handle passphrase entry
for SSL keys.  The conclusion was that it works pretty crappily right
now, and several suggestions for improvement were discussed.  I suggest
that fixing that properly and with flexibility could also yield a
solution for encryption key entry.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. Dramatically reduce System V shared memory consumption.