On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bad idea: once set, it'll never get unset, thus leaving installations
with a weakened security posture even after they've installed fixed
versions of openssl.
regards, tom lane
One might argue that
On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Renegotiation after X amount of data is the recommended method AFAIK,
because it limits the volume of data available to cryptanalysis.
What makes you think that elapsed time is relevant at all?
It appears that we didn't do enough research in regards to the recent
DST switch. We poorly assumed that having our machine's timezone files
up to date would be sufficient not knowing that our version of
postgres relied on its own timezone files.
The question is... can we symlink the
You can try the symlink game if you want, but it'll be on your own head
whether it works or not. (For the record, I am hoping to do exactly
that in future releases for Red Hat ... but in that context I know what
the system's timezone code is. I'm less sure that I know what Apple
is using.)
