Horton

Re: storing an explicit nonce

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Bruce Momjian <bruce@momjian.us>, 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-27T20:13:44Z
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.

On 2021-May-27, Andres Freund wrote:

> On 2021-05-27 15:48:09 -0400, Robert Haas wrote:

> > Another case where this sort of thing might happen is a standby doing
> > whatever the master did. I suppose that could be avoided if the
> > standby always has its own encryption keys, but that forces a key
> > rotation when you create a standby, and it doesn't seem like a lot of
> > fun to insist on that. But the information leak seems minor.
> 
> Which leaks seem minor? The "hole" issues leak all the prior contents of
> the hole, without needing any complicated analysis of the data, because
> one plain text is known (zeroes).

Maybe that problem could be solved by having PageRepairFragmentation,
compactify_tuples et al always fill the hole with zeroes, in encrypted
databases.

-- 
Álvaro Herrera       Valdivia, Chile