From: Bruce Momjian <bruce@momjian.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
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: Tue, 13 Jun 2017 14:56:22 -0400
Message-ID: <20170613185622.GO13873@momjian.us> (raw)
In-Reply-To: <20170613183858.GR3151@tamriel.snowman.net>
References: <20170613160434.GC13873@momjian.us>
<20170613162301.GF3151@tamriel.snowman.net>
<20170613164442.GD13873@momjian.us>
<20170613170132.GH3151@tamriel.snowman.net>
<20170613171356.GG13873@momjian.us>
<20170613172459.GL3151@tamriel.snowman.net>
<20170613174329.GK13873@momjian.us>
<20170613182339.GP3151@tamriel.snowman.net>
<20170613182910.GN13873@momjian.us>
<20170613183858.GR3151@tamriel.snowman.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Tue, Jun 13, 2017 at 02:38:58PM -0400, Stephen Frost wrote:
> It's good to discuss what the feature would bring and what cases it
> doesn't cover, as well as discussing how it can be designed to make sure
> that later improvements are able to be done without having to change it
> around. I do think it's a good idea for us to consider taking an
> incremental approach where we're adding pieces and building things up as
> we go. I'm concerned that if we try to do too much in the initial
> implementation that we'll end up not having anything.
>
> As it relates to the different attack vectors that this would address,
> it's primairly the same ones which filesystem-level encryption also
> addresses, but it's an improvement when it comes to ease of use.
> Unfortunately, it won't address cases where the OS is compromised.
OK, so let's go back. You are saying there are no security benefits to
this vs. file system encryption. The benefit is allowing configuration
in the database rather than the OS? You stated you can transfer
db-level encrypted files between servers, but can't you do that anyway?
Is the problem that you have to encrypt before sending and decrypt on
arrival, if you don't trust the transmission link? Is that used a lot?
Is having the db encrypt every write a reasonable solution to that?
As far as future features, we don't have to add the all features at this
time, but if someone has a good idea for an API and we can make it work
easily while adding this feature, why wouldn't we do that?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
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: bruce@momjian.us, sfrost@snowman.net, peter.eisentraut@2ndquadrant.com, ants.aasma@eesti.ee, robertmhaas@gmail.com
Subject: Re: WIP: Data at rest encryption
In-Reply-To: <20170613185622.GO13873@momjian.us>
* 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