Horton

Re: storing an explicit nonce

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Tom Kincaid <tomjohnkincaid@gmail.com>
Date: 2021-05-26T01:16:12Z
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 Tue, May 25, 2021 at 08:03:14PM -0400, Stephen Frost wrote:
> Indeed they are, but that's not relevant to the thrust of this specific
> debate.
> 
> Bruce is arguing that because clog is unprotected that it's not useful
> to protect relation data, with regard to data integrity validation as
> provided by AES-GCM using/storing tags.  I dispute this, as relation
> data is primary data while clog, for all its value, is still metadata.
> Yes, impacting the metadata has an impact on the primary data, but it
> doesn't *change* that primary data at its core (and it's also more
> likely to be detected than random bit flipping in the relation data
> would be, which is possible if you're only encrypting and not providing
> any integrity validation).

Even if you can protect clog, this documentation paragraph makes it
clear that if you can modify the cluster, you can weaken security enough
to read and write any data you want:

https://github.com/postgres/postgres/compare/master..bmomjian:_cfe-01-doc.patch

	Cluster file encryption does not protect against unauthorized
	file system writes.  Such writes can allow data decryption if
	used to weaken the system's security and the weakened system is
	later supplied with the externally-stored cluster encryption key.
	This also does not always detect if users with write access remove
	or modify database files.

I know of no way to make that safer, so again, I don't see the value in
modification detection.  Maybe someday we would find a way, but it seems
so remote as to not warrant consideration.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.