On Fri, Jan 15, 2021 at 7:56 PM Andres Freund <and...@anarazel.de> wrote: > I think that's not at all acceptable. I don't mind hashing out details > on calls / off-list, but the design needs to be public, documented, and > reviewable. And if it's something the community can't understand, then > it can't get in. We're going to have to maintain this going forward.
I agree. If the community is unable to clearly understand what something is, and why we should have it, then we shouldn't have it -- even if the reason is that we're too dumb to understand, as Bruce seems to be alleging. I don't really think I believe the theory that community members by and large are too dumb to understand encryption. Many features have provoked long and painful discussions about the design and yet got into the tree in the end with documentation of that design, and I don't see why that couldn't be done for this one, too. I think it can and should, and the fact that the work hasn't been done is one of several blockers for this patch. But even if I'm wrong, and the real problem is that everyone except the select group of people on these off-list phone calls are too stupid to understand this, then that's still a reason not to accept the patch. The code that's in our source tree is maintained by communal effort, and that means communal understanding is important. Frankly, it's more important in this particular case than in some others. TDE is in great demand, so if it gets into the tree, it's likely to get a lot of use. The preparatory patches, such as this one, would at that point be getting a lot of use, too. That means many people, not just hackers, will have to understand them and answer questions about them. They are also likely to get a lot of scrutiny from a security point of view, so we should have a way that we can be confident that we know why we believe them to be secure. If a security researcher shows up and says "your stuff is broken," we are not going to get away with it "no it isn't, because we discussed it on a Friday call with a closed group of people and decided it was OK." Our reasoning is going to have to be documented. That doesn't guarantee that it will be correct, but makes it possible to distinguish between defects in design, defects in particular parts of the code, and non-defects, which is otherwise impossible. Meanwhile, even if security researches are as happy with our TDE implementation as they could possibly be, a feature that changes the on-disk format can't erase our ability to solve other problems with the database. Databases using TDE are still going to have corruption, for example, but now a corrupted page has a good chance of being completely unreadable rather than just garbled. You certainly aren't going to be able to just run pg_filedump on it. I think even if we do a great job explaining to everybody what impact TDE and its preparatory patches are likely to have on the system, there's likely to be a lot of cases where users blame the database for eating their data when the real culprit is the OS or the hardware, just because such cases are bound to get harder to investigate, which could have a very negative effect on the perceptions of PostgreSQL's quality. But if the TDE itself is magic that only designated smart people on special calls can understand, then it's going to be far worse, because that'll mean when any kind of TDE problems comes up, nobody else can help debug anything. While I would like to have TDE in PostgreSQL, I would not like to have it on those terms. -- Robert Haas EDB: http://www.enterprisedb.com
