Joe, * Joe Conway (m...@joeconway.com) wrote: > On 06/13/2017 10:20 AM, Stephen Frost wrote: > > * Joe Conway (m...@joeconway.com) wrote: > >> Except shell escaping issues, etc, etc > > > > That's not an issue- we're talking about reading the stdout of some > > other process, there's no shell escaping that has to be done there. > > It could be an issue depending on how the user stores their master key.
... eh? The user gives us a command to run, we run it, it spits out some binary blob to stdout which we read in and use as the key. I don't see where in that there's any need to be concerned about shell escaping issues. > > I disagree that proper key management is "simple". If we really get to > > a point where we think we have a simple answer to it then perhaps that > > can be implemented in addition to the encryption piece in the same > > release cycle- but they certainly don't need to be in the same patch, > > nor do we need to make good key management a requirement for adding > > encryption support. > > I never said key management was simple. Indeed it is the most complex > and hazardous part of all this as you said earlier. What is simple is > implementing a master key encrypting actual keys scheme. Keeping the > user's master key management out of this design is unchanged by what I > proposed, and what I proposed is a superior yet simple method. Yes, it > can be done separately but what is the point? We should at least discuss > it as part of the design. The point is that we haven't got any encryption of any kind and you're suggesting we introduce key management which you agree isn't simple. That you're trying to argue that it actually is simple because it's just <<description of a key management system>> is a bit bizarre to me. > > No, but it seriously changes the level of complexity. I feel like we're > > trying to go from zero to light speed here because there's an idea that > > it's "simple" to add X, Y or Z additional requirement beyond the basic > > feature, but we don't have anything yet. > > I think that is hyperbole. It does not significantly add to the > complexity of what is being discussed. If I stipulate that it's, indeed, simple to implement a system where we have a master key and other keys- where are those other keys going to kept (even if they're encrypted)? How many extra keys are we talking about? When are those keys going to be used and how do we know what key to use when? If we're going to do per-tablespace or per-table encryption, how are we going to handle the WAL for that? Will we have an independent key for WAL (in which case, what's the point of using different keys for tables, et al, when all the data is in the WAL?)? Having a single key which is used cluster-wide is extremely simple and lets us get some form of encryption first before we try to tackle the more complicated multi-key/partial-encryption system. Just to be clear, I don't have any issue with discussing the idea that we want to get to a point where we can work with multiple keys and encrypt different tables with different keys (or not encrypt certain tables, et al) with the goal of implementing the single-key approach in a way that allows us to expand on it down the road easily, I just don't think we need to have it all done in the very first patch which adds the ability to encrypt the data files. Maybe you're not saying that it has to be included in the first implementation, in which case we seem to just be talking past each other, but that isn't the impression I got.. Thanks! Stephen
signature.asc
Description: Digital signature
