Re: [HACKERS] WIP: Data at rest encryption - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] WIP: Data at rest encryption
Date
Msg-id CA+TgmobSsOr7TQ7XBFGRnS2bmfsDE314qnefrEXQCBuz0S3bgQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] WIP: Data at rest encryption  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Wed, Jun 14, 2017 at 5:41 PM, Stephen Frost <sfrost@snowman.net> wrote:
> 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.

To me, this reads a bit like you're still trying to shut down the
discussion here.  Perhaps I am misreading it.

Upthread, you basically said that we shouldn't talk about key
management (specifically, you said, "Key management is an entirely
independent discussion from this") which I think is a ridiculous
statement.  We have to have some kind of simple key management in
order to have the feature at all.  It does not have to be crazy
complicated, but it has to exist.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Misnaming of staext_dependencies_load
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table