Hi All,
I've looked for any fix for the below mentioned API's in the OpenSSL site. But
my bad, could not find any.
Let me know if anyone have faced similar issue with the EVP_EncodeUpdate() and
EVP_EncodeFinal() API's or any pointer where I can find the fixes in OpenSSL
releases from OpenSSL v
On Tue, Apr 20, 2010 at 2:33 PM, Andy Polyakov wrote:
>>
>> I actually ended up solving it by removing all uses of BIO_new_fp() in
>> favor of my own custom BIO that I just finished writing earlier this
>> week.
>
> Why not BIO_new_file? A.
Yeah, I discovered while analyzing the code that using
Hello,
The openssl command line tool treats the non-null terminated buffer
"mbuf" as a C string when using the pop3 s_client feature. This causes
a segmentation fault with malloc.conf option "J" set when BIO_printf()
runs off the end of the buffer. The following patch from OpenBSD fixes
the issue.
If there are any minor issues which someone VMS illiterate (i.e. me) can
understand I'll fix them.
By the way, speaking of non-VMS stuff, in case anyone cares, ...
Even if somebody does, doesn't reporting it with VMS in subject decrease
the chance of being taken care of? Yes, you've added
Just two days ago I was banging my head against this very problem. I
have a C# app that calls into a C++ DLL that utilizes OpenSSL. Adding
applink.c to the DLL project didn't get rid of the error like I hoped it
would, and after analyzing the OpenSSL code I discovered to my dismay
that it alw
If I have correctly understood the FAQ about the OPENSSL_applink. It
applies only in the Win32 version:
* If OPENSSL_USE_APPLINK is not defined at the compilation stage of
OpenSSL, the snippet applink.c is not mandatory BUT I have to
build a debug and a release version of OpenSSL
Hi,
During our project migrating to the version 1.0.0 I have discovered an
obvious coding bug:
--- openssl-1.0.0/crypto/dsa/dsa_ameth.c Fri Jan 22 22:17:29 2010
+++ merge/crypto/dsa/dsa_ameth.c Tue Apr 20 10:21:50 2010
@@ -209,7 +209,7 @@
if (*p == (V_ASN1_SEQUENCE|V_ASN1_CONSTRUCTED))
{
ASN1_TYP
RFC 4492 says:
A client that receives a ServerHello message containing a Supported
Point Formats Extension MUST respect the server's choice of point
formats during the handshake (cf. Sections 5.6 and 5.7). If no
Supported Point Formats Extension is received with the ServerHello,
t
