On Tue, 11 Feb 2020 at 10:57, Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2020-02-08 12:07:57 -0500, Tom Lane wrote: > > For the same reason, I don't think that an "internal key management" > > feature in the core code is ever going to be acceptable. It has to > > be an extension. (But, as long as it's an extension, whether it's > > bringing its own crypto or relying on some other extension for that > > doesn't matter from the legal standpoint.) > > I'm not convinced by that. We have optional in-core functionality that > requires external libraries, and we add more cases, if necessary. Given > that the goal of this work is to be useful for on-disk encryption, I > don't see moving it into an extension being viable?
As far as I researched it is significantly hard to implement transparent data encryption without introducing into core. Adding a hook to the point where flushing data to the disk for encryption, compression and tracking dirty blocks has ever been proposed but it has been rejected every time. > > I am somewhat doubtful that the, imo significant, complexity of the > feature is worth it, but that's imo a different discussion. > > > > > Sure, I know the code is currently calling ooenssl functions. I was > > > responding to Masahiko-san's message that we might eventually merge this > > > openssl code into our tree. > > > > No. This absolutely, positively, will not happen. There will never be > > crypto functions in our core tree, because then there'd be no recourse for > > people who want to use Postgres in countries with restrictions on crypto > > software. It's hard enough for them that we have such code in contrib > > --- but at least they can remove pgcrypto and be legal. If it's in > > src/common then they're stuck > > Isn't that basically a problem of the past by now? Partially due to > changed laws (e.g. France, which used to be a problematic case), but > also because it's basically futile to have import restrictions on > cryptography by now. Just about every larger project contains > significant amounts of cryptographic code and it's entirely impractical > to operate anything interfacing with network without some form of > transport encryption. And just about all open source distribution > mechanism have stopped separating out crypto code a long time ago. > > I however do agree that we should strive to not introduce cryptographic > code into the pg source tree It doesn't include the case where we introduce the code using openssl cryptographic function library to the core. Is that right? Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
