From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Ants Aasma <ants.aasma@eesti.ee>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: WIP: Data at rest encryption
Date: Thu, 15 Jun 2017 12:06:49 -0400
Message-ID: <0b5611b8-af0f-152d-9c38-222b081c71ac@2ndquadrant.com> (raw)
In-Reply-To: <20170614214119.GL1769@tamriel.snowman.net>
References: <20170613172459.GL3151@tamriel.snowman.net>
<20170613174329.GK13873@momjian.us>
<20170613182339.GP3151@tamriel.snowman.net>
<20170613182910.GN13873@momjian.us>
<20170613183858.GR3151@tamriel.snowman.net>
<20170613185622.GO13873@momjian.us>
<20170613192011.GS3151@tamriel.snowman.net>
<a2fa2930-5334-c926-01ee-4a01c605b7a4@2ndquadrant.com>
<20170613221104.GT3151@tamriel.snowman.net>
<9cea5160-c64b-0b9e-d4b7-c57db2a696be@2ndquadrant.com>
<20170614214119.GL1769@tamriel.snowman.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter.eisentraut@2ndquadrant.com, sfrost@snowman.net, bruce@momjian.us, ants.aasma@eesti.ee, robertmhaas@gmail.com
Subject: Re: WIP: Data at rest encryption
In-Reply-To: <0b5611b8-af0f-152d-9c38-222b081c71ac@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox