On Thu, Mar 25, 2010 at 5:16 PM, Claus Assmann ca+ssl-...@esmtp.org wrote:
So far I haven't been able to determine which change caused the
problem, so I'm still looking at various diff's, but I'm not
familiar with the source code to (easily) spot the problem.
I imagine the reason that the
Bodo Moeller wrote:
it's code elsewhere that no longer tolerates the coarse logic we are
changing in the patch, which has been around forever.
In fact, I already suspected that, thanks for the confirmation.
__
OpenSSL Project
On 03/26/10 04:44 AM, David Schwartz wrote:
Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
That is correct.
This poses a challenge when using OpenSSL in a
Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no safe way to set
The attached patches (generated against OpenSSL 0.9.8n and OpenSSL-1.0.0-
beta5) cause openssl ocsp to implicitly trust the Issuing CA Certificate (as
denoted by the -issuer parameter) as a candidate OCSP Response signer. This
non-delegated model is allowed by RFC 2560.
With this patch, it's
On 03/25/10 02:13 PM, Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no
On Thu, 2010-03-25 at 17:57 +0100, PMHager wrote:
As all major compilers for Intel CPUs support intrinsics and, if used
correctly, optimize to the same instructions as direct assembler, IMHO
these policies should be reconsidered to keep OpenSSL competitive.
For good reasons perlasm is
My question was about the inconsistency between, for example,
SSE-optimised and AESNI-optimised functions. Both are implemented as
perlasm; that's not relevant. What _is_ relevant, however, is that the
SSE optimisations end up in the 'core' AES_encrypt() function which is
tested by 'openssl
PM,
Though I am not a member of the OpenSSL team, I totally agree with you.
As for the AES, the Westmere CPUs have also a new instruction for the
GHASH (pclmulqdq / _mm_clmulepi64_si128).
It's not an instruction *for* GHASH, it's an instruction that among
other thing can be used for GHASH.
Mark Phalan wrote:
Unfortunately that's not really practical. To take an example I'm
familiar with - libgss. libgss can end up calling into OpenSSL in the
following way:
libgss - kerberos - pkinit plugin - openssl
It's simply not practical to change libkrb5 and libgss and all
10 matches
Mail list logo