Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY

From: Asif Naeem <anaeem(dot)it(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY
Date: 2015-03-04 04:37:26
Message-ID: CAEB4t-O-7WLK_k511N66+N8305vgH-_WTWbM8rtCMjP54Em+GQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thank you Tom, Thank you Amit.

Regards,
Muhammad Asif Naeem

On Wed, Mar 4, 2015 at 9:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-03-04 05:03:59 Re: Bug in pg_dump
Previous Message Michael Paquier 2015-03-04 04:33:07 Re: Comparing primary/HS standby in tests