Steve Henson correctly pointed out that to change ASN1_TYPE_cmp() may not be
appropriate, as there could be cases when null pointer (absent list) means
something different from list being NULL.
To address that concern, I've made sure the workaround applies only to the case
when two algorithms a
> If you're going to change this, then perhaps at the same time as changing the
> API these could be inverted so we have defines that say what /is/ enabled
> since that's probably a better design overall.
The key word being "probably" There is something to be said for the idea that
new featur
On 20 January 2015 at 21:44, Salz, Rich wrote:
> > you think is still necessary to leave in the code #ifndef OPENSSL_NO_SHA
> > and #ifdef OPENSSL_NO_SHA are so many function calls EVP_sha1() (and
> > other similar) that compiling with -DOPENSSL_NO_SHA gives an endless
> > series of errors and wa
> you think is still necessary to leave in the code #ifndef OPENSSL_NO_SHA
> and #ifdef OPENSSL_NO_SHA are so many function calls EVP_sha1() (and
> other similar) that compiling with -DOPENSSL_NO_SHA gives an endless
> series of errors and warnings.
Right, it's not useful. We're looking at cleani
Our code-scanning tool has found another bug in OpenSSl 1.0.1k. In
TS_check_status_info (in crypto/ts/ts_rsp_verify.c), if an error occurs we
create a string which is intended to be a comma-separated list of error
strings. However when adding the comma between error strings, strcpy is used
rath
A scanning tool we use to scan our code for runtime problems such as buffer
overruns, possible NULL pointer dereferencing, memory leaks, etc. has found a
bug in the str_copy routine in conf_def.c. At line 621 (in 1.0.1k), there is a
call to BUF_MEM_grow_clean but the return value is not checked.
We have no plans to completely drop SSLv3. It is possible to compile it out
already. And the next version after 1.0.2 will make it easier to specify the
protocol versions you want to support, at runtime.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
Spam detection software, running on the system "butler.openssl.org", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
spam-ab...@openssl.net for d
Currently the OCSP_basic_verify() function fails with many apparently valid OCSP
responses (e.g. all those sent by Cloudflare servers). Other libraries (GnuTLS,
NSS) have no problem with them.
Essentially, in crypto/ocsp/ocsp_vfy.c in the OCSP_basic_verify() function, the
X509_STORE_CTX_init() fun
This patch gives about 50% speed improvement for existing GLV elliptic
curves in OpenSSL. Read about it here:
http://eprint.iacr.org/2015/036
It could use a review. Perhaps the best known use case for secp256k1
right now is Bitcoin.
BBB
Before:
op op/s
160 bi
Greetings,
I wonder have you refused the patch or it will be applied?
Thanks,
Alex Komnin.
2014-12-10 23:35 GMT+03:00 The default queue via RT :
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "[PATCH] NDEBUG
11 matches
Mail list logo