Horton

Re: storing an explicit nonce

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Masahiko Sawada <sawada.mshk@gmail.com>, Tom Kincaid <tomjohnkincaid@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Date: 2021-05-27T18:05:59Z
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 →

  1. Rethink method for assigning OIDs to the template0 and postgres DBs.

  2. pg_upgrade: Preserve database OIDs.

  3. pg_upgrade: Preserve relfilenodes and tablespace OIDs.

  4. Fix for new Boolean node

  5. Improve error handling of HMAC computations

  6. Add macro RelationIsPermanent() to report relation permanence

  7. Enhance nbtree index tuple deletion.

Hi,

On 2021-05-27 12:00:03 -0400, Bruce Momjian wrote:
> On Wed, May 26, 2021 at 05:02:01PM -0400, Bruce Momjian wrote:
> > Rather than surprise anyone, I might as well just come out and say some
> > things.  First, I have always admitted this feature has limited
> > usefulness.  
> > 
> > I think a non-LSN nonce adds a lot of code complexity, which adds a code
> > and maintenance burden.  It also prevents the creation of an encrypted
> > replica from a non-encrypted primary using binary replication, which
> > makes deployment harder.
> > 
> > Take a feature of limited usefulness, add code complexity and deployment
> > difficulty, and the feature becomes even less useful.
> > 
> > For these reasons, if we decide to go in the direction of using a
> > non-LSN nonce, I no longer plan to continue working on this feature. I
> > would rather work on things that have a more positive impact.  Maybe a
> > non-LSN nonce is a better long-term plan, but there are too many
> > unknowns and complexity for me to feel comfortable with it.
> 
> [...]
> I suspect that if we start adding a non-LSN nonce and malicious write
> detection, we will end up with the same problem --- a complex patch for
> a feature that has limited usefulness, and requires dump/restore or
> logical replication to add it to a cluster.  I think such a patch would
> be rejected, and I would probably even vote against it myself.

I think it's diametrically the opposite. Using the LSN as the nonce
requires that all code modifying pages needs to be audited (which
clearly hasn't been done yet), whereas an independent nonce can be
maintained in a few central places. And that's not just a one-off issue,
it's a forevermore issue.

Greetings,

Andres Freund