|From:||Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|Cc:||Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: WIP: Data at rest encryption|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, Jun 13, 2017 at 09:07:49AM -0400, Peter Eisentraut wrote:
> On 6/12/17 17:11, Ants Aasma wrote:
> > I'm curious if the community thinks this is a feature worth having?
> > Even considering that security experts would classify this kind of
> > encryption as a checkbox feature.
> File system encryption already exists and is well-tested. I don't see
> any big advantages in re-implementing all of this one level up. You
> would have to touch every single place in PostgreSQL backend and tool
> code where a file is being read or written. Yikes.
I appreciate your work, but unfortunately I must agree with Peter.
On Linux you can configure the full disc encryption using LUKS /
dm-crypt in like 5 minutes . On FreeBSD you can do the same using
geli . In my personal opinion PostgreSQL is already complicated
enough. A few companies that hired system administrators that are too
lazy to read two or three man pages is not a reason to re-implement file
system encryption (or compression, or mirroring if that matters) in any
open source RDBMS.
|Next Message||Ashutosh Bapat||2017-06-14 10:15:35||Re: A bug in mapping attributes in ATExecAttachPartition()|
|Previous Message||Marina Polyakova||2017-06-14 08:48:25||WIP Patch: Pgbench Serialization and deadlock errors|