Hi Kenneth, > > > 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 [1]. On FreeBSD you can do the same using > > geli [2]. 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. > > While I agree that configuring full disk encryption is not technically > difficult, it requires much more privileged access to the system and > basically requires the support of a system administrator. In addition, > if a volume is not available for encryption, PostgreSQL support for > encryption would still allow for its data to be encrypted and as others > have mentioned can be enabled by the DBA alone.
Frankly I'm having difficulties imagining when it could be a real problem. It doesn't seem to be such a burden to ask a colleague for assistance in case you don't have sufficient permissions to do something. And I got a strong feeling that solving bureaucracy issues of specific organizations by changing PostgreSQL core in very invasive way (keeping in mind testing, maintaining, etc) is misguided. -- Best regards, Aleksander Alekseev
signature.asc
Description: PGP signature