Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

> Two more observations. > > OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not > fitting into the expected integer size being zeroed. I do not know if it is > practically relevant, but it is strange that a read has side effects. It > would be a good reason for

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

> Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is > hidden, I still have to try over environment variables, which are not > as flexible for arm as for x86). > > > Anyway, it would be helpful to exclude hardware aes instructions at > compile-time: > > 1) Runtime checking is

Re: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends

On 14/06/16 21:30, David Benjamin via RT wrote: > For OpenSSL master, I believe it'd also work to add an s->rbio != s->wbio > check to SSL_set_rbio, but I think those are worse semantics for > SSL_set_{rbio,wbio}. They are new APIs, so, before it's too late, give them > clear semantics like

[openssl-dev] [openssl.org #4456] Fedora 1, i386: error: field `next_timeout` has incomplete type

Jeff has confirmed that this issue has been fixed in latest master. Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4456 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe:

[openssl-dev] [openssl.org #4565] Fatal error: Command failed for target `link_shlib.solaris'

This is fixed in latest master. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4565 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is hidden, I still have to try over environment variables, which are not as flexible for arm as for x86). Anyway, it would be helpful to exclude hardware aes instructions at compile-time: 1) Runtime checking is error prone

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

Perhaps we should consider if there are any negative consequences to my solution? It does work. I am trying really hard to get contention but I am only seeing this problem in about 1 out of 100,000 successful TLSv1.2 connections On a heavily congested network. I require three machines to just

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

Sending mail re-opens the ticket. Rats, wish it was fixed. Going to need something to more easily reproduce it, I guess. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

On 17/06/16 19:43, Mick Saxton via RT wrote: > Perhaps we should consider if there are any negative consequences to my > solution? > It does work. > > I am trying really hard to get contention but I am only seeing this problem > in about 1 out of 100,000 successful TLSv1.2 connections > On a

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

Hi Rich Many thanks for doing that – unfortunately it is not the whole fix. I checked out the latest v1.0.2i-dev and built that but I still get the crash. I know the ticket is now “closed” – do you need me to reopen it? I am still convinced that I don’t get it with the “master” build – but that

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

On 17/06/16 20:56, Matt Caswell via RT wrote: > > > On 17/06/16 19:43, Mick Saxton via RT wrote: >> Perhaps we should consider if there are any negative consequences to my >> solution? >> It does work. >> >> I am trying really hard to get contention but I am only seeing this problem >> in

Re: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends

On Fri, Jun 17, 2016 at 8:48 AM Matt Caswell via RT wrote: > > > On 14/06/16 21:30, David Benjamin via RT wrote: > > For OpenSSL master, I believe it'd also work to add an s->rbio != s->wbio > > check to SSL_set_rbio, but I think those are worse semantics for > >

Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

> Thanks for the explanations. > > In the code I am working with, I see: > $ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c > unsigned long *OPENSSL_ia32cap_loc(void) > > You may want to verify it. Right! Sorry about confusion, my bad! It was long in 1.0.x and in became int in master. Anyway,

Re: [openssl-dev] Latest Open SSL and old FIP module

On 06/17/2016 07:48 AM, Alibek Joraev wrote: > Currently, I use 1.0.1 series (with current one being 1.0.1t) of OpenSSL > with OpenSSL FIPS module version 2.0.2. > as 1.0.1 version nears its long term support, I would like to upgrade to > OpenSSL 1.0.2h, but keep existing 2.0.2 FIPS module. > > I

Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

Thanks for the explanations. In the code I am working with, I see: $ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c unsigned long *OPENSSL_ia32cap_loc(void) You may want to verify it. I happen to be using features introduced for testing and debugging, without knowing it. For debatable reasons,

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

Your technical arguments are sound, indeed. From: Andy Polyakov via RT Sent: Friday, June 17, 2016 5:13:50 PM To: Loic Etienne Cc: openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

1) Openssl works correctly (no crash, correct detection), as far as I can judge. By error-prone I mean, very defensively, that I (or others) could make a mistake, or that future versions of openssl could not work exactly the same way. 2) I would agree with your argumentation. But some

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

> 1) Openssl works correctly (no crash, correct detection), as far as I > can judge. By error-prone I mean, very defensively, that I (or > others) could make a mistake, or that future versions of openssl > could not work exactly the same way. Well, this is effectively argument in favour of