Hi
In OpenSSL 3.x, what RSA padding scheme does EVP_SealInit() use? PKCS1
or OAEP ?
In 1.1, I wrote my own version of this code that forced the padding to
be OAEP and am wondering if I still need that in 3.x.
Norm Green
I'm also interested in the answer to these questions regarding SRP in
OpenSSL v3.
Our project still uses OpenSSL v1.1.1 with plans to move to v3 next year.
However we use SRP extensively and will not be able to move to v3 if SRP
support is soon to be no longer available.
Norm Green
GemTalk
EVP_PKEY_can_verify() with some assurance such a
PR would be accepted.
Norm Green
On 8/18/2020 6:01 PM, Norm Green wrote:
In 3.0 I see this new function in evp.h :
int EVP_PKEY_can_sign(const EVP_PKEY *pkey);
Is there an equivalent way to check if a key can verify? I'm not
seeing an obvious way to do
In 3.0 I see this new function in evp.h :
int EVP_PKEY_can_sign(const EVP_PKEY *pkey);
Is there an equivalent way to check if a key can verify? I'm not seeing
an obvious way to do that. Previously I used
EVP_PKEY_meth_get_verifyctx() but that call is now deprecated in 3.0.
thanks,
Norm
Kaduk wrote:
On Wed, May 06, 2020 at 05:22:17PM -0700, Norm Green wrote:
All tests on AIX fail like this. Is this a known issue? What debugging
information is needed? Should I open an issue on github?
Also note I had to set LD_LIBRARY_PATH to the SSL build directory to get the
tests to run at all
All tests on AIX fail like this. Is this a known issue? What debugging
information is needed? Should I open an issue on github?
Also note I had to set LD_LIBRARY_PATH to the SSL build directory to get
the tests to run at all.
normg@sky>gmake test
make depend && make _tests
ssl.h. Is this intentional or a bug?
It's easy enough for me to fix this in my source code, but other
packages that rely upon openssl break with "ssl.h is unusable" errors
due of this change (OpenLDAP is one such example).
Norm Green
>I use the git release tags, not the tarballs.
I do too, and I suspect many others do as well.
The empty krb5 directory has not caused grief for me, but it would be
nice if the git release tag directory structure matched the tarball.
Norm Green
On 4/21/2020 10:19 AM, Quanah Gibson-Mo
Could be, but that's not how EVP_CipherUpdate is documented to work. If
this is an XTS mode limitation and not a bug, shouldn't the limitation
be documented on a man page somewhere? And shouldn't my second call to
EVP_CipherUpdate fail?
Norm Green
On 9/30/2019 8:04 PM, Thulasi Goriparthi
;
EVP_CipherUpdate(ctx, [512], , [512], 512);
// second chunk
EVP_CipherFinal(); (produces no additional data)
I have a short C program that demonstrates the problem that I can post
if necessary.
Can anyone explain what's going on?
Norm Green
CTO, GemTalk Systems Inc.
with pthread_exit() or
return to a known state such that no SSL calls are in progress in any
thread before the process can safely exit().
On 3/1/2019 11:54 AM, Viktor Dukhovni wrote:
On Fri, Mar 01, 2019 at 11:16:52AM -0800, Norm Green wrote:
[ Please avoid non-breaking spaces in your posts
I'm debugging a failure in a debug build on Solaris SPARC in the below
code in rand_lib.c. On line 744, rand_meth_lock is NULL, which suggests
the RUN_ONCE code is not working. Wondering if anyone else has seen
this problem?
We did not see this issue in 1.1.1a. Perhaps changes in the
I'm seeing the following link failure on Solaris, both SPARC and x86_64
with 1.1.1a. 1.1.1 does not have this problem. Adding -lcrypto to the
link line makes the problem go away.
Any suggestions on how to proceed?
Norm Green
rm -f test/rsa_complex
${LDCMD:-/opt/studio12.5/bin/cc} -m64
How does one specify the CRL to the SSL_CTX when setting up a
connection? I would expect there to be something similar to
SSL_CTX_use_certificate(), such as:
int SSL_CTX_use_crl(SSL_CTX *ctx, X509_CRL *crl)
but can nothing like that.
Norm Green
--
openssl-users mailing list
To unsubscribe
SSL version-specific? SSL 1.1.0 builds clean on the same machine
I'm wondering if the solution is code changes or
On 3/1/18 04:27, Andy Polyakov wrote:
I mean it might happen that it's not version-specific...
--
openssl-users mailing list
To unsubscribe:
It looks like 32 bit builds set the -WX flag (treat warnings as errors)
while the 64 bit builds don't.
cl -W3 -wd4090 -Gs0 -GF -Gy -nologo /MDd /Od -WX /Zi
/Fdossl_static /I "." /I "crypto\include" /I "include" /I
"crypto\ec\curve448\arch_32" /I "crypto\ec\curve448" -DDSO_WIN32
:39:47 -0800, Norm Green <norm.gr...@gemtalksystems.com> said:
norm.green> With CC=cc, I get this:
norm.green>
norm.green> cc -I. -Icrypto/include -Iinclude -g -O0 -arch x86_64 -Wall
norm.green> -Qunused-arguments -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H
norm.green> -DOPENSSL_NO_
With CC=cc, I get this:
cc -I. -Icrypto/include -Iinclude -g -O0 -arch x86_64 -Wall
-Qunused-arguments -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m
Adding "-cru" to arflags for AIX in Configuratinos/10-main.conf solves
the problem.
On 2/23/2018 2:36 PM, Dennis Clarke wrote:
On 23/02/18 05:31 PM, Norm Green wrote:
Looks like no target .a file is passed to ar ?
Note: OpenSSL 1.1.0 succeeds on this platform.
/export/localne
Looks like no target .a file is passed to ar ?
Note: OpenSSL 1.1.0 succeeds on this platform.
/export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl -i -pe 's/^.*\|//; s/
\/(\\.|[^ ])*//; $_ = undef if (/: *$/ || /^(#.*| *)$/); $_.="\n" unless
!defined($_) or /\R$/g;' apps/s_socket.d.tmp
ar -X
On 2/21/2018 12:46 PM, Andy Polyakov wrote:
And "the default for all v9 architectures is -xmemalign=8s".
I'm getting confused. Since I did not specify -xmemalign at all, why
did the test fail with SIGBUS in the first place? Seems like there
should have been no alignment problem if the
On 2/21/2018 9:42 AM, Dennis Clarke wrote:
Which is correct way to do this on sparc systems.
Why do you say that? We've been building OpenSSL on SPARC for the past
7 years without that flag and it's worked just fine with only a few
minor changes to the compile/link flags.
Norm
--
On 2/21/2018 8:42 AM, Dennis Clarke wrote:
Pretty sure I have done builds and tests. In fact I am certain of it.
If you added -xmemalign=8s to the SPARC compiler flags (as shown in one
of your emails from yesterday) then you would not see the problem.
-xmemalign=8s forces the compiler to
Hi Dennis,
You're right, I did modify the config file, sorry. I did it so long ago
I had forgotten. I will email it to you shortly.
Norm
On 2/20/2018 10:14 AM, Dennis Clarke wrote:
On 20/02/18 01:11 PM, Norm Green wrote:
Just download and build v1.1.1 pre alpha 1 on Solaris. It's
Just download and build v1.1.1 pre alpha 1 on Solaris. It's on
ftp.openssl.org. That's all I did. Configure using
solaris64-sparcv9-cc . I'm using Solaris studio 12.3.
Norm
On 2/20/2018 10:01 AM, Dennis Clarke wrote:
On 20/02/18 12:47 PM, Norm Green wrote:
On 2/20/2018 5:43 AM, Michael
On 2/20/2018 5:43 AM, Michael Wojcik wrote:
Not by default. The comments in /usr/include/sys/feature_tests.h (on a Solaris
system) explain this in excruciating detail, but in short you need either
-DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the equivalent in the code)
to compile with
ns_elem_size);
ret = ASN1_item_print(bio_err, o, 0, i, NULL);
On 2/19/2018 9:00 PM, Viktor Dukhovni wrote:
On Mon, Feb 19, 2018 at 01:45:26PM -0800, Norm Green wrote:
# ASN1_LONG_DATA:
# success: TRUE
t@1 (l@1) signal BUS (invalid address alignment) in asn1_item_print_ctx at
line 155 in file
s compiler which apparently
does not define these macros.
Nornm
On 2/19/2018 1:20 PM, Norm Green wrote:
The output is not too long.
/export/localnew/sparc.Solaris/bin/gmake depend &&
/export/localnew/sparc.Solaris/bin/gmake _tests
gmake[1]: Entering directory
'/hamburg4/users
205 in "driver.c"
[9] main(argc = 1, argv = 0x7fffec08), line 51 in "main.c"
(dbx)
On 2/19/2018 1:30 PM, Viktor Dukhovni wrote:
On Feb 19, 2018, at 4:20 PM, Norm Green <norm.gr...@gemtalksystems.com> wrote:
/export/localnew/sparc.Solaris/bin/gmake depend &a
Error 2
slow test failed
On 2/19/2018 12:50 PM, Benjamin Kaduk wrote:
On 02/19/2018 02:06 PM, Norm Green wrote:
Not sure if this is expected on this platform?
Test Summary Report
---
../test/recipes/04-test_asn1_encode.t (Wstat: 256 Tests: 1
Failed: 1)
Failed test: 1
Not sure if this is expected on this platform?
Test Summary Report
---
../test/recipes/04-test_asn1_encode.t (Wstat: 256 Tests: 1
Failed: 1)
Failed test: 1
Non-zero exit status: 1
../test/recipes/90-test_secmem.t (Wstat: 256 Tests: 1
Failed: 1)
In 1.1.1 pre-relase 1, we have this new function:
int OSSL_STORE_ctrl(OSSL_STORE_CTX *ctx, int cmd, ... /* args */);
Would it be possible to add a version that takes va_args like this?
int OSSL_STORE_vctrl(OSSL_STORE_CTX *ctx, int cmd, va_list args);
OpenSSL already have this precedent in
Turns out it only fails in my build environment and it builds clean as a
stand-alone SSL build. So it's something on my end.
Sorry for the noise.
Norm
On 2/13/2018 2:59 PM, Matt Caswell wrote:
On 13/02/18 21:06, Norm Green wrote:
This is on Ubuntu 16.04with a build configured to be debug
This is on Ubuntu 16.04with a build configured to be debug-linux-x86_64
normg@moop>gmake
make depend && make _all
make[1]: Entering directory
'/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1'
make[1]: Leaving directory
'/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1'
make[1]:
On 1/9/18 19:32, Viktor Dukhovni wrote:
This Key Usage is more appropriate. When the "Key Usage" is present in
a CA certificate, it*MUST* include "Certificate Sign".
That was indeed the problem. Thank you!! It seems strange to me that
OpenSSL will allow creation of a CA cert (CA:TRUE) that
2018 4:55 PM, Viktor Dukhovni wrote:
On Jan 9, 2018, at 7:28 PM, Norm Green <norm.gr...@gemtalksystems.com> wrote:
It still doesn't verify correctly.
Or correctly fails to verify?
To simplify, I tried it with 1 intermediate CA. Here's the chain:
rootCa.pem - self-signed roo
On 1/9/2018 3:57 PM, Viktor Dukhovni wrote:
On Jan 9, 2018, at 6:43 PM, Norm Green <norm.gr...@gemtalksystems.com> wrote:
What is the correct order of intermediate CA certs in the untrusted chain file?
The untrusted CA list is a heap, the order is irrelevant.
--
openssl-users m
Well that is not *at all* obvious from the documentation, but ok.
What is the correct order of intermediate CA certs in the untrusted
chain file?
On 1/9/2018 3:36 PM, Viktor Dukhovni wrote:
The correct way to verify a chain is to put the root CA in a CAfile,
intermediate CAs in an
On 1/9/2018 6:03 AM, Benjamin Kaduk wrote:
Did you try something like (with a 1.1.0 installation):
openssl verify -CAfile RootCA.pem -untrusted chain.pem chain.pem
with the leaf certificate as the first one in chain.pem?
Same result. The only way it seems to work is if the leaf cert appears
of things correct? Seems like there should be a way
for the openssl command to verify a chain file which will be used with the
SSL_CTX_use_certificate_chain_file() function.
Norm Green
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
This is with openssl 1.10d. When I run:
./openssl ciphers -v
The OCB ciphers are not in the list. Is this an omission or
intentional? Other AEAD ciphers are there (GCM).
Thanks,
Norm Green
normg@bunk>./openssl ciphers -v |grep AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH
yYdrQv
XmxFEr1AwKnmeD8dAg4F62ddmzX76fNaw1QqLbmEQTLdrEYM3KxUdA==
-END PUBLIC KEY-----
Norm Green
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
That was it. Thanks Matt!
On 12/13/16 15:48, Matt Caswell wrote:
On 13/12/16 21:09, Norm Green wrote:
I have a simple C program that works in 1.0.2 but fails with the same
code in 1.1.
Here's the psuedo code for the client and server:
Server:
const SSL_METHOD *meth = TLSv1_2_server_method
ails: error:141640B5:SSL routines:tls_construct_client_hello:no
ciphers available
ssl/statem/statem_clnt.c at 815
What do I need to do to make AECDH work in 1.1 ?
Norm Green
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
in the build log where the assembler is
being invoked directly.
My compiler is:
cc: Sun C 5.10 SunOS_i386 Patch 142363-05 2010/04/28
usage: cc [ options] files. Use 'cc -flags' for details
thanks,
Norm Green
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo
+1
I agree with Daniel's sentiment and respectfully suggest EPV_Seal* and
EVP_Open be updated and kept up to date.
We all know how easy it is to get crypto wrong. Having "one stop shop"
functions like these are invaluable for when it comes to getting crypto
right.
Norm Green
O
Sorry, I'm still not quite getting it.
It sounds like you're saying that only RSA supports encrypting with a
public key. But can't any asymmetric encryption algorithm encrypt using
the public key? Why is RSA special in this regard?
Norm Green
On 8/15/2016 5:31 PM, Dr. Stephen Henson wrote
Ok, thanks.
What I don't understand is what key transport has to do with
EV_SealInit() ? Why is key transport important here ?
Norm Green
On 8/15/2016 2:38 PM, Dr. Stephen Henson wrote:
On Mon, Aug 15, 2016, Norm Green wrote:
The man page for EVP_SealInit says:
"The public key
The man page for EVP_SealInit says:
"The public key must be RSA because it is the only OpenSSL public key
algorithm that supports key transport."
1 ) Is this still true?
2) Will this restriction change now that RSA key transport is being
dropped from TLS 1.3 (or so I've read..
implemented without aes instructions in that case?
Norm Green
On 8/10/16 06:28, Jan Just Keijser wrote:
Hi,
On 10/08/16 14:25, Nagesh shamnur wrote:
Hi Group,
I am running an application which transfers huge chunks of data every
second (850Mbps) and the same is secured using openssl
Yes, it's only required on the server.
Norm Green
On 5/25/16 14:10, Jeremy Farrell wrote:
Interesting; is this a server-side requirement? I ask because with
1.0.2g my client using "AECDH+AES:ADH+AES" makes a TLS 1.2 connection
with AECDH-AES256-SHA without calling this function
Yes! That was the problem. In order to use cipher "AECDH",
SSL_CTX_set_ecdh_auto(ctx, 1) must be called first.
Thanks Michael!!
Norm
On 5/24/16 15:52, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Norm Green
Sent: Tuesday, Ma
shared
cipher:s3_srvr.c:1417:
The following works but is not what I want:
SSL_CTX_set_cipher_list("ADH")
Any suggestions on how to proceed?
Norm Green
On 5/24/16 10:45, Salz, Rich wrote:
>./openssl ciphers -v 'ALL:aNULL' |grep ECDH |grep "Au=None"
AECDH-AES256-SHAS
I previously tried "kEECDH:kEDH" and that didn't work.
2) These ciphers all report as SSLv3. Do I have to use SSLv3
client/server methods to get access to these ciphers? I was using TLS
1.2 (TLSv1_2_server_method()) methods.
Norm Green
On 5/24/16 10:08, Salz, Rich wrote:
1)
encryption keys used every time with ADH?
3) Is it possible to use ephemeral DH without using certificates? I was
not able to get that to work.
4) What is the best practice for establishing an anonymous encrypted
channel using OpenSSL?
Norm Green
--
openssl-users mailing list
To unsubscribe: https
going to try modifying the make file to use shorter directory names
to try to get the link line back under the max length threshold.
Any other suggestions?
Norm Green
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
included in the in
error? What will 1.0.2f look like in this regard?
I need to merge 1.0.2e into a vendor branch in svn and I can foresee
these symlink changes causing me a lot of grief.
Norm Green
On 12/3/2015 9:05 AM, Viktor Dukhovni wrote:
On Thu, Dec 03, 2015 at 04:59:56PM +, Viktor Dukho
ztvf openssl-1.0.2d.tar.gz |grep cast.h
-rw-rw-r-- openssl/openssl 4659 2015-07-09 04:53
openssl-1.0.2d/crypto/cast/cast.h
lrwxrwxrwx openssl/openssl 0 2015-07-09 05:03
openssl-1.0.2d/include/openssl/cast.h -> ../../crypto/cast/cast.h
How can I resolve th
.c
./test/rsa_test.c
./test/evp_test.c
./test/ecdhtest.c
./test/mdc2test.c
./test/rc5test.c
./test/rc2test.c
./test/ectest.c
./test/exptest.c
./test/constant_time_test.c
Will there be a 3rd 1.0.2e tarball released to fix this?
Norm Green
On 12/3/15 09:41, Viktor Dukhovni wrote:
On Thu, Dec
Are these sym links going to remain this way in subsequent releases? Or
will they revert back to the way they were in 1.0.2d? Merging changes
like this into svn is a pain because it causes conflicts.
Norm Green
On 12/3/15 13:31, Matt Caswell wrote:
On 03/12/15 21:27, Norm Green wrote
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:s3_pkt.c:1275:SSL alert number 40
Thanks,
Norm Green
__
OpenSSL Project http://www.openssl.org
User Support Mailing List
=0x1082180) at s3_srvr.c:680
#9 0x7f666a560042 in SSL_accept (s=0x1082180) at ssl_lib.c:940
#10 0x7f669731b0fb in GsSslState::SSL_accept (this=0x7f669800fd20
SslState,
ssl=0x1082180) at /export/ghana1/users/bretlb/trunk/src/sslsocket.c:528
Thanks in advance for any help given,
Norm Green
ssl3_ctx_callback_ctrl}
(gdb)
On 9/8/14 14:21, Viktor Dukhovni wrote:
On Mon, Sep 08, 2014 at 11:45:59AM -0700, Norm Green wrote:
Were are occasionally seeing hangs when establishing an SSL connection with
OpenSSL 1.0.1i. This connection uses SRP and both the server and the client
sockets are in blocking
, Viktor Dukhovni wrote:
On Mon, Sep 08, 2014 at 03:10:47PM -0700, Norm Green wrote:
I will try to capture traffic in the next run.
Looking at the commit history after 1.0.1i, I think
you want:
commit 30fbe92c78981a417718bcbf25d295d16c5b7ed9
Author: Dr. Stephen Henson st...@openssl.org
Date
))
return 2;
cpk = ssl_get_server_send_pkey(s);
if (!cpk)
Norm
On 9/8/2014 7:10 PM, Viktor Dukhovni wrote:
On Mon, Sep 08, 2014 at 05:41:13PM -0700, Norm Green wrote:
Thanks Viktor. I did get some fixes (via this list) from
, Aug 07, 2014, Norm Green wrote:
Any idea where to begin debugging this? Any and all help is appreciated.
The cause is incorrect handling of new SRP authentication type which was added
to correct a bug where SRP authentication was incorrectly classified as NULL
authhentication.
A temporary
Then what would you suggest? SRP is completely broken for us with 1.0.1i
Norm
On 8/8/14, 11:51, Matt Caswell wrote:
On 08/08/14 19:33, Norm Green wrote:
Hello Steve,
Reverting the below commit is necessary but not sufficient. There are
also references to aSRP in s3_clnt.c and ssl_lib.c
Hi Steve,
That patch works! We will go with that one instead of rolling back the
commit mentioned in your previous message.
Thanks very much for your help!!!
Norm
On 8/8/14, 12:25, Dr. Stephen Henson wrote:
On Fri, Aug 08, 2014, Norm Green wrote:
Then what would you suggest? SRP
complaint after
line 31 on the server side is clearly bogus.
Any idea where to begin debugging this? Any and all help is appreciated.
Norm Green
Server Side:
[ 1] SSL call: SSL_load_error_strings with args: NONE (nothing returned)
[ 2] SSL call: ERR_load_crypto_strings with args: NONE
Thanks for tracking it down so fast Steve. I will revert the mods in
that commit and try it again tomorrow.
Norm
On 8/7/2014 7:21 PM, Dr. Stephen Henson wrote:
On Thu, Aug 07, 2014, Norm Green wrote:
Any idea where to begin debugging this? Any and all help is appreciated.
The cause
, which seems like a poor assumption.
I'm still fairly new to SSL and SRP and am grateful for any and all help.
Norm Green
VMware, Inc.
Here is the error I get on the client:
SSL_connect() failed, rc=0. resultCode=1 (SSL_ERROR_SSL)
0xfd7fffdf83a0 0xfd7fffdf839c 0xfd7fffdf8390
, which seems like a poor
assumption. Is there some better way to determine that SRP authenication has
failed?
I'm still fairly new to SSL and SRP and am grateful for any and all help.
Norm Green
VMware, Inc.
Here is the error I get on the client:
SSL_connect() failed, rc=0. resultCode=1
To: openssl-users@openssl.org
Sent: Wednesday, October 26, 2011 11:46:32 PM
Subject: Re: OpenSSL 1.0.1 example with SRP
On Wed, Oct 26, 2011 at 10:28 PM, Norm Green no...@vmware.com
wrote:
Is there no one that can help me get a simple SRP test case
working? Or should I conclude SRP is broken
:35 AM
Subject: Re: OpenSSL 1.0.1 example with SRP
On Thu, Oct 27, 2011, Norm Green wrote:
The best I can tell, the snapshot is broken.
At this point, I wouldn't be surprised.
Update:
I made some (major) changes to my example code based on the SRP
code in ssltest.c. Mainly, I
identity hint: None
SRP username: None
Start Time: 1319681979
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
- Original Message -
From: Norm Green no...@vmware.com
To: openssl-users@openssl.org
Sent: Tuesday, October 25, 2011 6:58:12 AM
Subject: Re: OpenSSL 1.0.1
(sec)
Verify return code: 0 (ok)
---
- Original Message -
From: Peter Sylvester peter.sylves...@gmail.com
To: openssl-users@openssl.org
Sent: Tuesday, October 25, 2011 3:18:39 AM
Subject: Re: OpenSSL 1.0.1 example with SRP
On 10/25/2011 05:15 AM, Norm Green wrote:
Hello Experts
Can anyone point me the right direction so I can get a simple SRP example to
work?
Thanks for any help,
Norm Green
VMware, Inc.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List
Hi Jeff,
Was OPENSSL_NO_SRP defined when you built?
I'm 99.9% sure it wasn't, otherwise the compiler would have barfed on my call
to SSL_CTX_SRP_CTX_init()
Thomas Wu's patches can be found in RT. The latest appears to be
http://rt.openssl.org/Ticket/Display.html?id=2523user=guestpass=guest.
78 matches
Mail list logo
