On 22.03.22 00:51, Nathan Bossart wrote:
On Wed, Mar 16, 2022 at 11:12:06AM +0100, Peter Eisentraut wrote:
Right, the previous behaviors were clearly faulty. I have updated the
commit message to call out the behavior change more clearly.
This patch is now complete from my perspective.
I took
On Wed, Mar 16, 2022 at 11:12:06AM +0100, Peter Eisentraut wrote:
> Right, the previous behaviors were clearly faulty. I have updated the
> commit message to call out the behavior change more clearly.
>
> This patch is now complete from my perspective.
I took a look at this patch and found nothi
Interesting. I have added test cases about this. Could you describe
how you arrived at the second test case?
Sure -- that second ciphertext is the result of running
SELECT encrypt_iv('abcdefghijklmnopqrstuvwxyz', '0123456', 'abcd', 'aes');
and then incrementing the last byte of the fi
On Mon, 2022-02-21 at 11:42 +0100, Peter Eisentraut wrote:
> On 15.02.22 00:07, Jacob Champion wrote:
> > After this patch, bad padding is no longer ignored during decryption,
> > and encryption without padding now requires the input size to be a
> > multiple of the block size. To see the differenc
On 15.02.22 00:07, Jacob Champion wrote:
After this patch, bad padding is no longer ignored during decryption,
and encryption without padding now requires the input size to be a
multiple of the block size. To see the difference you can try the
following queries with and without the patch:
s
On Mon, 2022-02-14 at 10:42 +0100, Peter Eisentraut wrote:
> This is a rebase of the patch from [0]. It removes the internal padding
> implementation in pgcrypto and lets OpenSSL do it. The internal
> implementation was once applicable to the non-OpenSSL code paths, but
> those have since been
