Scratch that, rather than memset(...) should be explicit_bzero(...) so it
doesn't get optimized out. Same idea though.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
>
are invoked.
Even if it's not added to the password encoding functions (as that kind of
changes the after effects if anything was relying on the password still
having the password), I think it'd be good to add it to the command.c stuff
that has the two copies of the password prior to freei
On Sat, Jan 6, 2024 at 11:53 AM Joe Conway wrote:
> On 1/2/24 07:23, Sehrope Sarkuni wrote:
> > 1. There's two sets of defaults, the client program's default and the
> > server's default. Need to pick one for each implemented function. They
> > don't nee
:
https://www.postgresql.org/message-id/1d669d97-86b3-a5dc-9f02-c368bca911f6%40iki.fi
[2]:
https://www.postgresql.org/message-id/flat/ZV149Fd2JG_OF7CM%40momjian.us#cc97d20ff357a9e9264d4ae14e96e566
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
t; in this case is explicit as I'm adding it when building the
object. What I was trying to show was not adding an additional object
wrapper / envelope.
So each row is:
{"foo":1}
Rather than:
"{"json_build_object":{"foo":1}}
If each row has exactly one j
other: json_build_object('some_field",
my_field_i_want_wrapped)
The duplicate field names would be a good test case too. I haven't gone
through this patch but I'm guessing it doesn't filter out duplicates so the
behavior would match up with row_to_json(...), i.e. duplicates a
CASE WHEN x > 1 THEN x END) FROM
generate_series(1, 3) x) TO STDOUT WITH (FORMAT JSON,
SOME_OPTION_TO_NOT_ENVELOPE, JSON_SKIP_NULLS)
{}
{"foo":2}
{"foo":3}
3. Reverse of #2 when copying data in to allow defaulting missing fields to
NULL.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
The intro in "E.1.3. Changes" says "... between PostgreSQL 15 and the
previous major release".
That should be "... between PostgreSQL __16__ ..." right?
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
Oids = palloc(length+1);
> ...
> + tmpOids = repalloc(tmpOids, length+1);
These should be: sizeof(Oid) * (length + 1)
Also, I think you need to specify an explicit context via
MemoryContextAlloc or the allocated memory will be in the default context
and released at the end of the command.
for
checking rotation size, performing the actual rotation, and closing. Also
one other to handle generating the logfile names with a suffix to handle
the pfree-ing (wrapping logfile_open(...)).
The rest of the changes happen in place using the new structures.
Regards,
-- Sehrope Sark
gards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
>
From 0f7978566b7770465060cd497a8dd4102b313878 Mon Sep 17 00:00:00 2001
From: Sehrope Sarkuni
Date: Thu, 16 Sep 2021 14:43:31 -0400
Subject: [PATCH 1/3] Add constant for list of log destinations that use fil
d to try out the forking
code paths. Definitely needs some review to ensure it's functionally
correct for the different log files.
I haven't tried splitting the csvlog code out or adding the new jsonlog
atop this yet. There's enough changes here that I'd like to get
free() and NULL checks.
> The rebased patch set, that has reworked the tests to be in line with
> HEAD, also fails. They compile.
>
> Sehrope, could you adjust that?
Yes I'm looking to sync those up and address the above later this week.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
s all it's
really doing is invoking the new write_jsonlog(...) function.
It also adds those missing fields to the JSON logger output.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
From d5b3f5fe44e91d35aefdd570758d5b2a9e9c1a36 Mon Sep 17 00:00:00 2001
On Tue, Aug 31, 2021 at 8:43 PM Michael Paquier wrote:
> On Tue, Aug 31, 2021 at 11:34:56AM -0400, Sehrope Sarkuni wrote:
> > The second commit adds a TAP test for log_destination "csvlog". This was
> > done to both confirm that the previous change didn't break an
":"[local]","session_id":"612e397d.2eec","line_num":1,"ps":"idle","session_start":"2021-08-31
10:15:25
EDT","vxid":"3/2","txid":"0","error_severity":"LOG",&
sonlog" destination.
It needed some cleanup due to bit rot, but it now builds and works atop
master. I'll post it in its own thread.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
ntroducing a new type. After sleeping about it,
> I think that I would just make MD5 and SHA1 issue an elog(ERROR) if
> the internal routine is taken in those cases, like in the attached.
>
The refactor patch looks good. It builds and passes make check.
Thanks for the enum explanation
es that by writing the digest final directly to
the result. It also removes the digest length arg and determines it in the
switch block. There's only one correct digest length for each type so
there's no reason to give callers the option to give the wrong one.
Regards,
-- Sehrope S
ize_t srclen)
{
- return (srclen >> 1);
+ return (uint64) srclen >> 1;
}
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
Typo in 9.4 retirement message:
s/is it time to retire/it is time to retire/
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
On Sat, Feb 1, 2020 at 7:02 PM Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Sun, 2 Feb 2020 at 00:37, Sehrope Sarkuni wrote:
> >
> > On Fri, Jan 31, 2020 at 1:21 AM Masahiko Sawada
> > wrote:
> > > On Thu, 30 Jan 2020 at 20:36, Sehrope Sarkun
On Fri, Jan 31, 2020 at 1:21 AM Masahiko Sawada
wrote:
> On Thu, 30 Jan 2020 at 20:36, Sehrope Sarkuni wrote:
> > That
> > would allow the internal usage to have a fixed output length of
> > LEN(IV) + LEN(HMAC) + LEN(DATA) = 16 + 32 + 64 = 112 bytes.
>
> Probably you
again after the patch is complete as it'll be
easier to see overlaps that could be combined.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
to infer the specific cipher/mac combo (Ex: v1 would be
AES256/HMAC-SHA256). I don't think the added size is an issue as
again, the output is opaque. Similar things can also be accomplished
by combining the 16-byte only version with pgcrypto but like this it'd
be usable out of the box witho
nds. That'd give backwards
compatibility too. The main limitation compared to a shared library is
that you'd still have to explicitly pick and name the exposed argument
environment variables (i.e. like picking the set of %? substitutions).
If there's a generic shared-library-for-external-com
> * Several fixes for logical replication, including a failure when the
> publisher
> & subscriber had different REPLICA IDENTITY columns set.
"&" should probably be "and" as I don't see it used like that in any
other release notes.
Regards,
-- S
The "Upgrading to PostgreSQL 12 RC 1" references v11 rather than v12:
"To upgrade to PostgreSQL 11 RC 1 from Beta 4 or an earlier version of
PostgreSQL 11, ..."
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
On Sat, Aug 17, 2019 at 12:43 PM Ibrar Ahmed wrote:
> +1 for voice call, bruce we usually have a weekly TDE call.
>
Please add me to the call as well. Thanks!
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
DEK would
involve decrypting / encrypting everything rather than just copying the
files. Even if that's not baked in a first version, the separation allows
for eventually supporting that.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
On Thu, Aug 8, 2019 at 2:16 PM Bruce Momjian wrote:
> On Wed, Aug 7, 2019 at 08:56:18AM -0400, Sehrope Sarkuni wrote:
> > Simplest approach for derived keys would be to use immutable attributes
> of the
> > WAL files as an input to the key derivation. Something like HKDF(MDEK,
On Wed, Aug 7, 2019 at 1:39 PM Bruce Momjian wrote:
> On Wed, Aug 7, 2019 at 11:41:51AM -0400, Sehrope Sarkuni wrote:
> > On Wed, Aug 7, 2019 at 7:19 AM Bruce Momjian wrote:
> >
> > On Wed, Aug 7, 2019 at 05:13:31PM +0900, Masahiko Sawada wrote:
> > &
ummy partial
block. The EVP read and write functions both deal with individual bytes so
once you've seeked to your desired offset you can read or write the real
individual bytes.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
On Mon, Aug 5, 2019 at 9:02 PM Bruce Momjian wrote:
> On Wed, Jul 31, 2019 at 09:25:01AM -0400, Sehrope Sarkuni wrote:
> > Even if we do not include a separate per-relation salt or things like
> > relfilenode when generating a derived key, we can still include other
> type
tency is nice but either reads fine to me. Only brought it up
as I didn't see many other usages so seemed out of place.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
commit message to match
some similar ones I found in the past.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
From 20c018b9350cb17e87930cebb66b715bc4b9fcf4 Mon Sep 17 00:00:00 2001
From: Sehrope Sarkuni
Date: Fri, 2 Aug 2019 05:58:35 -0400
Subject:
Hi,
Attached fixes some typos for "serialise" => "serialize" and "materialise"
=> "materialize".
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
From 30d34d082120ac2c041a4ad45e9d6e31b0ea9c9d Mon Sep 17 00:00:00
;s not a problem. Is that right?
>
Ah, this is what I was referring to in my previous mail. I'm not familiar
with how the writes happen yet (reading up...) but, yes, we would need to
ensure that encrypted data is not written more than once (i.e. no writing
of encrypt(zero) followed by wr
porate it. It could be part of each
encrypted record or its own summary record (providing a MAC for a series of
WAL records). After I've gone through this a bit more I'm looking to put
together a write up with this and some other thoughts in one place.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
On Tue, Jul 30, 2019 at 10:06 AM Masahiko Sawada
wrote:
> On Tue, Jul 30, 2019 at 5:03 AM Sehrope Sarkuni
> wrote:
> >
> > On Mon, Jul 29, 2019 at 9:44 AM Bruce Momjian wrote:
> >>
> >> > Checking that all buffers using a single LSN are from the same
>
On Tue, Jul 30, 2019 at 8:16 AM Bruce Momjian wrote:
> On Tue, Jul 30, 2019 at 07:44:20AM -0400, Sehrope Sarkuni wrote:
> > If each relation file has its own derived key, the derived TDEK for that
> > relation file, then there is no issue with reusing the same IV = LSN ||
> Pa
On Tue, Jul 30, 2019 at 8:16 AM Masahiko Sawada
wrote:
> On Mon, Jul 29, 2019 at 8:18 PM Sehrope Sarkuni
> wrote:
> >
> > On Mon, Jul 29, 2019 at 6:42 AM Masahiko Sawada
> wrote:
> > > > An argument could be made to push that problem upstream, i.e. let the
&
the next page's IV's range.
I ran the regression tests with asserts on and got no failures, so I
> think we are good.
>
It's not strictly required but it also doesn't hurt that LSN is unique
per-relation so that's still good news!
Might be useful for something
On Mon, Jul 29, 2019 at 4:15 PM Alvaro Herrera
wrote:
> On 2019-Jul-27, Sehrope Sarkuni wrote:
>
> > Given the non-cryptographic nature of CRC and its 16-bit size, I'd
> > round down the malicious tamper detection it provides to zero. At best
> > it catches random
for pages without a lot more complexity to
keep track of which key version to use based upon the LSN.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
se or moving a tablespace, having that be
simpler/faster seems like a good idea. It could be a known limitation like
the promoting of multiple replicas. Plus with a key rotation tool anyone
that wants everything re-encrypted could run one after the copy.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
using the same key or via a separate derived
MDEK-MAC key). If the computed MAC matches against the previously
stored value then you know the MDEK is correct as well.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
enticating against a stored MAC. If you're going to do that,
might as well directly support decrypting and managing your own MDEK.
That also let's you ensure it was properly generated via strong random
source.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
ul malicious tamper detection. And
even that would have to be off-page to deal with page replay (which I
think is out of scope).
[1]: https://en.wikipedia.org/wiki/CRC-32#Data_integrity
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
of this logic.
*/
static void
walkdir(const char *path,
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
ght reasons. With a generic
"messed up fsync" harness you might even be able to run some existing tests
that would otherwise pass and check for the fsync-specific exit code.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
On Thu, Jul 25, 2019 at 8:50 PM Bruce Momjian wrote:
> On Thu, Jul 25, 2019 at 08:44:40PM -0400, Sehrope Sarkuni wrote:
> > You can still use CTR mode and include those to make the key + IV unique
> by
> > adding them to the derived key rather than the IV.
> >
> >
ifferent IVs), that uses 12 bytes:
>
> LSN 8 bytes
> page-number 4 bytes
>
> That leaves 4 bytes unused. If we use CTR, we need 11 bits for the
> counter to support 32k pages sizes (per Sehrope Sarkuni), and we can use
> the remaining 5 bits as constant
quot;is_encrypted" flag
or a handful of bits used to infer a derived key. For example, with
2-bits you could have 00 represent unencrypted, 01/10 represent
old/new key, and 11 be future use. Something like that could
facilitate online key rotation.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
e encrypted data as each byte is encrypted
separately. At decryption time you simply ignore the decrypted output
of those bytes and zero them out again. A CRC of encrypted data (but
not a partial MAC) could be checked offline without access to the key.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
/www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
roach as the
new log destination would be built atop it. I leaning toward #3 though
if the 4-byte loss is a deal breaker then #2.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
From 9ec38a587b0c2645bc9fd73398c1debdf9fa962b Mon Sep 17 00:00:00 2001
From:
and concurrent generation.
The repo includes a PG extension and sample app code for generating tuids
in a couple languages as well as a pure-SQL one (though that one uses
random() rather than get_random_bytes() so I'd consider it more of an proof
of concept).
Regards,
-- Sehrope Sarkuni
Founder
58 matches
Mail list logo
