From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
Subject: | Re: Key management with tests |
Date: | 2021-01-18 17:42:54 |
Message-ID: | 20210118174254.nz6kzp6ibeql4m55@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-01-18 12:06:35 -0500, Bruce Momjian wrote:
> On Mon, Jan 18, 2021 at 10:50:37AM -0500, Bruce Momjian wrote:
> > OK, I looked at that and it is good, and I see my patch is missing that.
> > Are people looking for me to take the wiki content, expand on it and tie
> > it to the code that will be applied, or something else like all the
> > various crypto options and why we chose what we did beyond what is
> > already on the wiki? I can easily go from what we have on the wiki to
> > implementation code steps, but the other part is harder to explain and
> > that is why I offered to talk to people via voice.
>
> Just to clarify why voice calls can be helpful --- if you have to get
> into "you have to understand X to understand Y", that's where a voice
> call works best, because understanding X will require understanding
> A/B/C, and everyone's missing pieces are different, so you have to
> customize it for the individual.
I don't think anybody argued against having voice calls.
> You can explain some of this in a README, but trying to cover all of it
> leads to a combinatorial problem of trying to explain everything.
> Ideally the wiki page can be expanded so people can ask and answer all
> posted issues, perhaps in a Q&A format. Someone could go through the
> archives and post why certain decisions were made, and link to the
> original emails.
>
> I have to admit I was kind of baffled that the wiki page wasn't
> sufficient, because it is one of the longest Postgres feature
> explanations I have seen, but I now think the missing part is tying
> the wiki contents to the code implementation. If that is it, please
> confirm. If it is something else, also explain.
I don't think the wiki right now covers what's needed. The "Overview",
"Threat model" and "Scope of TDE" are a start, but beyond that it's
missing a bunch of things. And it's not in the source tree (we'll soon
have multiple versions of postgres with increasing levels of TDE
features, the wiki doesn't help with that)
Missing:
- talks about cluster wide encyrption being simpler, without mentioning
what it's being compared to, and what makes it simpler
- no differentiation from file system / block level encryption
- there's no explanation of which/why specific crypto primitives were
chosen, what the tradeoffs are
- no explanation which keys exists, stored where
- the key management patch introduces new files, not documented
- there's new types of lock files, possibility of interrupted
operations, ... - no documentation of what that means
- there's no documentation what "key wrapping" actually precisely is,
what the danger of the two-tier model is, ...
- are there dangers in not encrypting zero pages etc?
- ...
Personally, but I admit that there's legitimate reasons to differ on
that note, I don't think it's reasonable for a feature this invasive to
commit preliminary patches without the major subsequent patches being in
a shape that allows reviewing the whole picture.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Zhihong Yu | 2021-01-18 17:48:47 | Re: simplifying foreign key/RI checks |
Previous Message | Tom Lane | 2021-01-18 17:23:11 | Re: Add primary keys to system catalogs |