Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY

Asif Naeem <anaeem(dot)it(at)gmail(dot)com> writes:
> It is been observed on RANDOMIZE_ALLOCATED_MEMORY enabled PG95 build that
> chkpass is failing because of uninitialized memory and seems showing false
> alarm.

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.

> I think these uninitialized memory areas are false alarms. Along with this
> there seems another issue that makes chkpass troubling
> RANDOMIZE_ALLOCATED_MEMORY comparison logic is that crypt() function is
> being passed with random salt value for DES based result. PFA patch, to
> generate consistent results, it uses constant salt value.

This is a seriously awful idea. You can't break the fundamental behavior
of a data type (especially not in a way that introduces a major security
hole) just for the convenience of some debugging option or other.

regards, tom lane