On Sun, Jan 13, 2013 at 07:01:07PM -0500, Noah Misch wrote:
> On Sun, Jan 13, 2013 at 05:46:12PM -0500, Tom Lane wrote:
> > Marko Kreen writes:
> > > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
> > >> How about instead calling RAND_cleanup() after each backend fork?
> >
> > > Attached is
On Mon, Jan 14, 2013 at 03:42:42PM +0200, Marko Kreen wrote:
> On Mon, Jan 14, 2013 at 3:00 PM, Noah Misch wrote:
> > On Mon, Jan 14, 2013 at 02:21:00PM +0200, Marko Kreen wrote:
> >> Note: reading from /dev/urandom does not affect /dev/random.
> >
> > Reading from /dev/urandom drains the pool tha
On Mon, Jan 14, 2013 at 3:00 PM, Noah Misch wrote:
> On Mon, Jan 14, 2013 at 02:21:00PM +0200, Marko Kreen wrote:
>> Note: reading from /dev/urandom does not affect /dev/random.
>
> Reading from /dev/urandom drains the pool that serves /dev/random:
>
> $ cat /proc/sys/kernel/random/entropy_avail
>
On Mon, Jan 14, 2013 at 02:21:00PM +0200, Marko Kreen wrote:
> Note: reading from /dev/urandom does not affect /dev/random.
Reading from /dev/urandom drains the pool that serves /dev/random:
$ cat /proc/sys/kernel/random/entropy_avail
3596
$ dd iflag=nonblock bs=100 count=1 if=/dev/random of=/de
On Mon, Jan 14, 2013 at 12:46 AM, Tom Lane wrote:
> Marko Kreen writes:
>> On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
>>> How about instead calling RAND_cleanup() after each backend fork?
>
>> Attached is a patch that adds RAND_cleanup() to fork_process().
>
> I remain unconvinced that
On Sun, Jan 13, 2013 at 05:46:12PM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
> >> How about instead calling RAND_cleanup() after each backend fork?
>
> > Attached is a patch that adds RAND_cleanup() to fork_process().
>
> I remain uncon
Marko Kreen writes:
> On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
>> How about instead calling RAND_cleanup() after each backend fork?
> Attached is a patch that adds RAND_cleanup() to fork_process().
I remain unconvinced that this is the best solution. Anybody else have
an opinion?
On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
> How about instead calling RAND_cleanup() after each backend fork?
Attached is a patch that adds RAND_cleanup() to fork_process().
That way all forked processes start with fresh state. This should
make sure the problem does not happen in any p
On Sun, Dec 23, 2012 at 9:45 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane wrote:
> >> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
> >> though, as that seems like it'll guarantee that each session starts out
> >> with only a mi
On Sun, Dec 23, 2012 at 02:49:08PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Dec 22, 2012 at 02:20:56PM -0500, Tom Lane wrote:
> >> #ifdef USE_SSL
> >> if (EnableSSL)
> >> {
> >>struct timeval tv;
> >>
> >>gettimeofday(&tv, NULL);
> >>RAND_add(&tv, sizeof(tv), 0);
> >> }
Andres Freund writes:
> On 2012-12-22 14:20:56 -0500, Tom Lane wrote:
>> I believe that we'd be better off doing something in postmaster.c to
>> positively ensure that each session has a distinct seed value.
> I am entirely unconvinced that adding in a gettimeofday() provides more
> entropy than
Noah Misch writes:
> On Sat, Dec 22, 2012 at 02:20:56PM -0500, Tom Lane wrote:
>> I believe that we'd be better off doing something in postmaster.c to
>> positively ensure that each session has a distinct seed value. Notice
>> that BackendRun() already takes measures to ensure that's the case for
Marko Kreen writes:
> On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane wrote:
>> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
>> though, as that seems like it'll guarantee that each session starts out
>> with only a minimal amount of entropy.
> No, that's actually the right f
On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane wrote:
> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
> though, as that seems like it'll guarantee that each session starts out
> with only a minimal amount of entropy.
No, that's actually the right fix - that forces OpenSSL to
On 2012-12-22 14:20:56 -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
> >> How about instead calling RAND_cleanup() after each backend fork?
>
> > Not "instead" - the gettimeofday() makes sense in any case. Considering
> > that it's immediate
On Sat, Dec 22, 2012 at 02:20:56PM -0500, Tom Lane wrote:
> I believe that we'd be better off doing something in postmaster.c to
> positively ensure that each session has a distinct seed value. Notice
> that BackendRun() already takes measures to ensure that's the case for
> the regular libc rando
Marko Kreen writes:
> On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
>> How about instead calling RAND_cleanup() after each backend fork?
> Not "instead" - the gettimeofday() makes sense in any case. Considering
> that it's immediate problem only for pgcrypto, this patch has higher chance
On Fri, Dec 21, 2012 at 10:05:30PM -0500, Tom Lane wrote:
> This new patch looks pretty reasonable from here,
> modulo the question of whether it adds "enough" entropy.
More brains reviewing that question will be good.
> I'm not entirely sold on whether it does. ISTM that any attack based on
> t
Noah Misch writes:
> On Sat, Dec 22, 2012 at 12:59:55AM +0200, Marko Kreen wrote:
>> On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
>>> This should have gone to secur...@postgresql.org, instead.
>>
>> It went and this could have been patched in 9.2.2 but they did not care.
> Ah.
A slightl
On Sat, Dec 22, 2012 at 12:59:55AM +0200, Marko Kreen wrote:
> On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
> > This should have gone to secur...@postgresql.org, instead.
>
> It went and this could have been patched in 9.2.2 but they did not care.
Ah.
> > On Fri, Dec 21, 2012 at 06:05:10
On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch wrote:
> This should have gone to secur...@postgresql.org, instead.
It went and this could have been patched in 9.2.2 but they did not care.
> On Fri, Dec 21, 2012 at 06:05:10PM +0200, Marko Kreen wrote:
>> When there is 'ssl=on' then postmaster calls
This should have gone to secur...@postgresql.org, instead.
On Fri, Dec 21, 2012 at 06:05:10PM +0200, Marko Kreen wrote:
> When there is 'ssl=on' then postmaster calls SSL_CTX_new(),
> which asks for random number, thus requiring initialization
> of randomness pool (RAND_poll). After that all fork
When there is 'ssl=on' then postmaster calls SSL_CTX_new(),
which asks for random number, thus requiring initialization
of randomness pool (RAND_poll). After that all forked backends
think pool is already initialized. Thus they proceed with same
fixed state they got from postmaster.
Output is no
23 matches
Mail list logo
