From: [EMAIL PROTECTED]
neff I know that the current version of OpenSSL doesn't support shared
neff libraries for NetBSD. However, I really need the shared libraries (for
neff perl modules). Has anyone found a way to get the shared libraries to
neff compile on NetBSD?
[note: I'm redirecting
Hy all,
Is anyone have an example of the method to create a PKCS#7 EnveloppedData
when the different component of the PKCS#7 EnveloppedData comes from an
particular application :
- recipient certificate.
- Encrypt Data.
- Wrapped Session Key.
[This thread belongs to openssl-users]
On Mon, Oct 09, 2000 at 10:21:56PM -0600, Peter Dennis Bartok wrote:
Hi all,
I've got a (hopefully) simple question:
In a server that supports TLS (e.g. a imap server), when the server receives
the STARTTLS command, should the method that the
Is anyone have an example of the method to create a PKCS#7
EnveloppedData
when the different component of the PKCS#7 EnveloppedData comes from an
particular application :
- recipient certificate.
- Encrypt Data.
- Wrapped Session Key.
I just know how to create a
-Original Message-
From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
Sent: Sunday, October 08, 2000 11:01 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: ranlib all over the place...
From: Ben Laurie [EMAIL PROTECTED]
ben Lots of stuff internal to
We figured out how to get randtest working on OS/390. We determined that the
RAND_xxx functions were not running the functions they call in turn through the
rand_meth structure pointer. This is because in the scope of randtest.c, the
rand_meth pointer is not initialized.
In
From: Bernard Dautrevaux [EMAIL PROTECTED]
Dautrevaux Thus suppressing these ranlib may not be a good
Dautrevaux thing... One alternative is when configuring to define two
Dautrevaux ranlib tools: one to run each time, one to run at the
Dautrevaux end. Depending on the system the former or both
From: [EMAIL PROTECTED]
n2xjk We figured out how to get randtest working on OS/390. We
n2xjk determined that the RAND_xxx functions were not running the
n2xjk functions they call in turn through the rand_meth structure
n2xjk pointer. This is because in the scope of randtest.c, the
n2xjk
Hi all,
It seems like I found the problem - I was using
st_meth_ptr = SSLv2_client_method();
instead of
st_meth_ptr = SSLv23_client_method();
Making the change speeded up things, and throughput is just as good as
RSA's and Wininet.
Thanks to Dan Kegel,
Noam
Noam Ben-Yochanan wrote:
I'm
Your test program works (I assume you meant "word" in the printf instead of
"foo"), but then it is simpler example. randtest.c and rand_lib.c are
different files, so the binder has to resolve the static references across file
scopes. I can't say if we are seeing a bug in OS/390 or a more
From: [EMAIL PROTECTED]
n2xjk Your test program works (I assume you meant "word" in the
n2xjk printf instead of but then it is simpler example.
But with exactly the same semantics...
n2xjk randtest.c and rand_lib.c are different files, so the binder
n2xjk has to resolve the static references
On Tue, 10 Oct 2000, Richard Levitte - VMS Whacker wrote:
neff I know that the current version of OpenSSL doesn't support shared
neff libraries for NetBSD. However, I really need the shared libraries (for
neff perl modules). Has anyone found a way to get the shared libraries to
neff
From: [EMAIL PROTECTED]
neff These patches produce a makefile that dies before the shared
neff libraries get built on my system. Rather than debugging their
neff patches, though, I would much rather help get NetBSD shared
neff library support into OpenSSL.
I agree, but I'll probably still look
13 matches
Mail list logo
