|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Daniel Gustafsson <daniel(at)yesql(dot)se>|
|Cc:||Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Refactoring base64 encoding and decoding into a safer interface|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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 src/common/scram-common.c there are a few instances like this. Shouldn’t we
> also free the result buffer in these cases?
> +#ifdef FRONTEND
> + return NULL;
> 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. Good point. I have not thought of that, and your suggestion
Another question is if we'd want to actually use explicit_bzero()
here, but that could be a discussion on this other thread, except if
the patch discussed there is merged first:
Attached is an updated patch.
|Next Message||Paul Guo||2019-07-02 05:46:21||Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown)|
|Previous Message||Julien Rouhaud||2019-07-02 05:12:38||Re: cleanup & refactoring on reindexdb.c|