From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Asif Naeem <anaeem(dot)it(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY |
Date: | 2015-03-04 04:30:39 |
Message-ID: | 24713.1425443439@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Sat, Feb 14, 2015 at 10:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It's not a false alarm, unfortunately, because chkpass_in actually does
>> give different results from one call to the next. We could fix the aspect
>> of that involving failing to zero out unused bytes (which it appears was
>> introduced by sloppy replacement of strncpy with strlcpy). But we can't
>> really do anything about the dependency on random(), because that's part
>> of the fundamental specification of the data type. It was a bad idea,
>> no doubt, to design the input function to do this; but we're stuck with
>> it now.
> It seems to me that fix for this issue has already been committed
> (commit-id: 80986e85). So isn't it better to mark as Committed in
> CF app [1] or are you expecting anything more related to this issue?
> [1]: https://commitfest.postgresql.org/4/144/
Ah, I didn't realize there was a CF entry for it, I think. Yeah,
I think we committed as much as we should of this, so I marked the
CF entry as committed.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-03-04 04:33:07 | Re: Comparing primary/HS standby in tests |
Previous Message | Amit Kapila | 2015-03-04 03:42:21 | Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY |