New openssl builds including the Cyrix patch have been built for Fedora
18, 19, and 20 and fix my problem on F19. I'm still not clear on why
this patch wasn't included in the Fedora builds before, since it dates
from March, but I think if this patch actually has been included
upstream, then you
Hi,
This series of patches creates a new target for ppc64le and updates the
current assembly code for ppc64 in order to use the correct byte-order
when need.
Different approaches where tested to byte swap bytes, including the use
of instructions such as lwbrw, but the current version performed
SHA1 algorithm is defined using 32-bit variables in big-endian. This
patch updates sha1-ppc.pl to generate code that byte swaps the input
data when needed.
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
crypto/sha/asm/sha1-ppc.pl | 32
1 file
SHA2 algorithm is defined using 32-bit and 64-bit variables in
big-endian. This patch updates sha512-ppc.pl to generate code that byte
swaps the input data when needed.
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
crypto/sha/asm/sha512-ppc.pl | 196
This patch updates aes-ppc.pl to generate code that byte swaps the input
data when needed,
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
crypto/aes/asm/aes-ppc.pl | 43 +++
1 file changed, 43 insertions(+)
...
.align 4
Not to stand in the way of progress at all, but just to note we
cross-compile OpenSSL libraries for an embedded linux target that is still
using libc_r, not libpthread. That will not change anytime soon for us, at
least on legacy systems.
Besides that, it seems much of this discussion is about
On Oct 31, 2013 8:19 AM, Kevin Fowler kevpfow...@gmail.com wrote:
Not to stand in the way of progress at all, but just to note we
cross-compile OpenSSL libraries for an embedded linux target that is still
using libc_r, not libpthread. That will not change anytime soon for us, at
least on legacy
Hi,
This is probably the same bug as mentioned at
http://comments.gmane.org/gmane.comp.encryption.openssl.user/40609
Given the scripts
openssl version
openssl smime -decrypt -in no-headers.base64-wrapped-good.eml -out
decrypted.signed.mime -inkey x509.private-key.pem
echo finished with good
The synopsis had the wrong parameter types and an extra (unused)
function pointer declaration.
The demo dhparam filenames should all end in .pem.
---
doc/ssl/SSL_CTX_set_tmp_dh_callback.pod | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
Hello,
Please accept my patches for openssl 1.0.1e to enable building on Windows 7
Win32 and Win64 architectures. The problems are that running mk1mf.pl on
Windows gets confused by the carriage return for each EOL, and that there is a
missing directory separator on the uplink-x86_64.pl that
Hello,
If OpenSSL is compiled without SSLv2 support, the line
openssl ciphers -ssl2 HIGH
incorrectly prints all ciphers for any protocol classified as HIGH.
Without 'HIGH', this is the output ('openssl ciphers -ssl2'):
Error in cipher list
3076146824:error:1410D0B9:SSL
Hi Andy,
Thanks for your changes, they are working fine. I'm setting up a
little-endian and a big-endian system that I'll use to test and compare
performance results. As soon as I finish I'll post them here.
The only thing that I had to change was a typo in SHA-512:
diff --git
The only thing that I had to change was a typo in SHA-512:
diff --git a/crypto/sha/asm/sha512-ppc.pl b/crypto/sha/asm/sha512-ppc.pl
index 0648655..d6a86c7 100755
--- a/crypto/sha/asm/sha512-ppc.pl
+++ b/crypto/sha/asm/sha512-ppc.pl
@@ -383,7 +383,7 @@ $code.=___ if ($SZ==8 $LITTLE_ENDIAN);
From: owner-openssl-dev On Behalf Of Jeroen Pluimers via RT
Sent: Thursday, October 31, 2013 14:32
This is probably the same bug as mentioned at
http://comments.gmane.org/gmane.comp.encryption.openssl.user/40609
It's not exactly the same problem. Your lines are not 76.
snip: one smime
14 matches
Mail list logo
