Re: Key management with tests - Mailing list pgsql-hackers
| From | Tom Kincaid |
|---|---|
| Subject | Re: Key management with tests |
| Date | |
| Msg-id | CAKPRjUNqU1KPQ2XLkAzG3Gr0PXo6q5znDFa-etzfpG=0reKj-w@mail.gmail.com Whole thread Raw |
| In response to | Re: Key management with tests (Bruce Momjian <bruce@momjian.us>) |
| Responses |
Re: Key management with tests
(Bruce Momjian <bruce@momjian.us>)
|
| List | pgsql-hackers |
Hello,
> I don't think it makes sense to think about committing this to v14. I
> believe it only makes sense if we have a TDE patch that is relatively
> close to committable that can be used with it. I also don't think that
> this patch is in good enough shape to commit yet in terms of where
> it's at in terms of quality; I think it needs more review first,
> hopefully including review from people who can comment intelligently
> specifically on the cryptography aspects of it. However, the
> challenges don't seem insurmountable. There's also still some question
> in my mind about whether the design choices here (one KEK, 2 DEKs, one
> for data and one for WAL) have enough consensus. I don't have a
> considered opinion on that, partly because I'm not quite sure what the
> reasonable alternatives are, but it seems that other people had some
> questions about it, IIUC.
While I am willing to make requested adjustments to the patch, I don't
plan to work on this feaure any further, assuming your analysis above is
correct. If after years we are still not sure this is the right
direction, I don't see any point in moving forward with the later
pieces, which are even more complicated. I will join the group of
people that feel there will never be consensus on implementing this
feature in the community, so it is not worth trying.
I would also like to add a "not wanted" entry for this feature on the
TODO list, baaed on the feature's limited usefulness, but I already
asked about that and no one seems to feel we don't want it.
I want to avoid seeing this happen. As a result of a lot of customer and user discussions, around their criteria for choosing a database, I believe TDE is an important feature and having it appear with a "not-wanted" tag will keep the version of PostgreSQL released by the community out of certain (and possibly growing) number of deployment scenarios which I don't think anybody wants to see.
I think the current situation to be as follows (if I missed something please let me know):
1) We need to get the current patch for Key Management reviewed and tested further.
I spoke to Bruce just now he will see if can get somebody to do this.
2) We need to start working on the actual TDE implementation and get it pretty close to final before we start committing smaller portions of the feature.
Unfortunately, on this front, the only things, I think I can offer are:
a) Ask for volunteers to work on the TDE implementation.
b) Facilitate the work between volunteers.
c) Prod folks along and cheer as we go.
So I will start with (a), do we have any volunteers who feel they can contribute regularly for a while and would like to be part of a team that moves this forward?
I now better understand why the OpenSSL project has had such serious
problems in the past.
Updated patch attached as seven attachments.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Thomas John Kincaid
pgsql-hackers by date: