On Tue, Jul 02, 2019 at 09:56:03AM +0200, Daniel Gustafsson wrote:
> Looks good, passes tests, provides value to the code. Bumping this to ready
> for committer as I no more comments to add.
Thanks. I have spent more time testing the different error paths and
the new checks in base64.c, and comm
On Tue, Jul 02, 2019 at 09:56:03AM +0200, Daniel Gustafsson wrote:
> I’m not sure we need to go to that length, but I don’t have overly strong
> opinions. I think of this more like a case of “we’ve changed the API with new
> errorcases that we didn’t handle before, so we’re being a little defensiv
> On 2 Jul 2019, at 07:41, Michael Paquier wrote:
>> In the below passage, we leave the input buffer with a non-complete
>> encoded string. Should we memset the buffer to zero to avoid the
>> risk that code which fails to check the return value believes it has
>> an encoded string?
>
> Hmm. Go
On Mon, Jul 01, 2019 at 11:11:43PM +0200, Daniel Gustafsson wrote:
> I very much agree that functions operating on a buffer like this should have
> the size of the buffer in order to safeguard against overflow, so +1 on the
> general concept.
Thanks for the review!
> A few small comments:
>
> In
> On 23 Jun 2019, at 15:25, Michael Paquier wrote:
> Attached is a refactoring patch for those interfaces, which introduces
> a set of overflow checks so as we cannot repeat errors of the past.
I’ve done a review of this submission. The patch applies cleanly, and passes
make check, ssl/scram te
Hi all,
After the issues behind CVE-2019-10164, it seems that we can do much
better with the current interface of decoding and encoding functions
for base64 in src/common/.
The root issue is that the callers of pg_b64_decode() and
pg_b64_encode() provide a buffer where the result gets stored whic
