Horton

Re: storing an explicit nonce

Shruthi Gowda <gowdashru@gmail.com>

View thread
From: Shruthi Gowda <gowdashru@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, 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-08-11T07:41:05Z
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.

Attachments

On Fri, May 28, 2021 at 2:39 AM Stephen Frost <sfrost@snowman.net> wrote:
>
> Greetings,
>
> * Bruce Momjian (bruce@momjian.us) wrote:
> > On Thu, May 27, 2021 at 04:09:13PM -0400, Stephen Frost wrote:
> > > The above article, at least, suggested encrypting the sector number
> > > using the second key and then multiplying that times 2^(block number),
> > > where those blocks were actually AES 128bit blocks.  The article further
> > > claims that this is what's used in things like Bitlocker, TrueCrypt,
> > > VeraCrypt and OpenSSL.
> > >
> > > While the documentation isn't super clear, I'm taking that to mean that
> > > when you actually use EVP_aes_128_xts() in OpenSSL, and you provide it
> > > with a 256-bit key (twice the size of the AES key length function), and
> > > you give it a 'tweak', that what you would actually be passing in would
> > > be the "sector number" in the above method, or for us perhaps it would
> > > be relfilenode+block number, or maybe just block number but it seems
> > > like it'd be better to include the relfilenode to me.
> >
> > If you go in that direction, you should make sure pg_upgrade preserves
> > what you use (it does not preserve relfilenode, just pg_class.oid), and
> > CREATE DATABASE still works with a simple file copy.
>
> Ah, yes, good point, if we support in-place pg_upgrade of an encrypted
> cluster then the tweak has to be consistent between the old and new.
>
> I tend to agree with Andres that it'd be reasonable to make CREATE
> DATABASE do a bit more work for an encrypted cluster though, so I'm less
> concerned about that.
>
> Using pg_class.oid instead of relfilenode seems likely to complicate
> things like crash recovery though, wouldn't it?  I wonder if there's
> something else we could use.
>
Hi,
I have extracted the preserving relfilenode and dboid from [1] and
rebased on the current head. While tested I have found a few issues.

- Variable' dbDumpId' was not initialized before passing to
ArchiveEntry() in dumpDatabase() function due to which pg_upgrade was
failing with 'bad dumpId' error
- 'create_storage' flag was set as TRUE irrespective of relkind which
resulted in hitting assert when the source cluster had TYPE in it.
- In createdb() flow, ''dboid' was set to the preserved dboid in wrong
place. It was eventually overwritten and caused problems while
restoring the DB
- Removed the restriction on dumping the postgres DB OID

I have fixed all the issues and now the patch is working as expected.

[1] https://www.postgresql.org/message-id/7082.1562337694@localhost


Regards,
Shruthi KC
EnterpriseDB: http://www.enterprisedb.com