Re: storing an explicit nonce
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Robert Haas <robertmhaas@gmail.com>, Ants Aasma <ants@cybertec.at>, Sasasu <i@sasa.su>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-11T16:56:34Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rethink method for assigning OIDs to the template0 and postgres DBs.
- 2cb1272445d2 15.0 landed
-
pg_upgrade: Preserve database OIDs.
- aa01051418f1 15.0 landed
-
pg_upgrade: Preserve relfilenodes and tablespace OIDs.
- 9a974cbcba00 15.0 landed
-
Fix for new Boolean node
- cf925936ecc0 15.0 cited
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Add macro RelationIsPermanent() to report relation permanence
- 95d77149c535 14.0 landed
-
Enhance nbtree index tuple deletion.
- d168b666823b 14.0 cited
On Thu, Oct 7, 2021 at 11:32:07PM -0400, Stephen Frost wrote: > Part of the meeting was specifically about "why are we doing this?" and > there were a few different answers- first and foremost was "because > people are asking for it", from which followed that, yes, in many cases > it's to satisfy an audit or similar requirement which any of the > proposed methods would address. There was further discussion that we Yes, Cybertec's experience with their TDE patch's adoption supported this. > could address *more* cases by providing something better, but the page > format changes were weighed against that and the general consensus was > that we should attack the simpler problem first and, potentially, gain > a solution for 90% of the folks asking for it, and then later see if > there's enough interest and desire to attack the remaining 10%. It is more than just the page format --- it would also be the added code, possible performance impact, and later code maintenance to allow for are a more complex or two different page formats. As an example, I think the online checksum patch failed because it wasn't happy with that 90% and went for the extra 10% of restartability, but once you saw the 100% solution, the patch was too big and was rejected. > As such, it's just not so simple as "what is 'secure enough'" because it > depends on who you're talking to. Based on the collective discussion at > the meeting, XTS is 'secure enough' for the needs of probably 90% of > those asking, while the other 10% want better (an AEAD method such as > GCM or GCM-SIV). Therefore, what should we do? Spend all of the extra > resources and engineering effort to address the 10% and maybe not get > anything because of the level of difficulty, or go the simpler route > first and get the 90%? Through that lense, the choice seemed reasonably > clear, at least to me, hence why I agreed that we should work on an XTS > based approach first. Yes, that was the conclusion. I think it helped to have the discussion verbally with everyone hearing every word, rather than via email where people jump into the discussion not hearing earlier points. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.