On 2006.08.31 at 00:09:56 +0200, Peter Eisentraut wrote:
Victor B. Wagner wrote:
First one is useful if for some reason some ciphers supported by
OpenSSL is not permitted to use in the particular network, or if
there is need to use ciphersuites which are not included into default
On 2006.08.31 at 08:52:08 +0100, Gregory Stark wrote:
Victor B. Wagner [EMAIL PROTECTED] writes:
One example which can be tested with stock OpenSSL without national
cryptography modules is - usage of NULL ciphers. They are not enabled by
default, but use of them provides
On 2006.08.31 at 10:34:02 +0200, Peter Eisentraut wrote:
Am Donnerstag, 31. August 2006 11:29 schrieb Stefan Kaltenbrunner:
this is btw. something that is available in most daemons utilizing
openssl - one can disable weak ciphers (which might not even be known as
weak at the time the
On 2006.08.31 at 14:36:28 -0400, Tom Lane wrote:
I concur with this in the abstract: it would be better design to submit
something to the OpenSSL project to allow setting engine choices and
such site-wide. In the short term, though, it's hard to deny that our
code
if
I need to build custom win32 binary package for PostgreSQL.
I've downloaded source for PGinstaller but found them hard to
understand - WiX toolkit and MSI is totally alien territory for me.
Things I need to modify:
1. Exclude all unneccessary extensions such as PostGIS
2. Add some other
On 2006.05.19 at 10:02:34 +0200, Martijn van Oosterhout wrote:
On Fri, May 19, 2006 at 10:33:52AM +0400, Victor B. Wagner wrote:
1. Am I correct that these function have to be INTERNAL? Or it is
possible to get access to MyProcPort variable (on Windows platform too)
from dynamically
Hi,
I've project where I need to log information about database user, based
on hardware security tokens. These tokens are supported by OpenSSL.
So, I need two modification in the PostgreSQL core
1. Access to SSL certificate information on SQL level.
It seems that this can be done using
