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 +
