> OpenSSL 1.1.0 Pre 1
> Platform: Sparc Solaris 10
> Compiler: GCC 4.9.3
>
> Warnings:
>
> e_des.c: In function 'des_init_key':
> e_des.c:239:29: warning: assignment from incompatible pointer type
> dat->stream.cbc = enc ? des_t4_cbc_encrypt :
> des_t4_cbc_decrypt;
>
> You can also add some more macros to the perlasm which already translates a
> LOT of opcodes into something older assemblers won't choke on.
If it was a matter of few instructions, then absolutely. But if it's a
question about *all* vector instructions, then it becomes
counter-productive. As
Hi,
> Per Jeremy Farrell's suggestion, specifying the "-no-asm" option worked and I
> was able to get through the build.
>
> Regarding the "stvx" instruction, here is a bit clearer set of info to map to
> why that instruction seemed to be the issue:
Original report listed even last lines in
> It looks like in the #ifndef SIGALRM case, c[D_GHASH][0] is set, but not
> c[D_GHASH][i] for larger i.
Fixed in master.
> (Where is the no-SIGALRM code used?)
Nowhere 99.997% cares about. Originally it was used extensively on
Windows (i.e. among those majority cared about), but then even
Hi,
> I've started playing with the ChaCha20 assembly that was recently checked
> in and found a few problems. Most of these do not affect OpenSSL as you
> only ever call ChaCha20_ctr32 on a whole number of blocks. But this isn't
> documented as a constraint in internal/chacha.h and the assembly
On Fri Feb 12 18:41:41 2016, rainer.j...@kippdata.de wrote:
> Using OpenSSL 1.1.0pre2 I see renegotiation problems between s_client
> and s_server (but also in Apache mod_ssl).
>
Fixed in commit 5b326dc529e19194
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech
Hello John,
1. Please update ABICC and ABI Dumper tools. You are currently using too old
versions 1.99.9 and 0.99.7. The newer ones are 1.99.16 and 0.99.14. There are a
lot of improvements: https://github.com/lvc
The update is easy. Just unpack tarballs and type `sudo make install`.
2.
Hi,
I am having the exact same problem, just that I use openssl through Rust.
This is the error I am seeing:
cargo run
Running `target/debug/lantern`
thread '' panicked at 'assertion failed: `(left == right)` (left:
`-1165085120`, right: `1`)',
Is anyone non a non-Mac seeing this?
I'm beginning to think compiler bug.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4290
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
If it makes any difference, I build OpenSSL using hombrew which in turn used
clang:
$ clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.2.0
Thread model: posix
--
Felipe Sere
Sent with Airmail
--
Ticket here:
fixed with commie t124f6ff thanks!
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4304
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
+1
Also, I would like to add that companies and some "security" appliances vendors
really fail to understand the different ciphers properties (especially outside
the web world).
Therefore, IMHO, providing a more fool-proof configuration (e.g. a strict
definition of HIGH and disabling the rest
Hi,
I have multithreaded test programs (client and server) that I use to test
some functionalities build with OpenSSL.
They started to warn about memory leaks when I linked them with version 1.1.
As I had to do some code changes to adapt the new version, I first thought I
forget some [new]
On 13/02/16 22:19, Michel wrote:
> Hi,
>
>
>
> I have multithreaded test programs (client and server) that I use to
> test some functionalities build with OpenSSL.
>
> They started to warn about memory leaks when I linked them with version 1.1.
>
> As I had to do some code changes to adapt
Hi Matt,
Thanks for your quick answer.
I applied your patch and it fixes the leaks found in the simple test
program.
However, a more complex one, still report [other] leaks.
Below is a new log if you can have a look at them.
I will investigate deeper tomorrow concering 1.0.2.
Thanks again,
Hello All,
We are facing this issue for quite sometime, a random crash in SSL3_accept.
We yet to figure out the exact cause as it's quite random and does not
happen frequently - but it does happen once in a few hundred thousand
connections and crashing the server. We are using openssl 1.0.1e on
On Sun, Feb 14, 2016 at 11:51:40AM +0530, JM wrote:
> Hello All,
>
> We are facing this issue for quite sometime, a random crash in SSL3_accept.
> We yet to figure out the exact cause as it's quite random and does not
> happen frequently - but it does happen once in a few hundred thousand
>
17 matches
Mail list logo
