Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY
От | Tom Lane |
---|---|
Тема | Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY |
Дата | |
Msg-id | 28865.1423933010@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | chkpass with RANDOMIZE_ALLOCATED_MEMORY (Asif Naeem <anaeem.it@gmail.com>) |
Ответы |
Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY
|
Список | pgsql-hackers |
Asif Naeem <anaeem.it@gmail.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
В списке pgsql-hackers по дате отправления: