Re: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library

2018-11-28 Thread Kyle Hamilton
I thibk those are all the .asm modules. If they are, you'll probably want to Configure with no-asm and rebuild in order to get the C implementations. -Kyle H On Wed, Nov 28, 2018, 01:07 Vinay Kumar via openssl-users < openssl-users@openssl.org wrote: > Hi All, > > The 32bit OpenSSL 1.1.0i

[openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library

2018-11-28 Thread Vinay Kumar via openssl-users
Hi All, The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope GSCheck on Windows. E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the following modules for which a language could not be identified. Ensure these were compiled with debug information and run BinScope

[openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

2018-11-28 Thread Fuchs, Andreas
Hi all, I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific

Re: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library

2018-11-28 Thread Angus Robertson - Magenta Systems Ltd
> The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for > binscope GSCheck on Windows. This must be a customised non-standard library, since 1.1.0 does not build with that name, but as libcrypto-1_1.dll. Angus -- openssl-users mailing list To unsubscribe:

Re: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library

2018-11-28 Thread Jakob Bohm via openssl-users
If GSCheck is just a tool to check if you remembered to build code with the buffer overflow checks that Microsoft C can insert, then you should just treat this as a warning that the tool doesn't know how to check code from other compilers (in this case the manual work of the OpenSSL team). On

[openssl-users] Mail

2018-11-28 Thread mhirkhan.17
Sent from my Samsung Galaxy smartphone.-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL Versioning and License

2018-11-28 Thread Matt Caswell
Please see the following blog post about OpenSSL Versioning and License: https://www.openssl.org/blog/blog/2018/11/28/version/ Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] SNI callback

2018-11-28 Thread Jeremy Harris
OpenSSL 1.1.1 FIPS 11 Sep 2018 RHEL 8.0 beta Using SSL_CTX_set_tlsext_servername_callback() when the called routine returns SSL_TLSEXT_ERR_NOACK I was expecting the handshake to fail. It carries on; am I doing something wrong? -- Thanks, Jeremy -- openssl-users mailing list To unsubscribe:

Re: [openssl-users] SNI callback

2018-11-28 Thread Benjamin Kaduk via openssl-users
On Wed, Nov 28, 2018 at 08:48:10PM +, Jeremy Harris wrote: > OpenSSL 1.1.1 FIPS 11 Sep 2018 > RHEL 8.0 beta > > Using SSL_CTX_set_tlsext_servername_callback() > when the called routine returns SSL_TLSEXT_ERR_NOACK > I was expecting the handshake to fail. It carries > on; am I doing

Re: [openssl-users] SNI callback

2018-11-28 Thread Jeremy Harris
On 28/11/2018 21:03, Benjamin Kaduk via openssl-users wrote: > On Wed, Nov 28, 2018 at 08:48:10PM +, Jeremy Harris wrote: >> OpenSSL 1.1.1 FIPS 11 Sep 2018 >> RHEL 8.0 beta >> >> Using SSL_CTX_set_tlsext_servername_callback() >> when the called routine returns SSL_TLSEXT_ERR_NOACK >> I was

Re: [openssl-users] [openssl-announce] OpenSSL Versioning and License

2018-11-28 Thread Jonathan Larmour
On 28/11/18 17:02, Matt Caswell wrote: > Please see the following blog post about OpenSSL Versioning and License: > > https://www.openssl.org/blog/blog/2018/11/28/version/ :-( The Apache license is incompatible with GPLv2: https://www.apache.org/licenses/GPL-compatibility.html Those of us

Re: [openssl-users] [openssl-announce] OpenSSL Versioning and License

2018-11-28 Thread Daniel Kahn Gillmor
On Wed 2018-11-28 19:54:34 +, Jonathan Larmour wrote: > On 28/11/18 17:02, Matt Caswell wrote: >> Please see the following blog post about OpenSSL Versioning and License: >> >> https://www.openssl.org/blog/blog/2018/11/28/version/ > > :-( > > The Apache license is incompatible with GPLv2: > >

Re: [openssl-users] [openssl-announce] OpenSSL Versioning and License

2018-11-28 Thread Jonathan Larmour
On 28/11/18 21:41, Daniel Kahn Gillmor wrote: > On Wed 2018-11-28 19:54:34 +, Jonathan Larmour wrote: >> On 28/11/18 17:02, Matt Caswell wrote: >>> Please see the following blog post about OpenSSL Versioning and License: >>> >>> https://www.openssl.org/blog/blog/2018/11/28/version/ >> >> :-(

Re: [openssl-users] SNI callback

2018-11-28 Thread Viktor Dukhovni
> On Nov 28, 2018, at 3:48 PM, Jeremy Harris wrote: > > Using SSL_CTX_set_tlsext_servername_callback() > when the called routine returns SSL_TLSEXT_ERR_NOACK > I was expecting the handshake to fail. It carries > on; am I doing something wrong? For an SMTP server, SNI values that don't match

Re: [openssl-users] [openssl-announce] OpenSSL Versioning and License

2018-11-28 Thread Salz, Rich via openssl-users
This was discussed around when OpenSSL first talked about the project. You might find it worth reading the various blog entries (and comment/responses) https://www.openssl.org/blog/blog/categories/license/ One thing to note is that cryptography can be a patent minefield, and the patent

Re: [openssl-users] 1.1.1a: crash in CRYPTO_THREAD_lock_free

2018-11-28 Thread Claus Assmann
Thanks for the reply, it helped me adding some more debugging statements to various places to track down the problem: it is due to a change in TLS session handling in TLSv1.3. It seems there are multiple SSL_SESSION structures for a single SSL connection (SMTP session). The callback installed

Re: [openssl-users] 1.1.1a: crash in CRYPTO_THREAD_lock_free

2018-11-28 Thread Viktor Dukhovni
> On Nov 28, 2018, at 6:31 PM, Claus Assmann wrote: > > Thanks for the reply, it helped me adding some more debugging > statements to various places to track down the problem: > it is due to a change in TLS session handling in TLSv1.3. Thanks for following up, much appreciated. > It seems