Re: BUG #16476: pgp_sym_encrypt_bytea with compress-level=6 : Wrong key or corrupt data

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Wong <mark(at)2ndquadrant(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, jeff(dot)janes(at)gmail(dot)com, frank(dot)gagnepain(at)intm(dot)fr, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16476: pgp_sym_encrypt_bytea with compress-level=6 : Wrong key or corrupt data
Date: 2020-07-27 07:16:35
Message-ID: 20200727071635.GD1988@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jul 23, 2020 at 03:38:43PM -0400, Tom Lane wrote:
> I dug into this problem with access kindly provided by Mark Wong, and
> verified that indeed the zlib on that machine acts a bit differently
> from stock zlib. The problem we're facing turns out to be entirely
> unrelated to the patch at hand; it's the *compression* side that is
> misbehaving. After some digging in the code and reading the zlib.h
> API spec carefully, the answer is that compress_process() completely
> mishandles the situation where deflate() stops short of consuming all
> the input that's supplied. It resets the next_in pointer so that
> old data is reprocessed, rather than allowing the remaining unprocessed
> data to be processed.

Good catch. Thanks.

> Anyway, with that corrected, the SLES zlib still produces different
> output from stock zlib, and indeed seemingly is worse: the result
> is noticeably larger than what stock zlib produces. It does decompress
> back to the same thing, though, so this is a performance problem not
> a data corruption issue. That does mean that the proposed test case
> fails to exercise our empty-ending-block scenario with this version
> of zlib. I don't think we really care about that, though.

One simple method to test this code path would be to just decompress a
hardcoded bytea value that got weirdly compressed. I am not sure
either if that's worth the cycles, and I think that it would bloat the
test files a bit.

> I will go apply this fix, and then you can put back the fix for
> the originally-reported problem. I still like Horiguchi-san's
> fix better than what was committed, though.

Back into business for this issue.. And I have been able to work more
on a SLES15 box thanks to Mark, confirming that b9b6105 got rid of the
compression issue with the test of 9e10898, and that the previous
versions of the patches would take care of the issue for the
decompression now if compressed data was incorrectly shaped.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2020-07-27 17:07:39 BUG #16557: getProcedureColumns() function returns columns, when there is no existing Stored Procedure in the DB
Previous Message Oleksandr Shulgin 2020-07-27 06:23:03 Re: pg_dump seems to be broken in regards to the "--exclude-table-data" option on Windows.