[openssl-dev] [openssl.org #4254] PR for BLAKE2 support

[Matt Caswell via RT]

This was merged previously.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4254
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4248] Link error under Windows

[Matt Caswell via RT]

Appears to have been reopened in error. Closing again.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4248
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes

[Matt Caswell via RT]

The issue as originally described in this ticket has been fixed.

A comment was added at one point to this ticket:
"May I suggest the bug also becomes a wish for support for > 2GB
numbers, as that is what the user originally wanted?"

It's not clear that that is desirable and is unlikely to be added. Therefore
closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4227
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4217] Fixing DJGPP port of openssl master branch.

[Matt Caswell via RT]

Ping Richard Levitte.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4217
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4212] Compilation of master branch fails with 's_nbio' undeclared (first use in this function).

[Matt Caswell via RT]

Looks like this was fixed by ba8108154d.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4212
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4207] engine key format in 1.1

[Matt Caswell via RT]

Seems to have been mostly fixed by dd9589740d, but it looks like there may be a
few things in this patch not covered by that commit. Keeping this open for now.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4207
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format

[Matt Caswell via RT]

Github pull 570 which was associated with this ticket has been closed, so
closing this too.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4201
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's malloc failure handling

[Matt Caswell via RT]

Seems to have been fixed by 6aa0ba4bb28.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4185
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4178] [patch] OpenSSL 1.1.0 fails when configure with no-nextproto

[Matt Caswell via RT]

This seems to be working now.

Closing ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4178
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4177] opaque X509 struct issues

[Matt Caswell via RT]

Stephen answered this issue. The X509_get0_extensions() function does now seem
to be documented.

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4177
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4176] Add support for async jobs in OpenSSL speed

[Matt Caswell via RT]

Added in commit 8b0b80d923. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4176
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1298] OpenSSL bug in libcrypto.so:RAND_poll() crashes apache2 @ startup

[Matt Caswell via RT]

On Mon May 09 15:05:32 2016, rs...@akamai.com wrote:
> It's probably not an issue because the number of file descriptors has
> increased on the native O/S's. But "file descriptor exhaustion" is
> still an issue for RNG's (google it) and we should keep it in mind for
> the future. What's the best way to do that?

We should incorporate it into the requirements for when we do the RNG rewrite
(post 1.1.0). Perhaps a feature request gh issue?

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1298
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1215] Bug Report for OpenSSL

[Matt Caswell via RT]

Fixed in commit 3105d69.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1215
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1916] [PATCH] Fix for memleaks, use after free and optimizations

[Matt Caswell via RT]

These patches no longer apply and are no longer relevant to the latest
codebase.

Closing

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1916
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1912] BIO_printf/BIO_vprintf error in 0.9.8k

[Matt Caswell via RT]

I don't believe this is an issue any more as the maxlen increases along with
the dynamic buffer so no truncation should take place.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1912
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1875] Fwd: [PATCH] Small bug fixes and coding style corrections

[Matt Caswell via RT]

These patches no longer apply and are no longer relevant.

Closing

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1875
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1873] SMIME_write_PKCS7 and CRLF in base64 signature

[Matt Caswell via RT]

This doesn't seem to match up in any way with current code so I guess it is no
longer relevant.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1873
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1833] [PATCH] Abbreviated Renegotiations

[Matt Caswell via RT]

This doesn't seem to be the case any more.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1833
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1769] bug report: Array overruns

[Matt Caswell via RT]

At some in the intervening period since this was raised these issues have been
fixed.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1769
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1298] OpenSSL bug in libcrypto.so:RAND_poll() crashes apache2 @ startup

[Matt Caswell via RT]

Due to the elapsed time I am assuming this is no longer a problem for apache.
Please create a new ticket if this is still a problem!

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1298
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1241] apps/s_client.c: 2 changes in initial handshake

[Matt Caswell via RT]

These no longer apply due to the elapsed time.

The verify patch doesn't quite make sense (maybe it did when this was written)
because SSL_VERIFY_FAIL_IF_NO_PEER_CERT is a server side only option.

The "manual" option to starttls is quite a neat idea, but will not be applied
in its current state. A new patch should be developed against current master if
this is still wanted!!

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1241
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] [Suggestion] crypto/threads_win.c: Follow Consistent Return Style

[Matt Caswell]

Looks ok to me. I suggest you raise it as a GitHub PR.

Matt

On 08/05/16 08:52, Kurt Cancemi wrote:
> Every function that returns an int in crypto/threads_win.c returns 0
> immediately if the function called from inside the function fails
> except CRYPTO_THREAD_run_once() which returns 1 immediately if the
> function called from inside the function succeeds.
> 
> InitOnceExecuteOnce returns 0 on failure
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms683493%28v=vs.85%29.aspx
> 
> So my suggestion would be to follow this convention in
> CRYPTO_THREAD_run_once() too:
> 
> --- crypto/threads_win.c2016-05-08 03:42:44.401795919 -0400
> +++ crypto/threads_win.c2016-05-08 03:42:55.151796152 -0400
> @@ -135,10 +135,10 @@
> 
>  int CRYPTO_THREAD_run_once(CRYPTO_ONCE *once, void (*init)(void))
>  {
> -if (InitOnceExecuteOnce(once, once_cb, init, NULL))
> -return 1;
> +if (!InitOnceExecuteOnce(once, once_cb, init, NULL))
> +return 0;
> 
> -return 0;
> +return 1;
>  }
> 
>  # endif
> 
> --
> Kurt Cancemi
> https://www.x64architecture.com
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4534] Re: [PATCH] Add missing NULL check in i2d_PrivateKey()

[Matt Caswell via RT]

Closing this ticket at request of submitter. Erroneous duplicate of #4533

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4534
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Matt Caswell via RT]

On Sat Apr 30 19:51:51 2016, hen...@newdawn.dk wrote:
> Hi there
>
> I've recently come across what looks to be an internal bug in openssl:
>
> Original symptoms was that neither "curl" or "wget" could access the
> following site:
>
> https://coverage.tre.se - this site is using TLS 1.0 (only) and does
> have some pretty crazy certificate issues - but does show up "green"
> in most browsers (Unless you're on a system with an openssl which
> supports TLS 1.2 ).
>
> Accessing the site (curl / wget) hangs during SSL handshake.
>
> I then tried:
> openssl s_client -connect coverage.tre.se:443 which hangs as well
>
> By forcing the protocol to TLS1.0 it will correctly parse and see the
> certificate. By forcing protocol to TLS1.1 it'll correctly error out
> saying invalid protocol. Even just telling s_client to not include TLS
> 1.2 will make it work as expected.
>
> So to sum up:
>
> My guess would be that some incompatibility between the 1.0 and 1.2
> protocol causes 1.2 to not determine correctly that the server does
> not support it , and as such is unable to fallback to previous
> versions.
>
> I have verified this on several ubuntu 14.04 machines with the
> following openssl versions:
>
> OpenSSL 1.0.1f 6 Jan 2014
>
>
> OpenSSL 1.0.2g 1 Mar 2016
>
> And I've verified that it does work as expected on OSX which has a
> openssl version that does not support TLS 1.2:
>
> OpenSSL 0.9.8zg 14 July 2015
>
> Hope this helps resolve the issue.

This is not a bug in OpenSSL. The problem here is that the server is behaving
incorrectly when receiving large ClientHello messages. The ClientHello is the
first message that is sent from the client to the server. If a large
ClientHello is received then the server just hangs. The reason that this
impacts TLSv1.2 and not other versions is that there are more ciphersuites
available for that protocol version and therefore the ClientHello is bigger.

You can verify that it all works correctly by restricting the number of
ciphersuites that the client sends in its ClientHello. E.g. just sending one
ciphersuite:

openssl s_client -connect coverage.tre.se:443 cipher AES128-SHA

The above command works fine and successfully connects. If fixing the server is
not an option then a simple workaround is to define a ciphersuite selection
string that restricts the ciphersuites to a smaller set.

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
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 #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Matt Caswell]

On 26/04/16 16:16, Douglas E Engert wrote:
> Let me update my response.
> If I am reading GH#995 correctly it still has an issue if a user does:
> 
> RSA_get0_key(rsa, n, e, NULL); /* note this is a GET0 */
> /* other stuff done, such as calculating d */
> RSA_set0_key(rsa, n, e, d);
> 
> rsa is left with n and e pointing to unallocated storage.

You should not call it like that (programmer error). RSA_get0_key
transfers ownership of the memory. You must only transfer ownership for
memory that you own! By calling it again you are attempting to transfer
ownership of memory that you don't own.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] digest SN_ecdsa_with_SHA256 and NID_ecdsa_with_SHA256

[Matt Caswell]

On 26/04/16 10:39, Gäckler Martin (EXT) wrote:
> Hi Matt,
> 
> Thanks for the reply. According to my colleague the PHP function
> opens_verify uses EVP_get_digestbyname to retrieve the EVP_MD. This
> does not work for the digest name "ecdsa-with-SHA256".

Hmmm. No. Well "ecdsa-with-SHA256" is not a digest, so I would not
expect EVP_get_digestbyname() to return one. But "sha256" is. Have you
tried just using that? I am not familiar with the PHP language bindings
at all, but I would expect that the ECDSA bit would be derived from the
type of key used (i.e. if you supply an EC key then it will use ECDSA).

Matt

> 
> Nevertheless, I will try to create a new branch.
> 
> Thanks again.
> 
> Martin
> 
> 
> 
> -Original Message- From: openssl-dev
> [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell 
> Sent: Dienstag, 26. April 2016 11:12 To: openssl-dev@openssl.org 
> Subject: Re: [openssl-dev] digest SN_ecdsa_with_SHA256 and
> NID_ecdsa_with_SHA256
> 
> 
> 
> On 26/04/16 09:43, Gäckler Martin (EXT) wrote:
>> We're currently developing a system that uses OAuth protocol to 
>> identify the users. The service provider is developed in PHP and
>> uses OpenSSL to verify the access token. Unfortunately the identity
>>  provider, which is managed by another company, uses ecdsa with
>> sha256 to sign the access tokens. Although the constants for this
>> method (SN_ecdsa_with_SHA256 and NID_ecdsa_with_SHA256) are defined
>> in OpenSSL, this method is currently not supported by OpenSSL.
> 
> I'm not really sure what that means, since its perfectly possible to
> use ECDSA in conjunction with SHA256 to sign data. E.g. just use 
> EVP_sha256() as the EVP_MD, and create an EC EVP_PKEY in a call to 
> EVP_DigestSignInit()
> 
> https://www.openssl.org/docs/manmaster/crypto/EVP_DigestSignInit.html
>
> 
> 
>> 
>> My question is, what can I do, to add my changes to the official 
>> OpenSSL sources. I'm new to github and OpenSSL development and I
>> did not find a documentation suitable for me. We would appreciate
>> if this method would become part of the official OpenSSL
>> distribution.
> 
> Create a new branch based on the master branch in git (new features
> are not accepted into stable releases). Add your features to it and
> push your changes to your github repo, and then create a github pull
> request.
> 
> Matt
> 
> -- openssl-dev mailing list To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] digest SN_ecdsa_with_SHA256 and NID_ecdsa_with_SHA256

[Matt Caswell]

On 26/04/16 09:43, Gäckler Martin (EXT) wrote:
> We’re currently developing a system that uses OAuth protocol to identify
> the users. The service provider is developed in PHP and uses OpenSSL to
> verify the access token. Unfortunately the identity provider, which is
> managed by another company, uses ecdsa with sha256 to sign the access
> tokens. Although the constants for this method (SN_ecdsa_with_SHA256 and
> NID_ecdsa_with_SHA256) are defined in OpenSSL, this method is currently
> not supported by OpenSSL.

I'm not really sure what that means, since its perfectly possible to use
ECDSA in conjunction with SHA256 to sign data. E.g. just use
EVP_sha256() as the EVP_MD, and create an EC EVP_PKEY in a call to
EVP_DigestSignInit()

https://www.openssl.org/docs/manmaster/crypto/EVP_DigestSignInit.html


> 
> My question is, what can I do, to add my changes to the official OpenSSL
> sources. I’m new to github and OpenSSL development and I did not find a
> documentation suitable for me. We would appreciate if this method would
> become part of the official OpenSSL distribution.

Create a new branch based on the master branch in git (new features are
not accepted into stable releases). Add your features to it and push
your changes to your github repo, and then create a github pull request.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Matt Caswell]

On 26/04/16 08:26, Richard Levitte wrote:
> [temporarly taking this thread away from RT]
> 
> Basically, I can see two solutions:
> 
> - Allow calls like RSA_set0_key(rsa, NULL, NULL, d);
> 
>   That's what's implemented in GH#995, except it doesn't check if the
>   input parameters are NULL before setting the corresponding fields,
>   so that call ends up clearing n and e.
> 
>   GH#995 could be changed so that any input parameter can be NULL, and
>   that the corresponding RSA structure fields are left untouched.  The
>   consequence is that can never be made NULL.  I can live with that,
>   as I can't imagine a reason to reset the fields to NULL.

IMO this is the way to go. As long as we can't set private key values
without first having set the public key, i.e. we should not be able to
get into an inconsistent state.

Matt



> 
> - Add a function RSA_set0_d(RSA *rsa, BIGNUM *d)
> 
> I personally prefer the first variant, but would like to have some
> input and thoughts (or just a "go ahead").
> 
> Cheers,
> Richard
> 
> In message  on Tue, 26 
> Apr 2016 06:01:59 +, Richard Levitte via RT  said:
> 
> rt> Unfortunately, the solution in that PR is flawed. Back to the drawing 
> board.
> rt> 
> rt> Vid Mon, 25 apr 2016 kl. 18.39.24, skrev levitte:
> rt> > So, listening to what everyone had to say, perhaps this PR is better
> rt> > then:
> rt> >
> rt> > https://github.com/openssl/openssl/pull/995
> rt> >
> rt> > In message  rt> > dag1mb1.msg.corp.akamai.com> on Mon, 25 Apr 2016 17:45:05 +,
> rt> > "Salz, Rich"  said:
> rt> >
> rt> > rsalz>
> rt> > rsalz> > The 3-slot function is I think cleaner.
> rt> > rsalz> >
> rt> > rsalz> > I'll leave the decision of whether and when to support NULL
> rt> > rsalz> > parameters to
> rt> > rsalz> > the folks working on that code, but it is pretty clear that
> rt> > rsalz> > one must not pass an
> rt> > rsalz> > object one does not "own", such as one returned from a "get0"
> rt> > rsalz> > function, to a
> rt> > rsalz> > function that expects to take ownership of the indicated
> rt> > rsalz> > object.
> rt> > rsalz>
> rt> > rsalz> Agree with both of those.
> rt> > rsalz>
> rt> > rsalz> After a "set0" call, set your pointer to NULL, it's no longer
> rt> > rsalz> yours :)
> rt> > rsalz> --
> rt> > rsalz> openssl-dev mailing list
> rt> > rsalz> To unsubscribe:
> rt> > rsalz> https://mta.openssl.org/mailman/listinfo/openssl-dev
> rt> > rsalz>
> rt> 
> rt> 
> rt> --
> rt> Richard Levitte
> rt> levi...@openssl.org
> rt> 
> rt> -- 
> rt> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4518
> rt> Please log in as guest with password guest if prompted
> rt> 
> rt> -- 
> rt> openssl-dev mailing list
> rt> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> rt> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Core dump OpenSSL 1.1.0-pre5 during test (likely in 70-test_sslskewith0p.t)

[Matt Caswell]

On 20/04/16 09:24, Matt Caswell wrote:
> 
> 
> On 19/04/16 19:40, Rainer Jung wrote:
>> I get a core dump during test execution for 1.1.0-pre5. Test is
>> test/recipes/70-test_sslskewith0p.t, platform is Solaris 10 Sparc.
> 
> Thanks for the detailed analysis. Based on that I have been able to
> identify the problem. Fix on the way.

Should be fixed by this commit:

https://github.com/openssl/openssl/commit/ee85fc1dd67faebdeecb8fe8834facaee0566324

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows Patch affecting connectivity to our applications

[Matt Caswell]

On 20/04/16 15:03, Thirumal, Karthikeyan wrote:
> Thanks Rich.
> 
> We first attempted to move to openssl-0.9.8zc - but we faced memory issues 
> and our process got dumped at SSL_free. So we backed out and moved back to 
> 9.8a.
> 
> Can I go to 0.9.8e version and will the SSL fragment issue be fixed there ?

I don't know what the cause of the fragments issue is. AFAICS fragments
should work just fine in 0.9.8. However, there are a large number of
bugs that were fixed between 0.9.8a and 0.9.8zc. As neither version is
in support any more you'd have to try it for yourself. But really Rich
is absolutely right...the correct answer here is upgrade to a supported
version (i.e. not a 0.9.8/1.0.0 based version) and fix the memory issues
you are experiencing. OpenSSL is a security product. With the version
that you are currently running you are effectively getting near zero
security benefit.

Matt

> 
> Thanks & Regards
> 
> Karthikeyan Thirumal
> 
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Salz, 
> Rich
> Sent: Friday, April 15, 2016 10:26 PM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] Windows Patch affecting connectivity to our 
> applications
> 
>> Can you tell me if we can enable SSL in fragments with openssl-0.9.8a ? So
> 
> Upgrade.
> 
> Sorry, that's the only answer.
> 
> --  
> Senior Architect, Akamai Technologies
> IM: richs...@jabber.at Twitter: RichSalz
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Broken links in pod file of OpenSSL 1.1.0pre5

[Matt Caswell]

On 19/04/16 20:18, Rainer Jung wrote:
> Output during "make install":
> 
> Cannot find "BIO_gets" in podpath: cannot find suitable replacement
> path, cannot resolve link
> Cannot find "BIO_callback_ctrl" in podpath: cannot find suitable
> replacement path, cannot resolve link
> Cannot find "DSA_SIG_new3)" in podpath: cannot find suitable replacement
> path, cannot resolve link
> 
> Likely patch (it fixes the warnings, but please double check for
> correctness):

Patch applied:
https://github.com/openssl/openssl/commit/ecba1fb386919b70933fa0447ee7438d9379dea0

Thanks!

Matt

> 
> --- doc/crypto/DSA_meth_new.pod2016-04-19 18:51:18.0 +0200
> +++ doc/crypto/DSA_meth_new.pod2016-04-19 21:06:01.785837000 +0200
> @@ -174,7 +174,7 @@
>  =head1 SEE ALSO
> 
>  L, L, L,
> L,
> -L, L, L,
> L,
> +L, L, L,
> L,
>  L, L, L
> 
>  =head1 HISTORY
> 
> 
> ( "DSA_SIG_new(3)" instead of "DSA_SIG_new3)").
> 
> 
> --- doc/crypto/BIO_meth_new.pod2016-04-19 18:51:18.0 +0200
> +++ doc/crypto/BIO_meth_new.pod2016-04-19 21:14:10.702572000 +0200
> @@ -75,7 +75,7 @@
>  the function have the same meaning as for BIO_puts().
> 
>  BIO_meth_get_gets() and BIO_meth_set_gets() get and set the function
> typically
> -used for reading a line of data from the BIO respectively (see the
> L
> +used for reading a line of data from the BIO respectively (see the
> L
>  page for more information). This function will be called in response to
> the
>  application calling BIO_gets(). The parameters for the function have
> the same
>  meaning as for BIO_gets().
> @@ -102,7 +102,7 @@
> 
>  BIO_meth_get_callback_ctrl() and BIO_meth_set_callback_ctrl() get and
> set the
>  function used for processing callback ctrl messages in the BIO
> respectively. See
> -the L page for more information. This function will
> be called
> +the L page for more information. This function
> will be called
>  in response to the application calling BIO_callback_ctrl(). The
> parameters for
>  the function have the same meaning as for BIO_callback_ctrl().
> 
> 
> (Adding twice "(3)").
> 
> Regards,
> 
> Rainer
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Core dump OpenSSL 1.1.0-pre5 during test (likely in 70-test_sslskewith0p.t)

[Matt Caswell]

On 19/04/16 19:40, Rainer Jung wrote:
> I get a core dump during test execution for 1.1.0-pre5. Test is
> test/recipes/70-test_sslskewith0p.t, platform is Solaris 10 Sparc.

Thanks for the detailed analysis. Based on that I have been able to
identify the problem. Fix on the way.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows Patch affecting connectivity to our applications

[Matt Caswell]

On 15/04/16 10:33, Thirumal, Karthikeyan wrote:
> Yes Matt - I agree that it is a very old / low version that we are
> using. We faced few memory issues with the 0.9.8zc - so we backed out
> and lived with 9.8a. In addition we are also planning to terminate
> SSL at F5 rather than our Server - so we did not really care about
> the lower version.
> 
> Am still unclear what is the patch that MS released on April 12 that
> is affecting the SSL communication ?

No idea - that's probably more a question for MS.

> 
> Some more info -  My F5 version in test region uses 0.9.8e version
> and connectivity is working fine. Can you clarify the SSL related
> differences between 8a and 8e ?

The Change log summarises the major differences. See:

https://github.com/openssl/openssl/blob/OpenSSL_0_9_8-stable/CHANGES#L1254

Matt


> 
> Thanks & Regards  Karthikeyan Thirumal
> 
> -Original Message- From: openssl-dev
> [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell 
> Sent: Friday, April 15, 2016 2:05 PM To: openssl-dev@openssl.org 
> Subject: Re: [openssl-dev] Windows Patch affecting connectivity to
> our applications
> 
> 
> 
> On 15/04/16 09:15, Thirumal, Karthikeyan wrote:
>> Dear Dev folks,
>> 
>> My clients are facing are connectivity issues after windows
>> released their OS upgrade this week. I think they have changed the
>> way the SSL handshake happens.
>> 
>> My Server is using openssl-0.9.8a and my client sits on a Microsoft
>>  platform.
>> 
>> 
>> 
>> From OpenSSL - do we have a recommendation to overcome this 
>> connectivity issue that started after the Microsoft patch ? Please
>> confirm.
> 
> We have not had other reports of this issue, so I have no specific
> recommendation. However openssl-0.9.8a is a *very* old version of
> OpenSSL (released October 2005). The 0.9.8 series is out of support
> and is no longer receiving security bug fixes. Your server is almost
> certainly vulnerable to significant security defects. You should
> upgrade to a supported version as soon as possible. As we have not
> had other reports of this problem this is likely to solve your
> Microsoft issue too.
> 
> Matt
> 
> 
> 
>> 
>> 
>> 
>> 
>> 
>> Thanks & Regards  Karthikeyan Thirumal
>> 
>> 
>> 
>> 
>> ** This message
>> and any files or attachments sent with this message contain
>> confidential information and is intended only for the individual
>> named. If you are not the named addressee, you should not
>> disseminate, distribute, copy or use any part of this email. If you
>> have received this message in error, please delete it and all
>> copies from your system and notify the sender immediately by return
>> Email.
>> 
>> Email transmission cannot be guaranteed to be secure or error-free
>> as information can be intercepted, corrupted, lost, destroyed,
>> late, incomplete or may contain viruses. The sender, therefore,
>> does not accept liability for any errors or omissions in the
>> contents of this message, which arise as a result of email
>> transmission. 
>> **
>> 
>> 
> -- openssl-dev mailing list To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
> ** This message
> and any files or attachments sent with this message contain
> confidential information and is intended only for the individual
> named.  If you are not the named addressee, you should not
> disseminate, distribute, copy or use any part of this email.  If you
> have received this message in error, please delete it and all copies
> from your system and notify the sender immediately by return Email.
> 
> Email transmission cannot be guaranteed to be secure or error-free as
> information can be intercepted, corrupted, lost, destroyed, late,
> incomplete or may contain viruses.  The sender, therefore, does not
> accept liability for any errors or omissions in the contents of this
> message, which arise as a result of email transmission. 
> **
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows Patch affecting connectivity to our applications

[Matt Caswell]

On 15/04/16 09:15, Thirumal, Karthikeyan wrote:
> Dear Dev folks,
> 
> My clients are facing are connectivity issues after windows released
> their OS upgrade this week. I think they have changed the way the SSL
> handshake happens.
> 
> My Server is using openssl-0.9.8a and my client sits on a Microsoft
> platform.
> 
>  
> 
> From OpenSSL – do we have a recommendation to overcome this connectivity
> issue that started after the Microsoft patch ? Please confirm.

We have not had other reports of this issue, so I have no specific
recommendation. However openssl-0.9.8a is a *very* old version of
OpenSSL (released October 2005). The 0.9.8 series is out of support and
is no longer receiving security bug fixes. Your server is almost
certainly vulnerable to significant security defects. You should upgrade
to a supported version as soon as possible. As we have not had other
reports of this problem this is likely to solve your Microsoft issue too.

Matt



> 
>  
> 
>  
> 
> Thanks & Regards
> 
> Karthikeyan Thirumal
> 
>  
> 
> 
> **
> This message and any files or attachments sent with this message contain
> confidential information and is intended only for the individual named.
> If you are not the named addressee, you should not disseminate,
> distribute, copy or use any part of this email. If you have received
> this message in error, please delete it and all copies from your system
> and notify the sender immediately by return Email.
> 
> Email transmission cannot be guaranteed to be secure or error-free as
> information can be intercepted, corrupted, lost, destroyed, late,
> incomplete or may contain viruses. The sender, therefore, does not
> accept liability for any errors or omissions in the contents of this
> message, which arise as a result of email transmission.
> **
> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4499] ARM32 and "undefined reference to `engine_load_afalg_internal'"

[Matt Caswell via RT]

Please try again from latest master. Possibly fixed by 627537ddf379.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4499
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4455] OpenSUSE 42: undefined reference to `engine_load_afalg_internal'

[Matt Caswell via RT]

Please can you try this again on latest master. Possibly fixed by 627537ddf379.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4455
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] Start contributing to OpenSSL

[Matt Caswell]

On 14/04/16 01:31, CHOW Anthony wrote:
> I would like to start contributing to this project.  On github under
> openssl/CONTRIBUTING stated that there are local unit testing that can
> be done for sanity checking that we can do before submitting a PR.
> 
>  
> 
> In some cases, running these local unit test is not enough.  I will be
> doing the changes on a Ubuntu 14.04 system, is there any other way that
> I can test my code via some upper level “application” such as web
> browser such that I can switch between the official version and the
> version with my changes.  

Most people use s_client/s_server.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] requirements for tests in openssl 1.1.0 (openssl-SNAP-20160331)

[Matt Caswell]

On 01/04/16 16:06, Martin Hecht wrote:
> on SUSE Linux Enterprise Server 11 SP3, when running
> 
> ./config && make test
> 
> I get errors like:
> Compilation failed in require at ../test/recipes/90-test_v3name.t line 3.
> BEGIN failed--compilation aborted at ../test/recipes/90-test_v3name.t
> line 3.
> # Looks like your test died before it could output anything.
> ../test/recipes/90-test_v3namedubious   
> 
> Test returned status 255 (wstat 65280, 0xff00)
> FAILED--72 test scripts could be run, alas--no output ever seen
> make: *** [test] Error 255
> 
> runing the tests manually shows that the Test::More module is of an
> older version than expected:
> /tmp/tmp.COsNuvUJPw/openssl-SNAP-20160331> perl
> test/recipes/90-test_v3name.t
> Test::More version 0.96 required--this is only version 0.72 at
> /tmp/tmp.COsNuvUJPw/openssl-SNAP-20160331/test/testlib/OpenSSL/Test.pm
> line 6.
> 
> Of course I could install that perl module locally in my $HOME to get
> the test running.
> But is this a hard requirement or could a lower version do the job as well?
> 
> The same problem on Scientific Linux  release 6.7 (Carbon), a RHEL clone:
> ../test/recipes/01-test_abort.t ... Test::More version 0.96
> required--this is only version 0.92 at ../test/testlib/OpenSSL/Test.pm
> line 6.
> 
> On Ubuntu 14.04.4 LTS all the tests ran through happily.

Test::More version 0.96 or above is a requirement in order to run the tests.

Please refer to README.PERL for more information on this requirement and
how to install any missing modules.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4495] After upgrade openssl to 1.0.2g, it cause core accidently, please help me !

[Matt Caswell via RT]

On 31/03/16 14:00, Hejian via RT wrote:
> Hello, when upgrade openssl to 1.0.2g, If multi thread call the corba
> interface, it will cause core accidently. Please help analyze why the
> core is generated.
> 
> There are two kinds of core stack list below.
> 
> 
> #0  0x7f97729ad324 in RSA_verify () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #1
> 0x7f97729b2c13 in pkey_rsa_verify () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #2
> 0x7f97729e1e6a in EVP_DigestVerifyFinal () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #3
> 0x7f97729ec0d0 in ASN1_item_verify () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #4
> 0x7f9772a0b7f2 in internal_verify () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #5
> 0x7f9772a0d03a in X509_verify_cert () from
> /opt/oss/server/3rdTools/lib/libcrypto.so.1.0.0 #6
> 0x7f97727aed68 in ssl_verify_cert_chain () from
> /opt/oss/server/3rdTools/lib/libssl.so.1.0.0 #7  0x7f977278a486
> in ssl3_get_server_certificate () from
> /opt/oss/server/3rdTools/lib/libssl.so.1.0.0 #8  0x7f977278da22
> in ssl3_connect () from /opt/oss/server/3rdTools/lib/libssl.so.1.0.0 
> #9  0x7f977279797a in ssl23_connect () from
> /opt/oss/server/3rdTools/lib/libssl.so.1.0.0 #10 0x7f97719ad764
> in ACE_SSL_SOCK_Connector::ssl_connect(ACE_SSL_SOCK_Stream&,
> ACE_Time_Value const*) ()
> 
> The first core stack, we suspect there is NULL ptr use in
> internal_verify function:
> 
> when first thread run in X509_PUBKEY_get and create key->pkey, and go
> to EVP_PKEY_free(pkey); At same time another thread run to below
> function find key->pkey not NULL, get the value, and not goto add
> reference. The first thread think the reference decrease to 0 and
> free it. The second thread will call NULL ptr and cause core. Please
> help confirm whether my analyze is correct and why here is a core?
> 
> /* Check to see if another thread set key->pkey first */ 
> CRYPTO_w_lock(CRYPTO_LOCK_EVP_PKEY); if (key->pkey) { 
> CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY); EVP_PKEY_free(ret); ret =
> key->pkey; } else { key->pkey = ret; 
> CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY); } CRYPTO_add(&ret->references,
> 1, CRYPTO_LOCK_EVP_PKEY);
> 

So you think pkey ends up being NULL? Is that just a theory or have you
verified that in a debugger? I can't immediately see a problem with the
above code - the reference counting looks ok to me. Don't forget when
EVP_PKEY_new() gets called the reference count starts off as 1, and in
order to return from the X509_PUBKEY_get() function you must have
incremented the reference count by an additional 1 (no matter in which
order the threads complete the function). Furthermore the
ASN1_item_verify() function in the above stack trace verifies that pkey
!= NULL before it gets as far as calling EVP_DigestVerifyFinal().

Are you able to recompile OpenSSL with debugging symbols included (i.e.
pass the "-d" flag to "config" when building). That may help narrow
things down a bit.


> 
> The second stack we can't find why it cause core, please help analyze
> the source code where may cause core? #0  0x7f84a332bf2d in

Without debugging symbols it is difficult to say much about this one.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4495
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 SNAP 20160330 issues

[Matt Caswell]

On 30/03/16 15:55, The Doctor wrote:
> 
> Just got
> 
> make && make test
> gcc -DZLIB_SHARED -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> +-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS
> +-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
> +-DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> +-DPOLY1305_ASM -DOPENSSLDIR="\"/usr/contrib\""
> +-DENGINESDIR="\"/usr/contrib/lib/engines\"" -DPERL5 -DL_ENDIAN -DTERMIOS
> +-fomit-frame-pointer -O2 -march=i486 -Wall -g -fPIC -Iinclude -I.
> +-Icrypto/include -c -o crypto/mem_dbg.o crypto/mem_dbg.c
> crypto/mem_dbg.c: In function `CRYPTO_mem_leaks':
> crypto/mem_dbg.c:660: dereferencing pointer to incomplete type
> crypto/mem_dbg.c:662: dereferencing pointer to incomplete type
> *** Error code 1
> 
> And what are these lines?
> 
> /* Don't count the BIO that was passed in as a "leak" */
> if (ml.seen && ml.chunks >= 1 && ml.bytes >= (int)sizeof (*b)) {
> ml.chunks--;
> ml.bytes -= (int)sizeof (*b);
> }
> 
> Please fix 
> 

I have a patch for this already in review.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] FW: Current Github build broken (crypto/comp/c_zlib.c:334:25: error: variable has incomplete type 'const BIO_METHOD')

[Matt Caswell]

On 29/03/16 19:25, Blumenthal, Uri - 0553 - MITLL wrote:
>> clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
>> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
>> -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
>> -DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
>> -DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
>> -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  -fPIC -Iinclude -I.
>> -Icrypto/include -MMD -MF crypto/cms/cms_smime.d.tmp -MT
>> crypto/cms/cms_smime.o -c -o crypto/cms/cms_smime.o crypto/cms/cms_smime.c
>> clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
>> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
>> -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
>> -DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
>> -DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
>> -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  -fPIC -Iinclude -I.
>> -Icrypto/include -MMD -MF crypto/comp/c_zlib.d.tmp -MT
>> crypto/comp/c_zlib.o -c -o crypto/comp/c_zlib.o crypto/comp/c_zlib.c
>> crypto/comp/c_zlib.c:334:25: error: variable has incomplete type 'const
>> BIO_METHOD'
>>  (aka 'const struct bio_method_st')
>> static const BIO_METHOD bio_meth_zlib = {
>>^
>> include/openssl/bio.h:293:16: note: forward declaration of 'struct
>> bio_method_st'
>> typedef struct bio_method_st BIO_METHOD;
>>   ^
>> crypto/comp/c_zlib.c:374:7: error: incomplete definition of type 'struct
>> bio_st'
>>bi->init = 1;
>>~~^
>> include/openssl/ossl_typ.h:122:16: note: forward declaration of 'struct
>> bio_st'
>> typedef struct bio_st BIO;
>>   ^
> . . . . . . . . . . . . . . .
>>ret = BIO_ctrl(b->next_bio, cmd, num, ptr);
>>   ~^
>> include/openssl/ossl_typ.h:122:16: note: forward declaration of 'struct
>> bio_st'
>> typedef struct bio_st BIO;
>>   ^
>> crypto/comp/c_zlib.c:628:25: error: incomplete definition of type 'struct
>> bio_st'
>>ret = BIO_ctrl(b->next_bio, cmd, num, ptr);
>>   ~^
>> include/openssl/ossl_typ.h:122:16: note: forward declaration of 'struct
>> bio_st'
>> typedef struct bio_st BIO;
>>   ^
>> fatal error: too many errors emitted, stopping now [-ferror-limit=]
>> 20 errors generated.
>> make: *** [crypto/comp/c_zlib.o] Error 1
>> $
>>
>>

Thanks for the report. This should be fixed now.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] no-ui, warnings and errors

[Matt Caswell]

On 27/03/16 00:16, Jeffrey Walton wrote:
> Is this a supported configuration (no-ui and apps)?

Co-incidentally, Richard has a patch for no-ui that fixes these problems
that is currently in review.

Matt



> 
> There's a fair number of warnings when configuring with no-ui:
> 
> apps/enc.c:357:13: warning: implicit declaration of function
> ‘EVP_read_pw_string’ [-Wimplicit-function-declaration]
>  i = EVP_read_pw_string((char *)strbuf, SIZE, prompt, enc);
> 
> There's a few link problems, too:
> 
> LD_LIBRARY_PATH=.: gcc -DDSO_DLFCN -DHAVE_DLFCN_H
> -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC
> -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines"
> -Wall -O3 -m64 -DL_ENDIAN -ansi -o apps/openssl apps/app_rand.o
> apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o
> apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o
> apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o
> apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o
> apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o
> apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o
> apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o
> apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o
> apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o
> apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o
> apps/x509.o -L. -lssl -L. -lcrypto -ldl
> apps/apps.o: In function `ui_close':
> apps.c:(.text+0x15): undefined reference to `UI_OpenSSL'
> apps.c:(.text+0x1d): undefined reference to `UI_method_get_closer'
> apps/apps.o: In function `ui_write':
> apps.c:(.text+0x40): undefined reference to `UI_get_input_flags'
> apps.c:(.text+0x4c): undefined reference to `UI_get0_user_data'
> apps.c:(.text+0x59): undefined reference to `UI_get_string_type'
> apps.c:(.text+0x66): undefined reference to `UI_OpenSSL'
> apps.c:(.text+0x6e): undefined reference to `UI_method_get_writer'
> apps.c:(.text+0x84): undefined reference to `UI_get0_user_data'
> apps/apps.o: In function `ui_read':
> apps.c:(.text+0xc0): undefined reference to `UI_get_input_flags'
> apps.c:(.text+0xcc): undefined reference to `UI_get0_user_data'
> apps.c:(.text+0xd9): undefined reference to `UI_get_string_type'
> apps.c:(.text+0xe6): undefined reference to `UI_OpenSSL'
> apps.c:(.text+0xee): undefined reference to `UI_method_get_reader'
> apps.c:(.text+0x104): undefined reference to `UI_get0_user_data'
> apps.c:(.text+0x11c): undefined reference to `UI_set_result'
> apps/apps.o: In function `ui_open':
> apps.c:(.text+0x135): undefined reference to `UI_OpenSSL'
> apps.c:(.text+0x13d): undefined reference to `UI_method_get_opener'
> apps/apps.o: In function `password_callback':
> apps.c:(.text+0xca3): undefined reference to `UI_new_method'
> apps.c:(.text+0xcbf): undefined reference to `UI_construct_prompt'
> apps.c:(.text+0xce2): undefined reference to `UI_ctrl'
> apps.c:(.text+0xd05): undefined reference to `UI_add_input_string'
> apps.c:(.text+0xd38): undefined reference to `UI_ctrl'
> apps.c:(.text+0xd44): undefined reference to `UI_process'
> apps.c:(.text+0xd72): undefined reference to `UI_free'
> apps.c:(.text+0xe5e): undefined reference to `UI_add_verify_string'
> apps.c:(.text+0xe81): undefined reference to `UI_free'
> apps/apps.o: In function `setup_ui_method':
> apps.c:(.text+0x11da): undefined reference to `UI_create_method'
> apps.c:(.text+0x11ee): undefined reference to `UI_method_set_opener'
> apps.c:(.text+0x11ff): undefined reference to `UI_method_set_reader'
> apps.c:(.text+0x1210): undefined reference to `UI_method_set_writer'
> apps.c:(.text+0x1221): undefined reference to `UI_method_set_closer'
> apps/apps.o: In function `destroy_ui_method':
> apps.c:(.text+0x1241): undefined reference to `UI_destroy_method'
> apps/enc.o: In function `enc_main':
> enc.c:(.text+0xfbf): undefined reference to `EVP_read_pw_string'
> enc.c:(.text+0x10f7): undefined reference to `EVP_read_pw_string'
> apps/pkcs12.o: In function `pkcs12_main':
> pkcs12.c:(.text+0x119a): undefined reference to `EVP_read_pw_string'
> pkcs12.c:(.text+0x1733): undefined reference to `EVP_read_pw_string'
> pkcs12.c:(.text+0x17d8): undefined reference to `EVP_read_pw_string'
> apps/pkcs8.o:pkcs8.c:(.text+0x7e0): more undefined references to
> `EVP_read_pw_string' follow
> ./libcrypto.a(err_all.o): In function `err_load_crypto_strings_intern':
> err_all.c:(.text+0x86): undefined reference to `ERR_load_UI_strings'
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.0.1t ?

[Matt Caswell]

On 23/03/16 16:00, Suarez, Miguel wrote:
> Hi
> 
>  
> 
> Can you tell me when 1.0.1t release or later will be made available with
> fixes for the following issues (see below).

1.0.1t does not currently have a planned release date. Releases are
scheduled on an as-needed basis, typically (although not always) as a
result of security defects being discovered. We normally only announce a
release date for security fixes a few days in advance.

Matt

> 
> Disabling  SSLv2 in a default build will break applications we have
> released that depended on SSLv2 by default like release 2.2.29 of
> Apache’s httpd.
> 
> We can change our SSL build but would rather have fixes in an official
> release.
> 
>  
> 
> Thanks.
> 
>  
> 
> https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=CHANGES;h=d4e9887370c8733885851625a72301bc90275b2d;hb=refs/heads/OpenSSL_1_0_1-stable#l5
> 
>  
> 
>2  OpenSSL CHANGES
> 
>3  ___
> 
>4
> 
>5  Changes between 1.0.1s and 1.0.1t [xx XXX ]
> 
>6
> 
>7   *) Remove LOW from the DEFAULT cipher list.  This removes singles
> DES from the
> 
>8  default.
> 
>9  [Kurt Roeckx]
> 
>   10
> 
>   11   *) Only remove the SSLv2 methods with the no-ssl2-method option.
> When the
> 
>   12  methods are enabled and ssl2 is disabled the methods return NULL.
> 
>   13  [Kurt Roeckx]
> 
> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4437] invalid free() by ENGINE_cleanup()

[Matt Caswell via RT]

On 17/03/16 10:49, Daniel Stenberg via RT wrote:
> Hey,
> 
> In curl we call ENGINE_cleanup() as part of our OpenSSL specific cleanup 
> function. When I do this with OpenSSL from git master as of right now 
> (OpenSSL_1_1_0-pre4-7-ga717738) valgrind catches an illegal free:

Auto deinit automatically calls ENGINE_cleanup() so there is no need to
call it explicitly. The bug here is that ENGINE_cleanup() should really
be a no-op and deprecated in 1.1.0 to prevent double frees occuring.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4437
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 #4434] Gentoo 13, x86_64: 4 failed self tests

[Matt Caswell]

What happens if you run the afalgtest directly?

$ cd test
$ ./afalgtest


Matt

On 16/03/16 13:52, noloa...@gmail.com via RT wrote:
> Working from Master on a Gentoo 13 machine, x86_64. The test was run
> as root which explains one of the failures (I don't have users or SSH
> set up yet).
> 
> Kernel is 4.1.15, GCC is 4.9.3.
> 
> $ make test
> ...
> 
> ( cd test; \
>   SRCTOP=../. \
>   BLDTOP=../. \
>   EXE_EXT= \
> /usr/bin/perl .././test/run_tests.pl  )
> ../test/recipes/01-test_ordinals.t  ok
> ../test/recipes/05-test_bf.t .. ok
> ../test/recipes/05-test_cast.t  ok
> ../test/recipes/05-test_des.t . ok
> ../test/recipes/05-test_hmac.t  ok
> ../test/recipes/05-test_idea.t  ok
> ../test/recipes/05-test_md2.t . skipped: md2 is not
> supported by this OpenSSL build
> ../test/recipes/05-test_md4.t . ok
> ../test/recipes/05-test_md5.t . ok
> ../test/recipes/05-test_mdc2.t  ok
> ../test/recipes/05-test_rand.t  ok
> ../test/recipes/05-test_rc2.t . ok
> ../test/recipes/05-test_rc4.t . ok
> ../test/recipes/05-test_rc5.t . skipped: rc5 is not
> supported by this OpenSSL build
> ../test/recipes/05-test_rmd.t . ok
> ../test/recipes/05-test_sha1.t  ok
> ../test/recipes/05-test_sha256.t .. ok
> ../test/recipes/05-test_sha512.t .. ok
> ../test/recipes/05-test_wp.t .. ok
> ../test/recipes/10-test_bn.t .. ok
> ../test/recipes/10-test_exp.t . ok
> ../test/recipes/15-test_dh.t .. ok
> ../test/recipes/15-test_dsa.t . ok
> ../test/recipes/15-test_ec.t .. ok
> ../test/recipes/15-test_ecdh.t  ok
> ../test/recipes/15-test_ecdsa.t ... ok
> ../test/recipes/15-test_rsa.t . ok
> ../test/recipes/20-test_enc.t . ok
> ../test/recipes/25-test_crl.t . ok
> ../test/recipes/25-test_gen.t . ok
> ../test/recipes/25-test_pkcs7.t ... ok
> ../test/recipes/25-test_req.t . ok
> ../test/recipes/25-test_sid.t . ok
> ../test/recipes/25-test_verify.t .. ok
> ../test/recipes/25-test_x509.t  ok
> 
> #   Failed test 'running afalgtest'
> #   at ../test/recipes/30-test_afalg.t line 68.
> # Looks like you failed 1 test of 1.
> ../test/recipes/30-test_afalg.t ...
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/1 subtests
> ../test/recipes/30-test_engine.t .. ok
> ../test/recipes/30-test_evp.t . ok
> ../test/recipes/30-test_evp_extra.t ... ok
> ../test/recipes/30-test_pbelu.t ... ok
> 
> #   Failed test 'Testing that we aren't running as a privileged user,
> such as root'
> #   at ../test/recipes/40-test_rehash.t line 41.
> # Looks like you failed 1 test of 5.
> ../test/recipes/40-test_rehash.t ..
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/5 subtests
> (less 1 skipped subtest: 3 okay)
> ../test/recipes/70-test_clienthello.t . ok
> ../test/recipes/70-test_packet.t .. ok
> ../test/recipes/70-test_sslcertstatus.t ... skipped:
> test_sslcertstatus needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslextension.t  skipped: test_sslextension
> needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslsessiontick.t .. skipped:
> test_sslsessiontick needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslskewith0p.t  skipped: test_sslskewith0p
> needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslvertol.t ... skipped: test_sslextension
> needs the dynamic engine feature enabled
> ../test/recipes/70-test_tlsextms.t  skipped: test_tlsextms
> needs the dynamic engine feature enabled
> ../test/recipes/70-test_verify_extra.t  ok
> ../test/recipes/80-test_ca.t .. ok
> ../test/recipes/80-test_cms.t . ok
> ../test/recipes/80-test_ct.t .. ok
> ../test/recipes/80-test_dane.t  ok
> ../test/recipes/80-test_dtlsv1listen.t  ok
> ../test/recipes/80-test_ocsp.t  ok
> ../test/recipes/80-test_ssl.t . ok
> ../test/recipes/80-test_tsa.t . ok
> ../test/recipes/90-test_async.t ... ok
> ../test/recipes/90-test_constant_time.t ... ok
> ../test/recipes/90-test_gmdiff.t .. ok
> ../test/recipes/90-test_heartbeat.t ... skipped: heartbeats is not
> supported by this OpenSSL build
> ../test/recipes/90-test_ige.t . ok
> ../test/recipes/90-test_memleak.t . ok
> ../test/recipes/90-test_networking.t .. skipped: test_networking
> needs the dynamic engine feature enabled
> ../test/recipes/90-test_np.t .. ok
> ../test/recipes/90-test_p5_crpt2.t  ok
> ../test/recipes/90-test_secmem.t .. ok
> ../test/recipes/90-test_srp.t . ok
> ../test/recipes/90-test_threads.t . 

Re: [openssl-dev] [openssl.org #4445] Configure does not honor enable-afalgeng

[Matt Caswell via RT]

On 18/03/16 12:52, noloa...@gmail.com via RT wrote:
> I've configured with:
> 
> ./config enable-afalgeng
> 
> When I run the self tests, I see:
> 
>   ../test/recipes/30-test_afalg.t ... skipped: test_afalg not
> supported for this build

You should not need to use enable-afalgeng at all. It is enabled by
default unless for some reason it is not supported by your system.
Reasons that it might not be supported:

- You are not running Linux
- You are not building "shared" or have otherwise disabled dynamic-engines
- uname reports a kernel version less than 4.1.0
- Your linux headers are less than 4.1.0

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4445
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 #4445] Configure does not honor enable-afalgeng

[Matt Caswell via RT]

On 18/03/16 22:59, Kurt Roeckx via RT wrote:
> On Fri, Mar 18, 2016 at 01:18:04PM +0000, Matt Caswell wrote:
>>
>>
>> On 18/03/16 12:52, noloa...@gmail.com via RT wrote:
>>> I've configured with:
>>>
>>> ./config enable-afalgeng
>>>
>>> When I run the self tests, I see:
>>>
>>>   ../test/recipes/30-test_afalg.t ... skipped: test_afalg not
>>> supported for this build
>>
>> You should not need to use enable-afalgeng at all. It is enabled by
>> default unless for some reason it is not supported by your system.
>> Reasons that it might not be supported:
>>
>> - You are not running Linux
>> - You are not building "shared" or have otherwise disabled dynamic-engines
>> - uname reports a kernel version less than 4.1.0
>> - Your linux headers are less than 4.1.0
> 
> Please note that the kernel something is build on might not be the
> same as it's going to run on, so checking the current running
> kernel version doesn't make sense for compiling it.  Is there some
> runtime detection of support in the kernel?

Yes. There is runtime detection too.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4445
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 #4445] Configure does not honor enable-afalgeng

[Matt Caswell]

On 18/03/16 22:59, Kurt Roeckx via RT wrote:
> On Fri, Mar 18, 2016 at 01:18:04PM +0000, Matt Caswell wrote:
>>
>>
>> On 18/03/16 12:52, noloa...@gmail.com via RT wrote:
>>> I've configured with:
>>>
>>> ./config enable-afalgeng
>>>
>>> When I run the self tests, I see:
>>>
>>>   ../test/recipes/30-test_afalg.t ... skipped: test_afalg not
>>> supported for this build
>>
>> You should not need to use enable-afalgeng at all. It is enabled by
>> default unless for some reason it is not supported by your system.
>> Reasons that it might not be supported:
>>
>> - You are not running Linux
>> - You are not building "shared" or have otherwise disabled dynamic-engines
>> - uname reports a kernel version less than 4.1.0
>> - Your linux headers are less than 4.1.0
> 
> Please note that the kernel something is build on might not be the
> same as it's going to run on, so checking the current running
> kernel version doesn't make sense for compiling it.  Is there some
> runtime detection of support in the kernel?

Yes. There is runtime detection too.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] configure results in conflicting CRT switches for win DLL

[Matt Caswell]

On 17/03/16 09:56, Michel wrote:
> Hello again Richard,
> 
> And thanks for your help and answers.
> but as I said, I am not lucky at all :-(
> 
> Hope I am not again missing something, I would not be particularly proud to
> win the trophy of the dumbest user on this list ;-) 
> 
> Doing :
> PERL Configure no-rc2 no-rc5 no-md2 no-md4 no-ssl3 no-comp no-hw
> no-heartbeats no-deprecated VC-WIN32 shared --prefix=c:\OpenSSL_DLL
> nmake

Looks like some of these options are broken on Windows. Try the attached
patch.

Matt

>From 17c7e8a4c421ff42450ed76cf9894a00c3f76c47 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Thu, 17 Mar 2016 10:14:30 +
Subject: [PATCH 1/3] Fix no-rc2 in the CMS test

The CMS test uses some RC2 keys which should be skipped if the RC2 is
disabled.
---
 test/recipes/80-test_cms.t | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/test/recipes/80-test_cms.t b/test/recipes/80-test_cms.t
index e372271..2ce8a2c 100644
--- a/test/recipes/80-test_cms.t
+++ b/test/recipes/80-test_cms.t
@@ -13,7 +13,8 @@ setup("test_cms");
 
 my $smdir= srctop_dir("test", "smime-certs");
 my $smcont   = srctop_file("test", "smcont.txt");
-my ($no_dh, $no_ec, $no_ec2m, $no_zlib) = disabled qw/dh ec ec2m zlib/;
+my ($no_dh, $no_ec, $no_ec2m, $no_rc2, $no_zlib)
+= disabled qw/dh ec ec2m rc2 zlib/;
 
 plan tests => 4;
 
@@ -465,12 +466,15 @@ sub check_availability {
 my $tnam = shift;
 
 return "$tnam: skipped, EC disabled\n"
-	if ($no_ec && $tnam =~ /ECDH/);
+if ($no_ec && $tnam =~ /ECDH/);
 return "$tnam: skipped, ECDH disabled\n"
-	if ($no_ec && $tnam =~ /ECDH/);
+if ($no_ec && $tnam =~ /ECDH/);
 return "$tnam: skipped, EC2M disabled\n"
-	if ($no_ec2m && $tnam =~ /K-283/);
+if ($no_ec2m && $tnam =~ /K-283/);
 return "$tnam: skipped, DH disabled\n"
-	if ($no_dh && $tnam =~ /X9\.42/);
+if ($no_dh && $tnam =~ /X9\.42/);
+return "$tnam: skipped, RC2 disabled\n"
+if ($no_rc2 && $tnam =~ /RC2/);
+
 return "";
 }
-- 
2.5.0


>From 6c5f2b5b95d150210ca4bc8fba2447b52ff18ff6 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Thu, 17 Mar 2016 11:50:23 +
Subject: [PATCH 2/3] Ensure that no-comp functions are flagged as such

mkdef.pl was not detecting no-comp functions. This updates the header file
so that mkdef.pl detects that no-comp applies, and the functions are marked
accordingly.
---
 crypto/init.c  |  2 ++
 include/openssl/comp.h |  4 
 include/openssl/ssl.h  |  2 ++
 util/libcrypto.num | 24 
 4 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/crypto/init.c b/crypto/init.c
index 8c59989..fad7a85 100644
--- a/crypto/init.c
+++ b/crypto/init.c
@@ -66,7 +66,9 @@
 #ifndef OPENSSL_NO_ENGINE
 #include 
 #endif
+#ifndef OPENSSL_NO_COMP
 #include 
+#endif
 #include 
 #include 
 #include 
diff --git a/include/openssl/comp.h b/include/openssl/comp.h
index c7d903f..de16a9f 100644
--- a/include/openssl/comp.h
+++ b/include/openssl/comp.h
@@ -58,6 +58,10 @@
 
 # include 
 
+# ifdef OPENSSL_NO_COMP
+#  error COMP is disabled.
+# endif
+
 #ifdef  __cplusplus
 extern "C" {
 #endif
diff --git a/include/openssl/ssl.h b/include/openssl/ssl.h
index e19a791..c4ab26d 100644
--- a/include/openssl/ssl.h
+++ b/include/openssl/ssl.h
@@ -145,7 +145,9 @@
 # include 
 # include 
 
+#ifndef OPENSSL_NO_COMP
 # include 
+#endif
 # include 
 # if OPENSSL_API_COMPAT < 0x1010L
 #  include 
diff --git a/util/libcrypto.num b/util/libcrypto.num
index 7a86ac8..ddaf270 100644
--- a/util/libcrypto.num
+++ b/util/libcrypto.num
@@ -2,7 +2,7 @@ d2i_EC_PUBKEY   1	1_1_0	EXIST::FUNCTION:EC
 b2i_PVK_bio 2	1_1_0	EXIST::FUNCTION:RC4
 PEM_read_bio_NETSCAPE_CERT_SEQUENCE 3	1_1_0	EXIST::FUNCTION:
 X509_STORE_CTX_get_chain4	1_1_0	EXIST::FUNCTION:
-COMP_expand_block   5	1_1_0	EXIST::FUNCTION:
+COMP_expand_block   5	1_1_0	EXIST::FUNCTION:COMP
 X509V3_get_string   6	1_1_0	EXIST::FUNCTION:
 TS_MSG_IMPRINT_free 7	1_1_0	EXIST::FUNCTION:
 DES_xcbc_encrypt8	1_1_0	EXIST::FUNCTION:DES
@@ -843,7 +843,7 @@ i2d_ASN1_UTF8STRING 822	1_1_0	EXIST::FUNCTION:
 TS_REQ_delete_ext   823	1_1_0	EXIST::FUNCTION:
 PKCS7_DIGEST_free   824	1_1_0	EXIST::FUNCTION:
 OBJ_nid2ln  825	1_1_0	EXIST::FUNCTION:
-COMP_CTX_new826	1_1_0	EXIST::FUNCTION:
+COMP_CTX_new826	1_1_0	EXIST::FUNCTION:COMP
 BIO_ADDR_family 827	1_1_0	EXIST::FUNCTION:
 OCSP_RESPONSE_i

Re: [openssl-dev] [openssl.org #4445] Configure does not honor enable-afalgeng

[Matt Caswell]

On 18/03/16 12:52, noloa...@gmail.com via RT wrote:
> I've configured with:
> 
> ./config enable-afalgeng
> 
> When I run the self tests, I see:
> 
>   ../test/recipes/30-test_afalg.t ... skipped: test_afalg not
> supported for this build

You should not need to use enable-afalgeng at all. It is enabled by
default unless for some reason it is not supported by your system.
Reasons that it might not be supported:

- You are not running Linux
- You are not building "shared" or have otherwise disabled dynamic-engines
- uname reports a kernel version less than 4.1.0
- Your linux headers are less than 4.1.0

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] libcryto 1.1 leaks since old locks are removed

[Matt Caswell]

FYI, I have a fix for this but it is currently stalled in review due to
another related issue. Interim patch attached.

Matt


On 16/03/16 22:11, Michel wrote:
> Hi,
> 
>  
> 
> As in my previous post, libcrypto still leaks with OpenSSL version 1.1.0
> pre release 4.
> 
> Here is an example with the same test program that was running fine
> before I removed the old locking “stuff”.
> 
>  
> 
> Detected memory leaks!
> 
> Dumping objects ->
> 
> {1418} normal block at 0x0064EF98, 24 bytes long.
> 
> Data: <  d > 98 1F 64 00 FF FF FF FF 00 00 00 00 00 00 00 00
> 
> {703} normal block at 0x00641E40, 24 bytes long.
> 
> Data:  78 1E 64 00 FF FF FF FF 00 00 00 00 00 00 00 00
> 
> Object dump complete.
> 
> Debug Error!
> 
>  
> 
> -- Block 703 at 0x00641E40: 24 bytes --
> 
>   Leak Hash: 0x95EDDA21, Count: 1, Total 24 bytes
> 
>   Call Stack (TID 7140):
> 
> ntdll.dll!RtlAllocateHeap()
> 
> f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56):
> TestsTLS-11.exe!malloc() + 0x15 bytes
> 
> e:\openssl-1.1.0-pre4\crypto\mem.c (140):
> TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes
> 
> e:\openssl-1.1.0-pre4\crypto\mem.c (148):
> TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes
> 
> e:\openssl-1.1.0-pre4\crypto\threads_win.c (57):
> TestsTLS-11.exe!CRYPTO_THREAD_lock_new() + 0xE bytes
> 
> e:\openssl-1.1.0-pre4\crypto\err\err.c (393):
> TestsTLS-11.exe!do_err_strings_init() + 0x5 bytes
> 
> e:\openssl-1.1.0-pre4\crypto\threads_win.c (117):
> TestsTLS-11.exe!CRYPTO_THREAD_run_once()
> 
> e:\openssl-1.1.0-pre4\crypto\err\err.c (711):
> TestsTLS-11.exe!ERR_func_error_string() + 0xF bytes
> 
> e:\openssl-1.1.0-pre4\ssl\ssl_err.c (716):
> TestsTLS-11.exe!ERR_load_SSL_strings() + 0x14 bytes
> 
> e:\openssl-1.1.0-pre4\ssl\ssl_init.c (180):
> TestsTLS-11.exe!ossl_init_load_ssl_strings()
> 
> e:\openssl-1.1.0-pre4\crypto\threads_win.c (117):
> TestsTLS-11.exe!CRYPTO_THREAD_run_once()
> 
> e:\openssl-1.1.0-pre4\ssl\ssl_init.c (258):
> TestsTLS-11.exe!OPENSSL_init_ssl() + 0x2B bytes
> 
> e:\openssl-1.1.0-pre4\ssl\ssl_lib.c (2359):
> TestsTLS-11.exe!SSL_CTX_new() + 0xE bytes
> 
> p:\mes programmes\shared\ocrypto-11\tls.cpp (95):
> TestsTLS-11.exe!OTLS::TLSCtx::SetMinTLSVer() + 0x9 bytes
> 
> p:\mes programmes\tests\_testsshared\teststls-11\testtls.cpp (63):
> TestsTLS-11.exe!main() + 0xC bytes
> 
> f:\dd\vctools\crt\crtw32\startup\crt0.c (165):
> TestsTLS-11.exe!mainCRTStartup()
> 
>  
> 
> -- Block 1418 at 0x0064EF98: 24 bytes --
> 
>   Leak Hash: 0x9FBB4D3C, Count: 1, Total 24 bytes
> 
>   Call Stack (TID 7140):
> 
> ntdll.dll!RtlAllocateHeap()
> 
> f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56):
> TestsTLS-11.exe!malloc() + 0x15 bytes
> 
> e:\openssl-1.1.0-pre4\crypto\mem.c (140):
> TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes
> 
> e:\openssl-1.1.0-pre4\crypto\mem.c (148):
> TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes
> 
> e:\openssl-1.1.0-pre4\crypto\threads_win.c (57):
> TestsTLS-11.exe!CRYPTO_THREAD_lock_new() + 0xE bytes
> 
> e:\openssl-1.1.0-pre4\crypto\ex_data.c (143):
> TestsTLS-11.exe!do_ex_data_init() + 0x5 bytes
> 
> e:\openssl-1.1.0-pre4\crypto\threads_win.c (117):
> TestsTLS-11.exe!CRYPTO_THREAD_run_once()
> 
> e:\openssl-1.1.0-pre4\crypto\ex_data.c (160):
> TestsTLS-11.exe!get_and_lock() + 0xF bytes
> 
> e:\openssl-1.1.0-pre4\crypto\ex_data.c (243):
> TestsTLS-11.exe!CRYPTO_get_ex_new_index() + 0x9 bytes
> 
> e:\openssl-1.1.0-pre4\ssl\ssl_cert.c (146):
> TestsTLS-11.exe!ssl_x509_store_ctx_init() + 0x14 bytes
> 
> e:\openssl-1.1.0-pre4\crypto\threads_win.c (117):
> TestsTLS-11.exe!CRYPTO_THREAD_run_once()
> 
> e:\openssl-1.1.0-pre4\ssl\ssl_cert.c (152):
> TestsTLS-11.exe!SSL_get_ex_data_X509_STORE_CTX_idx() + 0xF bytes
> 
> e:\openssl-1.1.0-pre4\ssl\ssl_lib.c (2367):
> TestsTLS-11.exe!SSL_CTX_new() + 0x5 bytes
> 
> p:\mes programmes\shared\ocrypto-11\tls.cpp (95):
> TestsTLS-11.exe!OTLS::TLSCtx::SetMinTLSVer() + 0x9 bytes
> 
> p:\mes programmes\tests\_testsshared\teststls-11\testtls.cpp (63):
> TestsTLS-11.exe!main() + 0xC bytes
> 
> f:\dd\vctools\crt\crtw32\startup\crt0.c (165):
> TestsTLS-11.exe!mainCRTStartup()
> 
>  
> 
> Regards,
> 
>  
> 
> Michel
> 
>  
> 
> 
> 
From 33eae4591fec8bfa08a150e4342b1ae813fe4143 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Fri, 11 Mar 2016 21:53:18 +
Subject: [PATCH] Ensure all locks are properly cleaned up

Some locks were not being properly cleaned up during 

Re: [openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests

[Matt Caswell via RT]

What happens if you run the afalgtest directly?

$ cd test
$ ./afalgtest


Matt

On 16/03/16 13:52, noloa...@gmail.com via RT wrote:
> Working from Master on a Gentoo 13 machine, x86_64. The test was run
> as root which explains one of the failures (I don't have users or SSH
> set up yet).
> 
> Kernel is 4.1.15, GCC is 4.9.3.
> 
> $ make test
> ...
> 
> ( cd test; \
>   SRCTOP=../. \
>   BLDTOP=../. \
>   EXE_EXT= \
> /usr/bin/perl .././test/run_tests.pl  )
> ../test/recipes/01-test_ordinals.t  ok
> ../test/recipes/05-test_bf.t .. ok
> ../test/recipes/05-test_cast.t  ok
> ../test/recipes/05-test_des.t . ok
> ../test/recipes/05-test_hmac.t  ok
> ../test/recipes/05-test_idea.t  ok
> ../test/recipes/05-test_md2.t . skipped: md2 is not
> supported by this OpenSSL build
> ../test/recipes/05-test_md4.t . ok
> ../test/recipes/05-test_md5.t . ok
> ../test/recipes/05-test_mdc2.t  ok
> ../test/recipes/05-test_rand.t  ok
> ../test/recipes/05-test_rc2.t . ok
> ../test/recipes/05-test_rc4.t . ok
> ../test/recipes/05-test_rc5.t . skipped: rc5 is not
> supported by this OpenSSL build
> ../test/recipes/05-test_rmd.t . ok
> ../test/recipes/05-test_sha1.t  ok
> ../test/recipes/05-test_sha256.t .. ok
> ../test/recipes/05-test_sha512.t .. ok
> ../test/recipes/05-test_wp.t .. ok
> ../test/recipes/10-test_bn.t .. ok
> ../test/recipes/10-test_exp.t . ok
> ../test/recipes/15-test_dh.t .. ok
> ../test/recipes/15-test_dsa.t . ok
> ../test/recipes/15-test_ec.t .. ok
> ../test/recipes/15-test_ecdh.t  ok
> ../test/recipes/15-test_ecdsa.t ... ok
> ../test/recipes/15-test_rsa.t . ok
> ../test/recipes/20-test_enc.t . ok
> ../test/recipes/25-test_crl.t . ok
> ../test/recipes/25-test_gen.t . ok
> ../test/recipes/25-test_pkcs7.t ... ok
> ../test/recipes/25-test_req.t . ok
> ../test/recipes/25-test_sid.t . ok
> ../test/recipes/25-test_verify.t .. ok
> ../test/recipes/25-test_x509.t  ok
> 
> #   Failed test 'running afalgtest'
> #   at ../test/recipes/30-test_afalg.t line 68.
> # Looks like you failed 1 test of 1.
> ../test/recipes/30-test_afalg.t ...
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/1 subtests
> ../test/recipes/30-test_engine.t .. ok
> ../test/recipes/30-test_evp.t . ok
> ../test/recipes/30-test_evp_extra.t ... ok
> ../test/recipes/30-test_pbelu.t ... ok
> 
> #   Failed test 'Testing that we aren't running as a privileged user,
> such as root'
> #   at ../test/recipes/40-test_rehash.t line 41.
> # Looks like you failed 1 test of 5.
> ../test/recipes/40-test_rehash.t ..
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/5 subtests
> (less 1 skipped subtest: 3 okay)
> ../test/recipes/70-test_clienthello.t . ok
> ../test/recipes/70-test_packet.t .. ok
> ../test/recipes/70-test_sslcertstatus.t ... skipped:
> test_sslcertstatus needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslextension.t  skipped: test_sslextension
> needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslsessiontick.t .. skipped:
> test_sslsessiontick needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslskewith0p.t  skipped: test_sslskewith0p
> needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslvertol.t ... skipped: test_sslextension
> needs the dynamic engine feature enabled
> ../test/recipes/70-test_tlsextms.t  skipped: test_tlsextms
> needs the dynamic engine feature enabled
> ../test/recipes/70-test_verify_extra.t  ok
> ../test/recipes/80-test_ca.t .. ok
> ../test/recipes/80-test_cms.t . ok
> ../test/recipes/80-test_ct.t .. ok
> ../test/recipes/80-test_dane.t  ok
> ../test/recipes/80-test_dtlsv1listen.t  ok
> ../test/recipes/80-test_ocsp.t  ok
> ../test/recipes/80-test_ssl.t . ok
> ../test/recipes/80-test_tsa.t . ok
> ../test/recipes/90-test_async.t ... ok
> ../test/recipes/90-test_constant_time.t ... ok
> ../test/recipes/90-test_gmdiff.t .. ok
> ../test/recipes/90-test_heartbeat.t ... skipped: heartbeats is not
> supported by this OpenSSL build
> ../test/recipes/90-test_ige.t . ok
> ../test/recipes/90-test_memleak.t . ok
> ../test/recipes/90-test_networking.t .. skipped: test_networking
> needs the dynamic engine feature enabled
> ../test/recipes/90-test_np.t .. ok
> ../test/recipes/90-test_p5_crpt2.t  ok
> ../test/recipes/90-test_secmem.t .. ok
> ../test/recipes/90-test_srp.t . ok
> ../test/recipes/90-test_threads.t . 

Re: [openssl-dev] [openssl.org #4437] invalid free() by ENGINE_cleanup()

[Matt Caswell]

On 17/03/16 10:49, Daniel Stenberg via RT wrote:
> Hey,
> 
> In curl we call ENGINE_cleanup() as part of our OpenSSL specific cleanup 
> function. When I do this with OpenSSL from git master as of right now 
> (OpenSSL_1_1_0-pre4-7-ga717738) valgrind catches an illegal free:

Auto deinit automatically calls ENGINE_cleanup() so there is no need to
call it explicitly. The bug here is that ENGINE_cleanup() should really
be a no-op and deprecated in 1.1.0 to prevent double frees occuring.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

[Matt Caswell via RT]

On 14/03/16 15:21, Matt Caswell via RT wrote:
> 
> 
> On 14/03/16 15:05, Andy Polyakov via RT wrote:
>>>>> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
>>>>> 32-bit tests OK.
>>>>>
>>>>> The relevant snippets are:
>>>>>
>>>>> $ make test
>>>>> ...
>>>>> ../test/recipes/90-test_async.t ... 1/1
>>>>> #   Failed test 'running asynctest'
>>>>> #   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
>>>>> # Looks like you failed 1 test of 1.
>>>>> ../test/recipes/90-test_async.t ... Dubious, test returned 1
>>>>> (wstat 256, 0x100)
>>>>> Failed 1/1 subtests
>>>>
>>>> Once again, "it boils down to the fact that getcontext always returns
>>>> failure to ppc64 program. There is nothing we can do about it, you just
>>>> have to accept that this particular thing doesn't work on MacOS
>>>> X/ppc64." getcontext is part of libc equivalent, which is why there is
>>>> nothing that can be done about it.
>>>>
>>>>
>>> Can we detect the platform in async_posix.h so that if we work out we're
>>> on ppc64 then we default to ASYNC_NULL?
>>
>> #if defined(__APPLE__) && (defined(__ppc64__) || defined(_ARCH_PPC64))
>>
>>
> So something like the attached?
> 
> Jeff, can you test this?

Jeff reported to me off list that this did not work.

Jeff - please can you try the attached alternative patch?

Thanks

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4366
Please log in as guest with password guest if prompted

>From d81d6f1d7b9bb9497e0661eacc616d35755fa24b Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Wed, 16 Mar 2016 10:38:39 +
Subject: [PATCH] Some platforms provide getcontext() but it does not work

Some platforms claim to be POSIX but their getcontext() implementation
does not work. Therefore we update the ASYNC_is_capable() function to test
for this.
---
 crypto/async/arch/async_posix.c |  8 +++-
 test/asynctest.c| 45 +
 2 files changed, 21 insertions(+), 32 deletions(-)

diff --git a/crypto/async/arch/async_posix.c b/crypto/async/arch/async_posix.c
index 2d9e510..b0975c3 100644
--- a/crypto/async/arch/async_posix.c
+++ b/crypto/async/arch/async_posix.c
@@ -62,7 +62,13 @@
 
 int ASYNC_is_capable(void)
 {
-return 1;
+ucontext_t ctx;
+
+/*
+ * Some platforms provide getcontext() but it does not work. Check for
+ * a working getcontext();
+ */
+return getcontext(&ctx) == 0;
 }
 
 void async_local_cleanup(void)
diff --git a/test/asynctest.c b/test/asynctest.c
index 31f04e9..4694fda 100644
--- a/test/asynctest.c
+++ b/test/asynctest.c
@@ -61,21 +61,6 @@
 #include 
 #include <../apps/apps.h>
 
-#if (defined(OPENSSL_SYS_UNIX) || defined(OPENSSL_SYS_CYGWIN)) && defined(OPENSSL_THREADS)
-# include 
-# if _POSIX_VERSION >= 200112L
-#  define ASYNC_POSIX
-# endif
-#elif defined(_WIN32)
-# define ASYNC_WIN
-#endif
-
-#if !defined(ASYNC_POSIX) && !defined(ASYNC_WIN)
-# define ASYNC_NULL
-#endif
-
-#ifndef ASYNC_NULL
-
 static int ctr = 0;
 static ASYNC_JOB *currjob = NULL;
 
@@ -308,25 +293,23 @@ static int test_ASYNC_block_pause()
 return 1;
 }
 
-#endif
-
 int main(int argc, char **argv)
 {
-
-#ifdef ASYNC_NULL
-fprintf(stderr, "NULL implementation - skipping async tests\n");
-#else
-CRYPTO_set_mem_debug(1);
-CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
-
-if (   !test_ASYNC_init_thread()
-|| !test_ASYNC_start_job()
-|| !test_ASYNC_get_current_job()
-|| !test_ASYNC_WAIT_CTX_get_all_fds()
-|| !test_ASYNC_block_pause()) {
-return 1;
+if (!ASYNC_is_capable()) {
+fprintf(stderr,
+"OpenSSL build is not ASYNC capable - skipping async tests\n");
+} else {
+CRYPTO_set_mem_debug(1);
+CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
+
+if (   !test_ASYNC_init_thread()
+|| !test_ASYNC_start_job()
+|| !test_ASYNC_get_current_job()
+|| !test_ASYNC_WAIT_CTX_get_all_fds()
+|| !test_ASYNC_block_pause()) {
+return 1;
+}
 }
-#endif
 printf("PASS\n");
 return 0;
 }
-- 
2.5.0

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

[Matt Caswell]

On 14/03/16 15:21, Matt Caswell via RT wrote:
> 
> 
> On 14/03/16 15:05, Andy Polyakov via RT wrote:
>>>>> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
>>>>> 32-bit tests OK.
>>>>>
>>>>> The relevant snippets are:
>>>>>
>>>>> $ make test
>>>>> ...
>>>>> ../test/recipes/90-test_async.t ... 1/1
>>>>> #   Failed test 'running asynctest'
>>>>> #   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
>>>>> # Looks like you failed 1 test of 1.
>>>>> ../test/recipes/90-test_async.t ... Dubious, test returned 1
>>>>> (wstat 256, 0x100)
>>>>> Failed 1/1 subtests
>>>>
>>>> Once again, "it boils down to the fact that getcontext always returns
>>>> failure to ppc64 program. There is nothing we can do about it, you just
>>>> have to accept that this particular thing doesn't work on MacOS
>>>> X/ppc64." getcontext is part of libc equivalent, which is why there is
>>>> nothing that can be done about it.
>>>>
>>>>
>>> Can we detect the platform in async_posix.h so that if we work out we're
>>> on ppc64 then we default to ASYNC_NULL?
>>
>> #if defined(__APPLE__) && (defined(__ppc64__) || defined(_ARCH_PPC64))
>>
>>
> So something like the attached?
> 
> Jeff, can you test this?

Jeff reported to me off list that this did not work.

Jeff - please can you try the attached alternative patch?

Thanks

Matt

>From d81d6f1d7b9bb9497e0661eacc616d35755fa24b Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Wed, 16 Mar 2016 10:38:39 +
Subject: [PATCH] Some platforms provide getcontext() but it does not work

Some platforms claim to be POSIX but their getcontext() implementation
does not work. Therefore we update the ASYNC_is_capable() function to test
for this.
---
 crypto/async/arch/async_posix.c |  8 +++-
 test/asynctest.c| 45 +
 2 files changed, 21 insertions(+), 32 deletions(-)

diff --git a/crypto/async/arch/async_posix.c b/crypto/async/arch/async_posix.c
index 2d9e510..b0975c3 100644
--- a/crypto/async/arch/async_posix.c
+++ b/crypto/async/arch/async_posix.c
@@ -62,7 +62,13 @@
 
 int ASYNC_is_capable(void)
 {
-return 1;
+ucontext_t ctx;
+
+/*
+ * Some platforms provide getcontext() but it does not work. Check for
+ * a working getcontext();
+ */
+return getcontext(&ctx) == 0;
 }
 
 void async_local_cleanup(void)
diff --git a/test/asynctest.c b/test/asynctest.c
index 31f04e9..4694fda 100644
--- a/test/asynctest.c
+++ b/test/asynctest.c
@@ -61,21 +61,6 @@
 #include 
 #include <../apps/apps.h>
 
-#if (defined(OPENSSL_SYS_UNIX) || defined(OPENSSL_SYS_CYGWIN)) && defined(OPENSSL_THREADS)
-# include 
-# if _POSIX_VERSION >= 200112L
-#  define ASYNC_POSIX
-# endif
-#elif defined(_WIN32)
-# define ASYNC_WIN
-#endif
-
-#if !defined(ASYNC_POSIX) && !defined(ASYNC_WIN)
-# define ASYNC_NULL
-#endif
-
-#ifndef ASYNC_NULL
-
 static int ctr = 0;
 static ASYNC_JOB *currjob = NULL;
 
@@ -308,25 +293,23 @@ static int test_ASYNC_block_pause()
 return 1;
 }
 
-#endif
-
 int main(int argc, char **argv)
 {
-
-#ifdef ASYNC_NULL
-fprintf(stderr, "NULL implementation - skipping async tests\n");
-#else
-CRYPTO_set_mem_debug(1);
-CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
-
-if (   !test_ASYNC_init_thread()
-|| !test_ASYNC_start_job()
-|| !test_ASYNC_get_current_job()
-|| !test_ASYNC_WAIT_CTX_get_all_fds()
-|| !test_ASYNC_block_pause()) {
-return 1;
+if (!ASYNC_is_capable()) {
+fprintf(stderr,
+"OpenSSL build is not ASYNC capable - skipping async tests\n");
+} else {
+CRYPTO_set_mem_debug(1);
+CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
+
+if (   !test_ASYNC_init_thread()
+|| !test_ASYNC_start_job()
+|| !test_ASYNC_get_current_job()
+|| !test_ASYNC_WAIT_CTX_get_all_fds()
+|| !test_ASYNC_block_pause()) {
+return 1;
+}
 }
-#endif
 printf("PASS\n");
 return 0;
 }
-- 
2.5.0

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

[Matt Caswell via RT]

On 14/03/16 15:05, Andy Polyakov via RT wrote:
>>>> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
>>>> 32-bit tests OK.
>>>>
>>>> The relevant snippets are:
>>>>
>>>> $ make test
>>>> ...
>>>> ../test/recipes/90-test_async.t ... 1/1
>>>> #   Failed test 'running asynctest'
>>>> #   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
>>>> # Looks like you failed 1 test of 1.
>>>> ../test/recipes/90-test_async.t ... Dubious, test returned 1
>>>> (wstat 256, 0x100)
>>>> Failed 1/1 subtests
>>>
>>> Once again, "it boils down to the fact that getcontext always returns
>>> failure to ppc64 program. There is nothing we can do about it, you just
>>> have to accept that this particular thing doesn't work on MacOS
>>> X/ppc64." getcontext is part of libc equivalent, which is why there is
>>> nothing that can be done about it.
>>>
>>>
>> Can we detect the platform in async_posix.h so that if we work out we're
>> on ppc64 then we default to ASYNC_NULL?
> 
> #if defined(__APPLE__) && (defined(__ppc64__) || defined(_ARCH_PPC64))
> 
> 
So something like the attached?

Jeff, can you test this?

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4366
Please log in as guest with password guest if prompted

>From e30be0c1c51cc7da06f103a07d6b4b9757838867 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Mon, 14 Mar 2016 15:15:27 +
Subject: [PATCH] Disable ASYNC on MacOSX/ppc64

MacOSX/ppc64 has a getcontext() but it always fails, so if we detect
we're on that platform we should use ASYNC_NULL

RT#4366
---
 crypto/async/arch/async_posix.h | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/crypto/async/arch/async_posix.h b/crypto/async/arch/async_posix.h
index de80f95..edc332d 100644
--- a/crypto/async/arch/async_posix.h
+++ b/crypto/async/arch/async_posix.h
@@ -53,20 +53,25 @@
 #define OPENSSL_ASYNC_ARCH_ASYNC_POSIX_H
 #include 
 
-#if (defined(OPENSSL_SYS_UNIX) || defined(OPENSSL_SYS_CYGWIN)) && defined(OPENSSL_THREADS) && !defined(OPENSSL_NO_ASYNC)
+#if (defined(OPENSSL_SYS_UNIX) || defined(OPENSSL_SYS_CYGWIN)) \
+&& defined(OPENSSL_THREADS) && !defined(OPENSSL_NO_ASYNC)
 
-# include 
+/*  MacOSX/ppc64 has a getcontext() but it always fails */
+# if !defined(__APPLE__) || (!defined(__ppc64__) && !defined(_ARCH_PPC64)) \
+|| !defined(__MACH__)
 
-# if _POSIX_VERSION >= 200112L
+#  include 
 
-# include 
+#  if _POSIX_VERSION >= 200112L
 
-#  define ASYNC_POSIX
-#  define ASYNC_ARCH
+#  include 
 
-#  include 
-#  include 
-#  include "e_os.h"
+#   define ASYNC_POSIX
+#   define ASYNC_ARCH
+
+#   include 
+#   include 
+#   include "e_os.h"
 
 typedef struct async_fibre_st {
 ucontext_t fibre;
@@ -88,11 +93,12 @@ static inline int async_fibre_swapcontext(async_fibre *o, async_fibre *n, int r)
 return 1;
 }
 
-#  define async_fibre_init_dispatcher(d)
+#   define async_fibre_init_dispatcher(d)
 
 int async_fibre_makecontext(async_fibre *fibre);
 void async_fibre_free(async_fibre *fibre);
 
+#  endif
 # endif
 #endif
 #endif /* OPENSSL_ASYNC_ARCH_ASYNC_POSIX_H */
-- 
2.5.0

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

[Matt Caswell]

On 14/03/16 15:05, Andy Polyakov via RT wrote:
>>>> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
>>>> 32-bit tests OK.
>>>>
>>>> The relevant snippets are:
>>>>
>>>> $ make test
>>>> ...
>>>> ../test/recipes/90-test_async.t ... 1/1
>>>> #   Failed test 'running asynctest'
>>>> #   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
>>>> # Looks like you failed 1 test of 1.
>>>> ../test/recipes/90-test_async.t ... Dubious, test returned 1
>>>> (wstat 256, 0x100)
>>>> Failed 1/1 subtests
>>>
>>> Once again, "it boils down to the fact that getcontext always returns
>>> failure to ppc64 program. There is nothing we can do about it, you just
>>> have to accept that this particular thing doesn't work on MacOS
>>> X/ppc64." getcontext is part of libc equivalent, which is why there is
>>> nothing that can be done about it.
>>>
>>>
>> Can we detect the platform in async_posix.h so that if we work out we're
>> on ppc64 then we default to ASYNC_NULL?
> 
> #if defined(__APPLE__) && (defined(__ppc64__) || defined(_ARCH_PPC64))
> 
> 
So something like the attached?

Jeff, can you test this?

Matt
>From e30be0c1c51cc7da06f103a07d6b4b9757838867 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Mon, 14 Mar 2016 15:15:27 +
Subject: [PATCH] Disable ASYNC on MacOSX/ppc64

MacOSX/ppc64 has a getcontext() but it always fails, so if we detect
we're on that platform we should use ASYNC_NULL

RT#4366
---
 crypto/async/arch/async_posix.h | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/crypto/async/arch/async_posix.h b/crypto/async/arch/async_posix.h
index de80f95..edc332d 100644
--- a/crypto/async/arch/async_posix.h
+++ b/crypto/async/arch/async_posix.h
@@ -53,20 +53,25 @@
 #define OPENSSL_ASYNC_ARCH_ASYNC_POSIX_H
 #include 
 
-#if (defined(OPENSSL_SYS_UNIX) || defined(OPENSSL_SYS_CYGWIN)) && defined(OPENSSL_THREADS) && !defined(OPENSSL_NO_ASYNC)
+#if (defined(OPENSSL_SYS_UNIX) || defined(OPENSSL_SYS_CYGWIN)) \
+&& defined(OPENSSL_THREADS) && !defined(OPENSSL_NO_ASYNC)
 
-# include 
+/*  MacOSX/ppc64 has a getcontext() but it always fails */
+# if !defined(__APPLE__) || (!defined(__ppc64__) && !defined(_ARCH_PPC64)) \
+|| !defined(__MACH__)
 
-# if _POSIX_VERSION >= 200112L
+#  include 
 
-# include 
+#  if _POSIX_VERSION >= 200112L
 
-#  define ASYNC_POSIX
-#  define ASYNC_ARCH
+#  include 
 
-#  include 
-#  include 
-#  include "e_os.h"
+#   define ASYNC_POSIX
+#   define ASYNC_ARCH
+
+#   include 
+#   include 
+#   include "e_os.h"
 
 typedef struct async_fibre_st {
 ucontext_t fibre;
@@ -88,11 +93,12 @@ static inline int async_fibre_swapcontext(async_fibre *o, async_fibre *n, int r)
 return 1;
 }
 
-#  define async_fibre_init_dispatcher(d)
+#   define async_fibre_init_dispatcher(d)
 
 int async_fibre_makecontext(async_fibre *fibre);
 void async_fibre_free(async_fibre *fibre);
 
+#  endif
 # endif
 #endif
 #endif /* OPENSSL_ASYNC_ARCH_ASYNC_POSIX_H */
-- 
2.5.0

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

[Matt Caswell]

On 14/03/16 14:57, Andy Polyakov via RT wrote:
>> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
>> 32-bit tests OK.
>>
>> The relevant snippets are:
>>
>> $ make test
>> ...
>> ../test/recipes/90-test_async.t ... 1/1
>> #   Failed test 'running asynctest'
>> #   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
>> # Looks like you failed 1 test of 1.
>> ../test/recipes/90-test_async.t ... Dubious, test returned 1
>> (wstat 256, 0x100)
>> Failed 1/1 subtests
> 
> Once again, "it boils down to the fact that getcontext always returns
> failure to ppc64 program. There is nothing we can do about it, you just
> have to accept that this particular thing doesn't work on MacOS
> X/ppc64." getcontext is part of libc equivalent, which is why there is
> nothing that can be done about it.
> 
> 
Can we detect the platform in async_posix.h so that if we work out we're
on ppc64 then we default to ASYNC_NULL?

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

[Matt Caswell via RT]

On 14/03/16 14:57, Andy Polyakov via RT wrote:
>> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
>> 32-bit tests OK.
>>
>> The relevant snippets are:
>>
>> $ make test
>> ...
>> ../test/recipes/90-test_async.t ... 1/1
>> #   Failed test 'running asynctest'
>> #   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
>> # Looks like you failed 1 test of 1.
>> ../test/recipes/90-test_async.t ... Dubious, test returned 1
>> (wstat 256, 0x100)
>> Failed 1/1 subtests
> 
> Once again, "it boils down to the fact that getcontext always returns
> failure to ppc64 program. There is nothing we can do about it, you just
> have to accept that this particular thing doesn't work on MacOS
> X/ppc64." getcontext is part of libc equivalent, which is why there is
> nothing that can be done about it.
> 
> 
Can we detect the platform in async_posix.h so that if we work out we're
on ppc64 then we default to ASYNC_NULL?

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4366
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 #4411] VIA C7-D processor: Hang in 30-test_afalg.t

[Matt Caswell]

On 12/03/16 00:12, noloa...@gmail.com via RT wrote:
>>> What is actually running? How can I get it under a debugger?
>>
>>
>> $ ./config -d
>> $ make
>> $ make test/afalgtest
>> $ cd test
>> $ OPENSSL_ENGINES=../engines/afalg gdb ./afalgtest
>>
> 
> Ooh, -d looks like a new option. Would that be for Debug builds?

Yes...but its not new.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4411] VIA C7-D processor: Hang in 30-test_afalg.t

[Matt Caswell via RT]

On 11/03/16 19:38, noloa...@gmail.com via RT wrote:
> On Thu, Mar 10, 2016 at 2:29 PM, noloa...@gmail.com via RT
>  wrote:
>> Working from Master:
>>
> 
> It looks like the hang is still present as of 603358d.
> 
> When the following runs:
> 
> ../test/recipes/30-test_afalg.t
> 
> What is actually running? How can I get it under a debugger?


$ ./config -d
$ make
$ make test/afalgtest
$ cd test
$ OPENSSL_ENGINES=../engines/afalg gdb ./afalgtest

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4411
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 #4411] VIA C7-D processor: Hang in 30-test_afalg.t

[Matt Caswell]

On 11/03/16 19:38, noloa...@gmail.com via RT wrote:
> On Thu, Mar 10, 2016 at 2:29 PM, noloa...@gmail.com via RT
>  wrote:
>> Working from Master:
>>
> 
> It looks like the hang is still present as of 603358d.
> 
> When the following runs:
> 
> ../test/recipes/30-test_afalg.t
> 
> What is actually running? How can I get it under a debugger?


$ ./config -d
$ make
$ make test/afalgtest
$ cd test
$ OPENSSL_ENGINES=../engines/afalg gdb ./afalgtest

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4411] VIA C7-D processor: Hang in 30-test_afalg.t

[Matt Caswell via RT]

Hi Jeff

On Thu Mar 10 19:29:21 2016, noloa...@gmail.com wrote:
> Working from Master:
>
> $ git reset --hard HEAD && git pull
> HEAD is now at fb04434 In the recipe using "makedepend", make sure the
> object file extension is there
> Already up-to-date.
>
> $ ./config
> ...
> $ make depend && make clean && make
> ...
> $ make test
> ...
> ( cd test; \
> SRCTOP=../. \
> BLDTOP=../. \
> EXE_EXT= \
> /usr/bin/perl .././test/run_tests.pl )
> ../test/recipes/01-test_ordinals.t  ok
> ../test/recipes/05-test_bf.t .. ok
> ...
> ../test/recipes/25-test_x509.t  ok
> ../test/recipes/30-test_afalg.t ...
> ^C (after about 20 minutes)
>
> **

I've not been able to reproduce this issue. However it is plausible that it is
the same problem that Roumen recently reported on openssl-dev. Please can you
try again with the latest master (including commit 773fd0bad4).

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4411
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_cleanup new issue

[Matt Caswell]

Hi Roumen

On 10/03/16 22:21, Roumen Petrov wrote:
> Hello,
> 
> With new thread model in some configurations openssl hands on unload of
> engine.

I just pushed commit 773fd0bad4 to master which should hopefully resolve
this issue.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Please consider delaying the Beta-1 freeze for a week or two

[Matt Caswell]

On 11/03/16 01:03, Jeffrey Walton wrote:
> Hi Everyone,
> 
> Testing master on real hardware is showing some minor issues on a few
> platforms, including ARM32, ARM64, PowerPC and i686. In addition,
> there seems to be one-off issues on other combinations, like VIA's C7
> processor on Linux.
> 
> In addition to the base issues, there are other minor issues like
> failing to configure and compile with 'no-comp'. Other configuration
> dependent issues include failed self tests under PowerPC in a shared
> configuration.
> 
> Please consider delaying the freeze for a week or two while the issues
> are being ironed out.

I'd argue that a freeze helps us to iron the issues out. Problems tend
to get introduced when new features are added. By declaring a freeze we
no longer accept new features and can instead divert our attention to
stability and bug fixing.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] current github 1.1.0-pre "clang: error: unsupported option '--unified'

[Matt Caswell]

--unified has been removed and it is now the default. If you want "old"
build use --classic.

Matt


On 08/03/16 15:51, Blumenthal, Uri - 0553 - MITLL wrote:
> $ ./Configure darwin64-x86_64-cc enable-rfc3779 threads zlib
> enable-ec_nistp_64_gcc_128 shared
> --prefix=/Users/ur20980/src/openssl-1.1
> --openssldir=/Users/ur20980/src/openssl-1.1/etc --unified
> 
> Smartmatch is experimental at ./Configure line 2144.
> 
> Configuring OpenSSL version 1.1.0-pre4-dev (0x0x1014L)
> 
> no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> 
> no-crypto-mdebug-backtrace [forced]  
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> 
> no-egd  [default]  OPENSSL_NO_EGD (skip dir)
> 
> no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
> 
> no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
> 
> no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
> 
> no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
> 
> no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
> 
> no-ssl3 [default]  OPENSSL_NO_SSL3 (skip dir)
> 
> no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
> 
> no-static-engine [default]  OPENSSL_NO_STATIC_ENGINE (skip dir)
> 
> no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
> 
> no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
> 
> no-zlib-dynamic [default] 
> 
> Configuring for darwin64-x86_64-cc
> 
> IsMK1MF   =no
> 
> CC=clang
> 
> CFLAG =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  --unified
> 
> DEFINES   =ZLIB DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS
> OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
> OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM
> SHA256_ASM SHA512_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM
> ECP_NISTZ256_ASM POLY1305_ASM
> 
> LFLAG =
> 
> PLIB_LFLAG=-Wl,-search_paths_first
> 
> EX_LIBS   =-lz 
> 
> APPS_OBJ  =
> 
> CPUID_OBJ =x86_64cpuid.o
> 
> UPLINK_OBJ=
> 
> BN_ASM=asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o
> x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
> 
> EC_ASM=ecp_nistz256.o ecp_nistz256-x86_64.o
> 
> DES_ENC   =des_enc.o fcrypt_b.o
> 
> AES_ENC   =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o
> aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
> 
> BF_ENC=bf_enc.o
> 
> CAST_ENC  =c_enc.o
> 
> RC4_ENC   =rc4-x86_64.o rc4-md5-x86_64.o
> 
> RC5_ENC   =rc5_enc.o
> 
> MD5_OBJ_ASM   =md5-x86_64.o
> 
> SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> sha1-mb-x86_64.o sha256-mb-x86_64.o
> 
> RMD160_OBJ_ASM=
> 
> CMLL_ENC  =cmll-x86_64.o cmll_misc.o
> 
> MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
> 
> PADLOCK_OBJ   =e_padlock-x86_64.o
> 
> CHACHA_ENC=chacha-x86_64.o
> 
> POLY1305_OBJ  =poly1305-x86_64.o
> 
> PROCESSOR =
> 
> RANLIB=ranlib -c
> 
> ARFLAGS   =
> 
> PERL  =/opt/local/bin/perl5
> 
> 
> SIXTY_FOUR_BIT_LONG mode
> 
> 
> Configured for darwin64-x86_64-cc.
> 
> $ make depend && make clean && make all && make test && make install
> 
> rm -f libcrypto.1.1.dylib
> 
> rm -f libcrypto.dylib
> 
> rm -f libssl.1.1.dylib
> 
> rm -f libssl.dylib
> 
> rm -f libcrypto.a libssl.a
> 
> rm -f apps/openssl test/afalgtest test/asynctest test/bftest test/bntest
> test/casttest test/clienthellotest test/constant_time_test test/ct_test
> test/danetest test/destest test/dhtest test/dsatest
> test/dtlsv1listentest test/ecdhtest test/ecdsatest test/ectest
> test/enginetest test/evp_extra_test test/evp_test test/exptest
> test/gmdifftest test/heartbeat_test test/hmactest test/ideatest
> test/igetest test/md2test test/md4test test/md5test test/mdc2test
> test/memleaktest test/nptest test/p5_crpt2_test test/packettest
> test/pbelutest test/randtest test/rc2test test/rc4test test/rc5test
> test/rmdtest test/rsa_test test/secmemtest test/sha1test test/sha256t
> test/sha512t test/srptest test/ssltest test/threadstest test/v3nametest
> test/verify_extra_test test/wp_test
> 
> rm -f `find . -name '*.d'`
> 
> rm -f `find . -name '*.o'`
> 
> rm -f ./core
> 
> rm -f ./tags ./TAGS
> 
> rm -f ./openssl.pc ./libcrypto.pc ./libssl.pc
> 
> rm -f `find . -type l`
> 
> rm -f ../openssl-1.1.0-pre4-dev.tar
> 
> clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
> -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
> -DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
> -DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
> -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  --unified -fPIC -Iinclude
> -I. -Icrypto/include -MMD -MF crypto/aes/aes-x86_64.d.tmp -MT
> crypto/aes/aes-x86_64.o -c -o crypto/aes/aes-x86_64.o
> crypto/aes/aes-x

[openssl-dev] [openssl.org #4396] OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

[Matt Caswell via RT]

On Mon Mar 07 23:02:26 2016, noloa...@gmail.com wrote:
> This just showed up on OS X 10-5, 64-bit PowerPC. Its not present
> under Linux.
>
> $ git reset --hard HEAD
> HEAD is now at e1d9f1a Remove kinv/r fields from DSA structure.
> $ git pull
> Already up-to-date.
>
> $ ./config && make depend && make clean && make
> ...
>
> c -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM
> -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
> -DENGINESDIR="\"/usr/local/lib/engines\"" -O3 -D_REENTRANT -arch ppc64
> -DB_ENDIAN -fPIC -c record/rec_layer_s3.c -o record/rec_layer_s3.o
> record/rec_layer_s3.c: In function 'ssl3_write_bytes':
> record/rec_layer_s3.c:645: error: 'split_send_fragment' undeclared
> (first use in this function)
> record/rec_layer_s3.c:645: error: (Each undeclared identifier is
> reported only once
> record/rec_layer_s3.c:645: error: for each function it appears in.)
> record/rec_layer_s3.c:652: error: 'maxpipes' undeclared (first use in
> this function)
> make[1]: *** [record/rec_layer_s3.o] Error 1

This issue should be fixed now. Closing ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4396
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] Running against BoringSSL's SSL test suite

[Matt Caswell]

On 07/03/16 21:49, David Benjamin wrote:
> Hi folks,
> 
> So, we've by now built up a decent-sized SSL test suite in BoringSSL. I
> was bored and ran it against OpenSSL master. It revealed a number of
> bugs. One is https://github.com/openssl/openssl/pull/603. I'll be filing
> tickets shortly for the remaining ones I've triaged, but I thought I'd
> send this separately rather than duplicate it everywhere.

Wow! That's awesome! Thanks David.

> 
> Emilia also suggested there may be room to collaborate on testing. If
> nothing else, just borrowing ideas or porting tests to/from your
> TLSProxy setup. (Like, say, the ones that caught the bugs I'll be
> reporting. :-) ) So, here's an introduction on how it all works:
> 
> To run the tests on OpenSSL, clone BoringSSL:
> https://boringssl.googlesource.com/boringssl/
> Then patch in this change. (Click the "Download" in the upper-right for
> options.)
> https://boringssl-review.googlesource.com/#/c/7332/
> Then follow the instructions in the commit message.
> 
> The tests themselves and the runner logic live in ssl/test/runner/runner.go:
> https://boringssl.googlesource.com/boringssl/+/22ce9b2d08a52e399bf2ab86851952d727be034d/ssl/test/runner/runner.go#922
> 
> They work by running an unmodified TLS stack in a shim binary against a
> copy of Go's. We patch our copy with options for weird behavior to test
> against:
> https://boringssl.googlesource.com/boringssl/+/22ce9b2d08a52e399bf2ab86851952d727be034d/ssl/test/runner/common.go#414
> 
> Go and shim communicate entirely with sockets and (tons of) command-line
> flags, though it is slightly overfit to BoringSSL's behavior and checks
> error strings a lot. The shim also has options like -async mode which we
> use on a subset of tests to stress state machine resumption. (This has
> saved me from state machine bugs so many times.)
> https://boringssl.googlesource.com/boringssl/+/22ce9b2d08a52e399bf2ab86851952d727be034d/ssl/test/runner/runner.go#2770
> https://boringssl.googlesource.com/boringssl/+/22ce9b2d08a52e399bf2ab86851952d727be034d/ssl/test/bssl_shim.cc#826
> 
> I hope this is useful! Bugs and patches will follow this mail, as I
> write them up.

Great. We're in the final few days prior to the 1.1.0 feature freeze and
the team are working flat out at the moment. I'll try and start looking
at them once we're past that milestone later this week.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

[Matt Caswell]

On 07/03/16 23:43, noloa...@gmail.com via RT wrote:
> On Mon, Mar 7, 2016 at 6:29 PM, Matt Caswell via RT  wrote:
>> Fix already on the way.
>>
> 
> Thanks.  I'm not sure what's triggering it on OS X because those
> defines don't seem to show up in the configuration gear:


EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK is defined in evp.h:

# define EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK 0x40


Then at the top of rec_layer_s3.c we have this:

#if defined(OPENSSL_SMALL_FOOTPRINT) || \
!(  defined(AES_ASM) && ( \
defined(__x86_64)   || defined(__x86_64__)  || \
defined(_M_AMD64)   || defined(_M_X64)  || \
defined(__INTEL__)  ) \
)
# undef EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK
# define EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK 0
#endif

So, if the above condition evaluates to true then
EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK is redefined to be 0 and then when we
get here:

#if !defined(OPENSSL_NO_MULTIBLOCK) && EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK
unsigned int max_send_fragment, split_send_fragment, maxpipes;
unsigned int u_len = (unsigned int)len;
#endif

The condition will evaluate to false, and so the variables in question
will not be defined.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

[Matt Caswell via RT]

On 07/03/16 23:43, noloa...@gmail.com via RT wrote:
> On Mon, Mar 7, 2016 at 6:29 PM, Matt Caswell via RT  wrote:
>> Fix already on the way.
>>
> 
> Thanks.  I'm not sure what's triggering it on OS X because those
> defines don't seem to show up in the configuration gear:


EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK is defined in evp.h:

# define EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK 0x40


Then at the top of rec_layer_s3.c we have this:

#if defined(OPENSSL_SMALL_FOOTPRINT) || \
!(  defined(AES_ASM) && ( \
defined(__x86_64)   || defined(__x86_64__)  || \
defined(_M_AMD64)   || defined(_M_X64)  || \
defined(__INTEL__)  ) \
)
# undef EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK
# define EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK 0
#endif

So, if the above condition evaluates to true then
EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK is redefined to be 0 and then when we
get here:

#if !defined(OPENSSL_NO_MULTIBLOCK) && EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK
unsigned int max_send_fragment, split_send_fragment, maxpipes;
unsigned int u_len = (unsigned int)len;
#endif

The condition will evaluate to false, and so the variables in question
will not be defined.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4396
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 #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

[Matt Caswell via RT]

Fix already on the way.

Matt

On 07/03/16 23:28, noloa...@gmail.com via RT wrote:
> On Mon, Mar 7, 2016 at 6:02 PM, Jeffrey Walton  wrote:
>> This just showed up on OS X 10-5, 64-bit PowerPC. Its not present under 
>> Linux.
>>
>> $ git reset --hard HEAD
>> HEAD is now at e1d9f1a Remove kinv/r fields from DSA structure.
>> $ git pull
>> Already up-to-date.
> 
> This can be duplicated on Linux with:
> 
> $ ./config -DOPENSSL_NO_MULTIBLOCK
> 
> 
> Result:
> 
> gcc -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
> -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
> -DOPENSSL_NO_MULTIBLOCK -DOPENSSLDIR="\"/usr/local/ssl\""
> -DENGINESDIR="\"/usr/local/lib/engines\"" -Wall -O3 -pthread -m64
> -DL_ENDIAN  -Wa,--noexecstack -fPIC -c record/rec_layer_s3.c -o
> record/rec_layer_s3.o
> record/rec_layer_s3.c: In function 'ssl3_write_bytes':
> record/rec_layer_s3.c:645:5: error: 'split_send_fragment' undeclared
> (first use in this function)
>  split_send_fragment = s->split_send_fragment;
>  ^
> record/rec_layer_s3.c:645:5: note: each undeclared identifier is
> reported only once for each function it appears in
> record/rec_layer_s3.c:652:5: error: 'maxpipes' undeclared (first use
> in this function)
>  maxpipes = s->max_pipelines;
>  ^
> record/rec_layer_s3.c:453:21: warning: unused variable 'nw' 
> [-Wunused-variable]
>  unsigned int n, nw;
>  ^
> make[1]: *** [record/rec_layer_s3.o] Error 1
> 
> 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4396
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 #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

[Matt Caswell]

Fix already on the way.

Matt

On 07/03/16 23:28, noloa...@gmail.com via RT wrote:
> On Mon, Mar 7, 2016 at 6:02 PM, Jeffrey Walton  wrote:
>> This just showed up on OS X 10-5, 64-bit PowerPC. Its not present under 
>> Linux.
>>
>> $ git reset --hard HEAD
>> HEAD is now at e1d9f1a Remove kinv/r fields from DSA structure.
>> $ git pull
>> Already up-to-date.
> 
> This can be duplicated on Linux with:
> 
> $ ./config -DOPENSSL_NO_MULTIBLOCK
> 
> 
> Result:
> 
> gcc -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
> -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
> -DOPENSSL_NO_MULTIBLOCK -DOPENSSLDIR="\"/usr/local/ssl\""
> -DENGINESDIR="\"/usr/local/lib/engines\"" -Wall -O3 -pthread -m64
> -DL_ENDIAN  -Wa,--noexecstack -fPIC -c record/rec_layer_s3.c -o
> record/rec_layer_s3.o
> record/rec_layer_s3.c: In function 'ssl3_write_bytes':
> record/rec_layer_s3.c:645:5: error: 'split_send_fragment' undeclared
> (first use in this function)
>  split_send_fragment = s->split_send_fragment;
>  ^
> record/rec_layer_s3.c:645:5: note: each undeclared identifier is
> reported only once for each function it appears in
> record/rec_layer_s3.c:652:5: error: 'maxpipes' undeclared (first use
> in this function)
>  maxpipes = s->max_pipelines;
>  ^
> record/rec_layer_s3.c:453:21: warning: unused variable 'nw' 
> [-Wunused-variable]
>  unsigned int n, nw;
>  ^
> make[1]: *** [record/rec_layer_s3.o] Error 1
> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] overflow issue in b2i_PVK_bio

[Matt Caswell]

On 03/03/16 11:54, Marcus Meissner wrote:
> Hi,
> 
> https://guidovranken.wordpress.com/2016/03/01/public-disclosure-malformed-private-keys-lead-to-heap-corruption-in-b2i_pvk_bio/
>
>  Integer overflow in b2i_PVK_bio
> 
> Have you assigned a CVE internally for that already?
> 
> Ciao, Marcus
> 

This has been fixed in commit 5f57abe2b15 (master version, similar
commits in other branches):

commit 5f57abe2b150139b8b057313d52b1fe8f126c952
Author: Dr. Stephen Henson 
AuthorDate: Thu Mar 3 23:37:36 2016 +
Commit: Dr. Stephen Henson 
CommitDate: Fri Mar 4 01:20:04 2016 +

Sanity check PVK file fields.

PVK files with abnormally large length or salt fields can cause an
integer overflow which can result in an OOB read and heap corruption.
However this is an rarely used format and private key files do not
normally come from untrusted sources the security implications not
significant.

Fix by limiting PVK length field to 100K and salt to 10K: these
should be
more than enough to cover any files encountered in practice.

Issue reported by Guido Vranken.

Reviewed-by: Rich Salz 


As per the notes in the commit we do not see the security implications
as significant and therefore we are treating this as a bug and will not
be issuing a CVE.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] MSVC 2015 internal compiler error

[Matt Caswell]

On 24/02/16 16:48, Gisle Vanem wrote:
> Matt Caswell wrote:
> 
>> The complete patch is attached. This is currently going through review,
>> and solves the link issue.
> 
> That brought MSVC-2015 back on track. Thanks!
> 

This has now been committed, so hopefully this should work again now.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[Matt Caswell]

On 23/02/16 16:38, Sander Temme wrote:
> All,
> 
> I toyed over the weekend with resurrecting CHIL: intermediate result
> here https://github.com/sctemme/openssl/tree/rescue-chil and I AM NOT
> PROUD OF THIS but have no cycles to clean it up for at least a couple
> of days to come. It builds now but doesn't work: my privkey loading
> routine doesn't get called and that may be an API change I missed.
> 
> Can we resurrect CHIL for 1.1 along these lines? Then I'd be
> delighted to join the discussion about p11 for down the road.

I would prefer to move CHIL to an external repo (e.g. maybe Richard's
engine corner??). As Richard said in another post, this code is
unmaintainable by us because no-one on the team has access to the
relevant hardware.

BTW, no one has spoken up for Ubsec, which was the other engine
mentioned in the original post, so I will be removing that one imminently.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] SSL_library_init

[Matt Caswell]

On 24/02/16 15:50, The Doctor wrote:
> As of 2106-20-24 SSL_librbary_init may not be avialable in the libssl.so .
> 
> Is their a workaround for this?
> 

SSL_library_init is still available in ssl.h as a compatibility macro:

#if OPENSSL_API_COMPAT < 0x1010L
# define SSL_library_init() OPENSSL_init_ssl(0, NULL)
#endif

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] MSVC 2015 internal compiler error

[Matt Caswell]

On 24/02/16 10:29, Gisle Vanem wrote:
> Matt Caswell wrote:
> 
>> The attached seems to avoid the problem - but then for reasons I cannot
>> understand link errors result later on in the build.
> 
> I too can confirm that your patch fixes MSVC-2105 compilation.
> Thanks a million!
> 
> But as you wrote, the link fails. Due to util/mkdef.pl needs
> an update? I looked at this .pl-file, but I'm a n00b when it
> comes to Perl. So I fail to see how it now should define all
> needed .def symbols.
> 
> As it's now, ssleay32.dll export only these:
>   BIO_f_ssl
>   BIO_new_ssl
>   BIO_ssl_copy_session_id
>   BIO_ssl_shutdown
>   BIO_new_buffer_ssl_connect
>   BIO_new_ssl_connect
> 
> But is building with -DOPENSSL_OPT_WINDLL (i.e. __declspec(dllimport)
> while using the OpenSSL .DLLs) still supported? If so, what is the
> .def-files good for then?
> 
The complete patch is attached. This is currently going through review,
and solves the link issue.

Matt
>From b4f4c8dfdb9ab4b88b52ee5708dc4da16c10ee64 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Tue, 23 Feb 2016 15:27:05 +
Subject: [PATCH] Workaround for VisualStudio 2015 bug

VisualStudio 2015 has a bug where an internal compiler error was occurring.
By reordering the DEFINE_STACK_OF declarations for SSL_CIPHER and SSL_COMP
until after the ssl3.h include everything seems ok again.
---
 include/openssl/ssl.h | 11 +--
 util/mkdef.pl |  3 ++-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/include/openssl/ssl.h b/include/openssl/ssl.h
index 9709103..4fb4e8a 100644
--- a/include/openssl/ssl.h
+++ b/include/openssl/ssl.h
@@ -326,8 +326,8 @@ typedef struct tls_sigalgs_st TLS_SIGALGS;
 typedef struct ssl_conf_ctx_st SSL_CONF_CTX;
 typedef struct ssl_comp_st SSL_COMP;
 
-DEFINE_STACK_OF_CONST(SSL_CIPHER)
-DEFINE_STACK_OF(SSL_COMP)
+STACK_OF(SSL_CIPHER);
+STACK_OF(SSL_COMP);
 
 /* SRTP protection profiles for use with the use_srtp extension (RFC 5764)*/
 typedef struct srtp_protection_profile_st {
@@ -907,6 +907,13 @@ __owur int SSL_extension_supported(unsigned int ext_type);
 extern "C" {
 #endif
 
+/*
+ * These need to be after the above set of includes due to a compiler bug
+ * in VisualStudio 2015
+ */
+DEFINE_STACK_OF_CONST(SSL_CIPHER)
+DEFINE_STACK_OF(SSL_COMP)
+
 /* compatibility */
 # define SSL_set_app_data(s,arg) (SSL_set_ex_data(s,0,(char *)arg))
 # define SSL_get_app_data(s) (SSL_get_ex_data(s,0))
diff --git a/util/mkdef.pl b/util/mkdef.pl
index a2fedc5..e9a3aff 100755
--- a/util/mkdef.pl
+++ b/util/mkdef.pl
@@ -632,7 +632,8 @@ sub do_defs
 next;
 			}
 			if ($tag{'TRUE'} != -1) {
-if (/^\s*DECLARE_STACK_OF\s*\(\s*(\w*)\s*\)/) {
+if (/^\s*DEFINE_STACK_OF\s*\(\s*(\w*)\s*\)/
+		|| /^\s*DEFINE_STACK_OF_CONST\s*\(\s*(\w*)\s*\)/) {
 	next;
 } elsif (/^\s*DECLARE_ASN1_ENCODE_FUNCTIONS\s*\(\s*(\w*)\s*,\s*(\w*)\s*,\s*(\w*)\s*\)/) {
 	$def .= "int d2i_$3(void);";
-- 
2.5.0

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] MSVC 2015 internal compiler error

[Matt Caswell]

On 23/02/16 15:59, Matt Caswell wrote:
> 
> 
> On 23/02/16 01:55, Bill Bierman wrote:
>> The Microsoft compiler team has suggested removing the include of ssl.h
>> from srtp.h as it creates a circular reference which is likely confusing
>> the compiler.
>>
>> On Mon, Feb 22, 2016 at 2:19 PM, Bill Bierman > <mailto:b...@thebiermans.org>> wrote:
>>
>> Hello.  I'm sorry I cannot reply to the thread.  I only just now
>> have subscribed to the list.
>>
>> I can confirm that this problem exists with Visual Studio 2015 on HEAD.
>>
>> I spoke to a friend of mine who works at MS who relayed this to the
>> compiler team.  A senior dev there is aware of the issue and they
>> are working on a fix.
> 
> 
> The attached seems to avoid the problem - but then for reasons I cannot
> understand link errors result later on in the build.

Ahhh, mkdef.pl had fallen over...fix coming up.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] MSVC 2015 internal compiler error

[Matt Caswell]

On 23/02/16 01:55, Bill Bierman wrote:
> The Microsoft compiler team has suggested removing the include of ssl.h
> from srtp.h as it creates a circular reference which is likely confusing
> the compiler.
> 
> On Mon, Feb 22, 2016 at 2:19 PM, Bill Bierman  <mailto:b...@thebiermans.org>> wrote:
> 
> Hello.  I'm sorry I cannot reply to the thread.  I only just now
> have subscribed to the list.
> 
> I can confirm that this problem exists with Visual Studio 2015 on HEAD.
> 
> I spoke to a friend of mine who works at MS who relayed this to the
> compiler team.  A senior dev there is aware of the issue and they
> are working on a fix.


The attached seems to avoid the problem - but then for reasons I cannot
understand link errors result later on in the build.

Matt
>From 68db934d65513236b6e0ffd5290d0f53b71f56c9 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Tue, 23 Feb 2016 15:27:05 +
Subject: [PATCH] Workaround for VisualStudio 2015 bug

VisualStudio 2015 has a bug where an internal compiler error was occurring.
By reordering the DEFINE_STACK_OF declarations for SSL_CIPHER and SSL_COMP
until after the ssl3.h include everything seems ok again.
---
 include/openssl/ssl.h | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/include/openssl/ssl.h b/include/openssl/ssl.h
index 9709103..b6e6960 100644
--- a/include/openssl/ssl.h
+++ b/include/openssl/ssl.h
@@ -326,8 +326,6 @@ typedef struct tls_sigalgs_st TLS_SIGALGS;
 typedef struct ssl_conf_ctx_st SSL_CONF_CTX;
 typedef struct ssl_comp_st SSL_COMP;
 
-DEFINE_STACK_OF_CONST(SSL_CIPHER)
-DEFINE_STACK_OF(SSL_COMP)
 
 /* SRTP protection profiles for use with the use_srtp extension (RFC 5764)*/
 typedef struct srtp_protection_profile_st {
@@ -907,6 +905,13 @@ __owur int SSL_extension_supported(unsigned int ext_type);
 extern "C" {
 #endif
 
+/*
+ * These need to be after the above set of includes due to a compiler bug
+ * in VisualStudio 2015
+ */
+DEFINE_STACK_OF_CONST(SSL_CIPHER)
+DEFINE_STACK_OF(SSL_COMP)
+
 /* compatibility */
 # define SSL_set_app_data(s,arg) (SSL_set_ex_data(s,0,(char *)arg))
 # define SSL_get_app_data(s) (SSL_get_ex_data(s,0))
-- 
2.5.0

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4322] SSL_shutdown:shutdown while in init (1.0.2f)

[Matt Caswell via RT]

On Fri Feb 19 13:58:34 2016, i...@ecsystems.nl wrote:
> openssl 1.0.2f static build with nginx 1.9.12 (development version)
>
> about
>
https://github.com/openssl/openssl/commit/64193c8218540499984cd63cda41f3cd491f3f59
>
> This may solve the initial issue but creates a new one:
> SSL_shutdown() failed (SSL: error:140E0197:SSL
> routines:SSL_shutdown:shutdown while in init) while SSL handshaking

That is expected behaviour. The original behaviour returned a "success" result
from SSL_shutdown() even though it had actually failed. The new behaviour
reports that as an error.

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4322
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] Ubsec and Chil engines

[Matt Caswell]

On 19/02/16 13:11, Jaroslav Imrich wrote:
> Hello Matt,
> 
> If I don't hear from anyone I will remove these.
> 
> 
> I can confirm that CHIL engine is actively used with OpenSSL 1.0.* by
> the owners of nCipher/THALES nShield HSMs.
> 
> I have notified vendor support about this thread.
> 
Great. Thanks Jaroslav. It would be good if the vendor could take on
support of the engine themselves.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[Matt Caswell]

On 19/02/16 13:03, Tomas Mraz wrote:
> On Pá, 2016-02-19 at 11:31 +0000, Matt Caswell wrote:
> 
> 
>> So it seems that for chil there may possibly be some rare use (but
>> even
>> the most recent evidence is 4 years old). However the OpenSSL dev
>> team
>> do not have access to this hardware to maintain the engine and (as
>> noted
>> above) this is currently not building in 1.1.0.
>>
>> In both cases I would like to remove these engines from 1.1.0. I'd
>> like
>> to hear from the community if there is any active use of these. One
>> option if there is found to be some small scale use is to spin out
>> the
>> engine into a separately managed repo (as has happened recently with
>> the
>> GOST engine).
>>
>> If I don't hear from anyone I will remove these.
> 
> As far as I know there are some customers using the Chil engine with
> RHEL (openssl-1.0.1). 

How do you feel about the engine being spun out into a separate repo?
That of course assumes that a volunteer can be found to maintain it (I
don't believe anyone on the dev team wishes to do so).

If no such volunteer can be found how big a deal is it to remove it from
1.1.0 without a replacement? Obviously it won't be taken out of
1.0.1/1.0.2. Of course there's no reason, even if we take it out now,
that if someone needs it badly enough in the future that they couldn't
forward port the 1.0.2 version to 1.1.0 and maintain it themselves at
that point.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Ubsec and Chil engines

[Matt Caswell]

Hi all

The ubsec and chil engines are currently disabled in 1.1.0 and do not build.

As far as ubsec is concerned I understand that this is an engine for
broadcom cards. There has been very little activity with this engine
since it was first introduced. Google brings up some very old historic
references to its use.

There are a couple of more recent references.

This post from 2014 suggests that OpenSSL's support for this is broken
anyway and has been for some while:
https://forum.pfsense.org/index.php?topic=71857.0

There is also this post from 2013 from someone trying to get it to work
but with no (apparent) success:
https://stackoverflow.com/questions/17715546/openssl-speed-test-for-broadcom-engine

So for ubsec I can't find any evidence that it is being used successfully.


For chil I found this dicussion from 2012 on openssl-users where
apparently someone was using it (successfully):
http://openssl.6102.n7.nabble.com/Tutorials-on-OpenSSL-integration-with-nCipher-HSM-nShield-td2311.html

This RT ticket from 2008 is suggesting various fixes - the last of which
was applied. There was a brief flurry of commits tweaking stuff in chil
around this time:
https://rt.openssl.org/Ticket/Display.html?id=1736


So it seems that for chil there may possibly be some rare use (but even
the most recent evidence is 4 years old). However the OpenSSL dev team
do not have access to this hardware to maintain the engine and (as noted
above) this is currently not building in 1.1.0.

In both cases I would like to remove these engines from 1.1.0. I'd like
to hear from the community if there is any active use of these. One
option if there is found to be some small scale use is to spin out the
engine into a separately managed repo (as has happened recently with the
GOST engine).

If I don't hear from anyone I will remove these.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks

[Matt Caswell via RT]

Looks like the last suggested patch against this ticket was applied. No further
activity since 2008, so assuming this is resolved. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1736
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] memory leaks detected using libSSL 1.1

[Matt Caswell]

On 18/02/16 13:59, Michel wrote:
> Yes !
> With your 2 patches applied, tls_decrypt_ticket.patch and
> fix-win-thread-stop.patch,
> (looks like I lost the first one yesterday), 
> none of my tests programs using libSSL v1.1 reports leaks.
> 
> I feel better. :-)

Great. I'll get those reviewed and committed.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] memory leaks detected using libSSL 1.1

[Matt Caswell]

s.cpp (953):
> TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes
> p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (64):
> TestsTLS-11.exe!CltThread::Main() + 0xB bytes
> p:\mes programmes\shared\sthread.cpp (17):
> TestsTLS-11.exe!SThread::Run() + 0xE bytes
> f:\dd\vctools\crt\crtw32\startup\threadex.c (359):
> TestsTLS-11.exe!_threadstartex()
> 
> 
> -- Block 5000 at 0x00A40CA8: 400 bytes --
>   Leak Hash: 0x2037555F, Count: 1, Total 400 bytes
>   Call Stack (TID 6080):
> ntdll.dll!RtlAllocateHeap()
> f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc()
> + 0x15 bytes
> e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() +
> 0x9 bytes
> e:\openssl-1.1.git\crypto\err\err.c (874):
> TestsTLS-11.exe!ERR_get_state() + 0x14 bytes
> e:\openssl-1.1.git\crypto\err\err.c (598):
> TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes
> e:\openssl-1.1.git\ssl\statem\statem.c (279):
> TestsTLS-11.exe!state_machine()
> e:\openssl-1.1.git\ssl\statem\statem.c (222):
> TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes
> e:\openssl-1.1.git\ssl\ssl_lib.c (2905):
> TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes
> p:\mes programmes\shared\ocrypto-11\tls.cpp (953):
> TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes
> p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79):
> TestsTLS-11.exe!SrvThread::Main() + 0xB bytes
> p:\mes programmes\shared\sthread.cpp (17):
> TestsTLS-11.exe!SThread::Run() + 0xE bytes
> f:\dd\vctools\crt\crtw32\startup\threadex.c (359):
> TestsTLS-11.exe!_threadstartex()
> 
> 
> -- Block 7017 at 0x00A75628: 8 bytes --
>   Leak Hash: 0x82CA3A37, Count: 1, Total 8 bytes
>   Call Stack (TID 6080):
> ntdll.dll!RtlAllocateHeap()
> f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc()
> + 0x15 bytes
> e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() +
> 0x9 bytes
> e:\openssl-1.1.git\crypto\mem.c (161): TestsTLS-11.exe!CRYPTO_zalloc() +
> 0x11 bytes
> e:\openssl-1.1.git\crypto\init.c (212):
> TestsTLS-11.exe!ossl_init_get_thread_local() + 0x11 bytes
> e:\openssl-1.1.git\crypto\init.c (568):
> TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes
> e:\openssl-1.1.git\crypto\err\err.c (898):
> TestsTLS-11.exe!ERR_get_state() + 0x9 bytes
> e:\openssl-1.1.git\crypto\err\err.c (598):
> TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes
> e:\openssl-1.1.git\ssl\statem\statem.c (279):
> TestsTLS-11.exe!state_machine()
> e:\openssl-1.1.git\ssl\statem\statem.c (222):
> TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes
> e:\openssl-1.1.git\ssl\ssl_lib.c (2905):
> TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes
> p:\mes programmes\shared\ocrypto-11\tls.cpp (953):
> TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes
> p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79):
> TestsTLS-11.exe!SrvThread::Main() + 0xB bytes
> p:\mes programmes\shared\sthread.cpp (17):
> TestsTLS-11.exe!SThread::Run() + 0xE bytes
> f:\dd\vctools\crt\crtw32\startup\threadex.c (359):
> TestsTLS-11.exe!_threadstartex()
> 
> 
> Visual Leak Detector detected 5 memory leaks (16416 bytes).
> Largest number used: 442154 bytes.
> Total allocations: 1908126 bytes.
> 
> 
>From 41f8a77731432586b2923dd77c523b79c9bd7025 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Thu, 18 Feb 2016 12:24:09 +
Subject: [PATCH] Fix windows thread stop code

The windows thread stop code was erroneously not just deleting the thread
local variable on thread stop, but also deleting the thread local *key*
(thus removing thread local data for *all* threads in one go!).
---
 crypto/init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/init.c b/crypto/init.c
index c7eff8b..106bb10 100644
--- a/crypto/init.c
+++ b/crypto/init.c
@@ -500,7 +500,6 @@ static void ossl_init_thread_stop(struct thread_local_inits_st *locals)
 }
 
 OPENSSL_free(locals);
-ossl_init_thread_stop_cleanup();
 }
 
 void OPENSSL_thread_stop(void)
@@ -593,6 +592,8 @@ void OPENSSL_cleanup(void)
 ERR_free_strings();
 }
 
+ossl_init_thread_stop_cleanup();
+
 #ifdef OPENSSL_INIT_DEBUG
 fprintf(stderr, "OPENSSL_INIT: OPENSSL_INIT_library_stop: "
 "CRYPTO_cleanup_all_ex_data()\n");
-- 
2.5.0

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] memory leaks detected using libSSL 1.1

[Matt Caswell]

On 18/02/16 00:13, Michel wrote:
> Hi Matt, 
> 
> Thanks for the suggestion.
> 
> This is what was printed to stderr :
> OPENSSL_INIT: ossl_init_base: Setting up stop handlers
> OPENSSL_INIT: ossl_init_add_all_ciphers: openssl_add_all_ciphers_internal()
> OPENSSL_INIT: ossl_init_add_all_digests: openssl_add_all_digests_internal()
> OPENSSL_INIT: ossl_init_ssl_base: Adding SSL ciphers and digests
> OPENSSL_INIT: ossl_init_ssl_base: SSL_COMP_get_compression_methods()
> OPENSSL_INIT: ossl_init_ssl_base: SSL_add_ssl_module()
> OPENSSL_INIT: ossl_init_load_ssl_strings: ERR_load_SSL_strings()
> OPENSSL_INIT: ossl_init_async: async_init()
> OPENSSL_INIT: ossl_init_load_crypto_strings:
> err_load_crypto_strings_intern()
> OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state
> OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state
> OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL)
> OPENSSL_INIT: ssl_library_stop: SSL_COMP_free_compression_methods()
> OPENSSL_INIT: ssl_library_stop: ERR_free_strings()
> OPENSSL_INIT: OPENSSL_cleanup: ERR_free_strings()
> OPENSSL_INIT: OPENSSL_INIT_library_stop: CRYPTO_cleanup_all_ex_data()
> OPENSSL_INIT: OPENSSL_INIT_library_stop: EVP_cleanup()
> OPENSSL_INIT: OPENSSL_INIT_library_stop: CONF_modules_free()
> OPENSSL_INIT: OPENSSL_INIT_library_stop: RAND_cleanup()
> 
> Shouldn't there be at least another line with ERR_remove_thread_state() (one
> for each thread) ?

Yes. I can see we have two of these:

OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state
OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state

Which means that the init code has spotted that there are two threads
running and has initialised the error system for both of them.

But we only get one of these:

OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL)

Which means only one of the two threads has subsequently been de-inited.
That's very odd.

I have two possible theories:
1) OPENSSL_thread_stop() is not actually getting called as we think it is.
Or
2) The Thread Local Structure that keeps track of what things need
cleanup is not being obtained correctly for some reason during the
thread stop...so we have "forgotten" that we initialised the error system.

To try and help narrow down which of these possibilities it is I have
created a patch (attached) which bumps up the logging significantly.
Please can you apply it, rerun your code (with OPENSSL_INIT_DEBUG
defined still) and post the output here?

Thanks

Matt


> This test program launch 1 server thread and 1 client thread.
> Both of them have OPENSSL_thread_stop() in their [pre-]exit member function.
> 
> Michel.
> 
> -Message d'origine-
> De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Matt
> Caswell
> Envoyé : mercredi 17 février 2016 17:23
> À : openssl-dev@openssl.org
> Objet : Re: [openssl-dev] memory leaks detected using libSSL 1.1
> 
>> Am I missing anything else ?
> 
> That should be sufficient (although the OPENSSL_cleanup() should not be
> required).
> 
> You could try compiling OpenSSL with OPENSSL_INIT_DEBUG defined, e.g.
> 
> perl Configure your-platform-here -DOPENSSL_INIT_DEBUG
> 
> This should print out some debugging information to stderr every time the
> init functions attempt to do something interesting. In particular when you
> call OPENSSL_thread_stop() you should see the following printed
> out:
> 
> OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL)
> 
> Matt
> 
From 6679ef43680a63aac9430bfbc6d49014d5675948 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Thu, 18 Feb 2016 09:32:42 +
Subject: [PATCH] Add some additional logging to thread stop code

---
 crypto/init.c | 77 ++-
 1 file changed, 71 insertions(+), 6 deletions(-)

diff --git a/crypto/init.c b/crypto/init.c
index 25e3dc7..c4d5c81 100644
--- a/crypto/init.c
+++ b/crypto/init.c
@@ -194,14 +194,36 @@ static struct thread_local_inits_st *ossl_init_get_thread_local(int alloc)
 {
 struct thread_local_inits_st *local = TlsGetValue(threadstopkey);
 
+#ifdef OPENSSL_INIT_DEBUG
+DWORD threadid;
+threadid = GetCurrentThreadId();
+fprintf(stderr, "OPENSSL_INIT: ossl_init_get_thread_local: "
+"Starting: Local value is %s, alloc is %d (%ld)\n",
+((local == NULL)?"NULL":"NOT NULL"), alloc, threadid);
+#endif
+
 if (local == NULL && alloc) {
+#ifdef OPENSSL_INIT_DEBUG
+fprintf(stderr, "OPENSSL_INIT: ossl_init_get_thread_local: "
+"Allocating a new local structure (%ld)\n", threadid);
+#endif
 local = OPENSSL_zalloc(sizeof *loc

Re: [openssl-dev] memory leaks detected using libSSL 1.1

[Matt Caswell]

tsTLS-11.exe!malloc()
> + 0x15 bytes
> e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() +
> 0x9 bytes
> e:\openssl-1.1.git\crypto\lhash\lhash.c (168):
> TestsTLS-11.exe!lh_insert() + 0xB bytes
> e:\openssl-1.1.git\crypto\err\err_lcl.h (2):
> TestsTLS-11.exe!lh_ERR_STATE_insert() + 0x10 bytes
> e:\openssl-1.1.git\crypto\err\err.c (371):
> TestsTLS-11.exe!int_thread_set_item() + 0xD bytes
> e:\openssl-1.1.git\crypto\err\err.c (884):
> TestsTLS-11.exe!ERR_get_state() + 0xC bytes
> e:\openssl-1.1.git\crypto\err\err.c (598):
> TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes
> e:\openssl-1.1.git\ssl\statem\statem.c (279):
> TestsTLS-11.exe!state_machine()
> e:\openssl-1.1.git\ssl\statem\statem.c (222):
> TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes
> e:\openssl-1.1.git\ssl\ssl_lib.c (2908):
> TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes
> p:\mes programmes\shared\ocrypto-11\tls.cpp (953):
> TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes
> p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79):
> TestsTLS-11.exe!SrvThread::Main() + 0xB bytes
> p:\mes programmes\shared\sthread.cpp (17):
> TestsTLS-11.exe!SThread::Run() + 0xE bytes
> f:\dd\vctools\crt\crtw32\startup\threadex.c (359):
> TestsTLS-11.exe!_threadstartex()
> 
> 
> -- Block 7093 at 0x00484A40: 8 bytes --
>   Leak Hash: 0x160A9734, Count: 1, Total 8 bytes
>   Call Stack (TID 6408):
> ntdll.dll!RtlAllocateHeap()
> f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc()
> + 0x15 bytes
> e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() +
> 0x9 bytes
> e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() +
> 0x11 bytes
> e:\openssl-1.1.git\crypto\init.c (198):
> TestsTLS-11.exe!ossl_init_get_thread_local() + 0xB bytes
> e:\openssl-1.1.git\crypto\init.c (512):
> TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes
> e:\openssl-1.1.git\crypto\err\err.c (898):
> TestsTLS-11.exe!ERR_get_state() + 0x9 bytes
> e:\openssl-1.1.git\crypto\err\err.c (598):
> TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes
> e:\openssl-1.1.git\ssl\statem\statem.c (279):
> TestsTLS-11.exe!state_machine()
> e:\openssl-1.1.git\ssl\statem\statem.c (222):
> TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes
> e:\openssl-1.1.git\ssl\ssl_lib.c (2908):
> TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes
> p:\mes programmes\shared\ocrypto-11\tls.cpp (953):
> TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes
> p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79):
> TestsTLS-11.exe!SrvThread::Main() + 0xB bytes
> p:\mes programmes\shared\sthread.cpp (17):
> TestsTLS-11.exe!SThread::Run() + 0xE bytes
> f:\dd\vctools\crt\crtw32\startup\threadex.c (359):
> TestsTLS-11.exe!_threadstartex()
> 
> -Message d'origine-
> De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Matt
> Caswell
> Envoyé : mardi 16 février 2016 00:15
> À : openssl-dev@openssl.org
> Objet : Re: [openssl-dev] memory leaks detected using libSSL 1.1
> 
> Are you linking to OpenSSL statically?
> 
> Please see the "Notes" section on this page:
> https://www.openssl.org/docs/manmaster/crypto/OPENSSL_atexit.html
> 
> Matt
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published

[Matt Caswell]

On 16/02/16 16:17, David Woodhouse wrote:
> On Mon, 2016-02-15 at 22:17 +0000, Matt Caswell wrote:
>>
>> Maybe EVP_cleanup() and other similar explicit deinit functions should
>> be deprecated, and do nothing in 1.1.0? The auto-deinit capability
>> should handle it. That way you would not need to do anything "special"
>> for 1.1.0 with "#ifdef" etc. What do you think?
>>
>> If applications *must* do explicit cleanup they can always use the new
>> OPENSSL_cleanup() function (which is clear in the docs that you cannot
>> reinit afterwards).
> 
> What about libraries?
> 
> If a library (or loadable plugin within an application) uses OpenSSL,
> how should it clean up after itself?
> 
> It has no control over, and no visibility into, whether another library
> or the application itself might subsequently use OpenSSL again.
> 
> Any cleanup function which, as a side-effect, means that nobody can
> ever use OpenSSL for the remainder of the lifetime of the running
> process, seems entirely broken.
> 

The whole concept of a library cleaning up is broken. If a library
de-inits OpenSSL it cannot know if the application has finished using it
or not.

This is explicitly pointed out in the docs:

"The OPENSSL_cleanup() function deinitialises OpenSSL (both libcrypto
and libssl). All resources allocated by OpenSSL are freed. Typically
there should be no need to call this function directly as it is
initiated automatically on application exit. This is done via the
standard C library atexit function. In the event that the application
will close in a manner that will not call the registered atexit()
handlers then the application should call OPENSSL_cleanup() directly.
Developers of libraries using OpenSSL are discouraged from calling this
function and should instead, typically, rely on auto-deinitialisation.
This is to avoid error conditions where both an application and a
library it depends on both use OpenSSL, and the library deinitialises it
before the application has finished using it."

i.e. libraries should not explicitly deinit.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] memory leaks detected using libSSL 1.1

[Matt Caswell]

sTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes
> e:\openssl-1.1.git\crypto\err\err.c (321):
> TestsTLS-11.exe!int_thread_get() + 0xF bytes
> e:\openssl-1.1.git\crypto\err\err.c (369):
> TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes
> e:\openssl-1.1.git\crypto\err\err.c (884):
> TestsTLS-11.exe!ERR_get_state() + 0xC bytes
> e:\openssl-1.1.git\crypto\err\err.c (598):
> TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes
> e:\openssl-1.1.git\ssl\statem\statem.c (279):
> TestsTLS-11.exe!state_machine()
> e:\openssl-1.1.git\ssl\statem\statem.c (217):
> TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes
> e:\openssl-1.1.git\ssl\ssl_lib.c (2908):
> TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes
> p:\mes programmes\shared\ocrypto-11\tls.cpp (1017):
> TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes
> p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63):
> TestsTLS-11.exe!CltThread::Main() + 0xB bytes
> p:\mes programmes\shared\sthread.cpp (17):
> TestsTLS-11.exe!SThread::Run() + 0xE bytes
> f:\dd\vctools\crt\crtw32\startup\threadex.c (359):
> TestsTLS-11.exe!_threadstartex()
> 
> -- Block 4361 at 0x00647248: 64 bytes --
>   Leak Hash: 0x713FD291, Count: 1, Total 64 bytes
>   Call Stack (TID 2464):
> ntdll.dll!RtlAllocateHeap()
> f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc()
> + 0x15 bytes
> e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() +
> 0x9 bytes
> e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() +
> 0x11 bytes
> e:\openssl-1.1.git\crypto\lhash\lhash.c (118): TestsTLS-11.exe!lh_new()
> + 0xB bytes
> e:\openssl-1.1.git\crypto\err\err_lcl.h (2):
> TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes
> e:\openssl-1.1.git\crypto\err\err.c (321):
> TestsTLS-11.exe!int_thread_get() + 0xF bytes
> e:\openssl-1.1.git\crypto\err\err.c (369):
> TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes
> e:\openssl-1.1.git\crypto\err\err.c (884):
> TestsTLS-11.exe!ERR_get_state() + 0xC bytes
> e:\openssl-1.1.git\crypto\err\err.c (598):
> TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes
> e:\openssl-1.1.git\ssl\statem\statem.c (279):
> TestsTLS-11.exe!state_machine()
> e:\openssl-1.1.git\ssl\statem\statem.c (217):
> TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes
> e:\openssl-1.1.git\ssl\ssl_lib.c (2908):
> TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes
> p:\mes programmes\shared\ocrypto-11\tls.cpp (1017):
> TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes
> p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63):
> TestsTLS-11.exe!CltThread::Main() + 0xB bytes
> p:\mes programmes\shared\sthread.cpp (17):
> TestsTLS-11.exe!SThread::Run() + 0xE bytes
> f:\dd\vctools\crt\crtw32\startup\threadex.c (359):
> TestsTLS-11.exe!_threadstartex()
> 
> -- Block 4365 at 0x006472C8: 8 bytes --
>   Leak Hash: 0xFBE574AD, Count: 1, Total 8 bytes
>   Call Stack (TID 2464):
> ntdll.dll!RtlAllocateHeap()
> f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc()
> + 0x15 bytes
> e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() +
> 0x9 bytes
> e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() +
> 0x11 bytes
> e:\openssl-1.1.git\crypto\init.c (197):
> TestsTLS-11.exe!ossl_init_get_thread_local() + 0xB bytes
> e:\openssl-1.1.git\crypto\init.c (511):
> TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes
> e:\openssl-1.1.git\crypto\err\err.c (898):
> TestsTLS-11.exe!ERR_get_state() + 0x9 bytes
> e:\openssl-1.1.git\crypto\err\err.c (598):
> TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes
> e:\openssl-1.1.git\ssl\statem\statem.c (279):
> TestsTLS-11.exe!state_machine()
> e:\openssl-1.1.git\ssl\statem\statem.c (217):
> TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes
> e:\openssl-1.1.git\ssl\ssl_lib.c (2908):
> TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes
> p:\mes programmes\shared\ocrypto-11\tls.cpp (1017):
> TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes
> p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63):
> TestsTLS-11.exe!CltThread::Main() + 0xB bytes
> p:\mes programmes\shared\sthread.cpp (17):
> TestsTLS-11.exe!SThread::Run() + 0xE bytes
> f:\dd\vctools\crt\crtw32\startup\threadex.c (359):
> TestsTLS-11.exe!_threadstartex()
> 
> Visual Leak Detector detected 5 memory leaks (10757 bytes).
> Largest number used: 213916 bytes.
> Total allocations: 902180 bytes.
> Visual Leak Detector is now exiting.
> 
> -Message d'origine-
> De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Matt
> Caswell
> Envoyé : dimanche 14 février 2016 00:30
> À : openssl-dev@openssl.org
> Objet : Re: [openssl-dev] memory leaks detected using libSSL 1.1
> 
> Hmmm. It does look to me like there could be a memory leak here. What's not
> clear to me is to why you are only seeing this in 1.1 and not previous
> versions, as it looks like the same could happen in 1.0.2 as well!
> 
> Anyway, please try the attached patch to see if that helps.
> 
> Let me know how you get on.
> 
> Thanks
> 
> Matt
> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published

[Matt Caswell]

On 15/02/16 21:50, Jouni Malinen wrote:
> On Mon, Feb 15, 2016 at 09:34:33PM +0000, Matt Caswell wrote:
>> On 15/02/16 21:25, Jouni Malinen wrote:
>>> Is this change in OpenSSL behavior expected? Is it not allowed to call
>>> EVP_cleanup() and then re-initialize OpenSSL digests with
>>> SSL_library_init()?
>>
>> Correct, you cannot reinit once you have deinit.
> 
> OK.. That used to work, though, so it would be good to mention this
> clearly in the release notes since this can cause a difficult to find
> issues for existing programs. Luckily I happened to have automated test
> cases that found this now with wpa_supplicant.
> 
>> You should not need to explicitly init or deinit at all. Try removing
>> all such calls. If you are getting memory leaks not caused by your
>> application then that is a bug in OpenSSL.
> 
> I agree with the "should not need" part, but there is a reason why I
> added those calls in the first place, i.e., these were needed with older
> OpenSSL releases (well, all releases so far since 1.1.0 has not been
> released). I guess I can remove these calls with #ifdef
> OPENSSL_VERSION_NUMBER < 0x1010L to maintain support for older
> versions.
> 
> I'd also recommend updating EVP_cleanup man page to be clearer about
> EVP_cleanup() being something that must not be called if there is going
> to be any future calls to OpenSSL before the process exits.

Maybe EVP_cleanup() and other similar explicit deinit functions should
be deprecated, and do nothing in 1.1.0? The auto-deinit capability
should handle it. That way you would not need to do anything "special"
for 1.1.0 with "#ifdef" etc. What do you think?

If applications *must* do explicit cleanup they can always use the new
OPENSSL_cleanup() function (which is clear in the docs that you cannot
reinit afterwards).

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published

[Matt Caswell]

On 15/02/16 21:25, Jouni Malinen wrote:
> On Mon, Feb 15, 2016 at 10:52:27PM +0200, Jouni Malinen wrote:
>> On Mon, Feb 15, 2016 at 07:04:20PM +, OpenSSL wrote:
>>>OpenSSL version 1.1.0 pre release 3 (alpha)
> 
>> It looks like something in pre release 3 has changed behavior in a way
>> that results in SSL_CTX_new(SSLv23_method()) failing in some cases. I've
>> never seen this with earlier releases. It looks like the error within
>> SSL_CTX_new() is in EVP_get_digestbyname("ssl3-md5") returning NULL
>> suddenly after a process has called SSL_CTX_new() and SSL_CTX_free()
>> multiple times.
> 
> Found the trigger.. When adding and removing a network interface,
> wpa_supplicant ends up going through OpenSSL library init and deinit.
> One part of that deinit is a call to EVP_cleanup(). Init on the other
> hand is calling SSL_library_init(). The difference between pre release 2
> and 3 is in the SSL_library_init() call after EVP_cleanup() call not
> adding back the needed digest registration.
> 
> Is this change in OpenSSL behavior expected? Is it not allowed to call
> EVP_cleanup() and then re-initialize OpenSSL digests with
> SSL_library_init()?

Correct, you cannot reinit once you have deinit.

> 
> I can "fix" this by removing the EVP_cleanup() call in wpa_supplicant,
> but that does not sound like the best thing to do here since it was
> needed to avoid leaving allocated memory behind during process deinit
> (i.e., getting memory leak reports from valgrind).
> 
> The way the ossl_init_ssl_base() function is "hidden" within
> ssl_init.c, the application cannot even call it again, so other than
> duplicating the contents of that function after that EVP_cleanup() call,
> I don't see how this could be fixed cleanly without an OpenSSL change.
> 

You should not need to explicitly init or deinit at all. Try removing
all such calls. If you are getting memory leaks not caused by your
application then that is a bug in OpenSSL.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published

[Matt Caswell]

On 15/02/16 20:52, Jouni Malinen wrote:
> On Mon, Feb 15, 2016 at 07:04:20PM +, OpenSSL wrote:
>>OpenSSL version 1.1.0 pre release 3 (alpha)
>>
>>OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now
>>been made available. For details of changes and known issues see the
>>release notes at:
>>
>> http://www.openssl.org/news/openssl-1.1.0-notes.html
> 
> It looks like something in pre release 3 has changed behavior in a way
> that results in SSL_CTX_new(SSLv23_method()) failing in some cases. I've
> never seen this with earlier releases. It looks like the error within
> SSL_CTX_new() is in EVP_get_digestbyname("ssl3-md5") returning NULL
> suddenly after a process has called SSL_CTX_new() and SSL_CTX_free()
> multiple times.
> 
> Based on a git bisect between OpenSSL_1_1_0-pre2 and OpenSSL_1_1_0-pre3
> tags, it looks like the different behavior was triggered by commit
> 7fa792d14d06cdaca18f225b1d2d8daf8ed24fd7 ('Auto init/de-init libssl').
> That does add a call to
> OPENSSL_INIT_ssl_library_start(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL)
> within SSL_CTX_new(), so I guess this is somehow messing up the
> registered digests.
> 
> The program in question (wpa_supplicant) calls SSL_load_error_strings(),
> SSL_library_init(), EVP_add_digest(EVP_sha256()),
> EVP_add_cipher(EVP_rc2_40_cbc()), and PKCS12_PBE_add(), but commenting
> these out did not change anything for the issue.
> 
> I could not find anything related to this in the release notes either.
> 
> Is this a bug somewhere in pre release 3 or is there supposed to be some
> changes needed in applications using OpenSSL to work with this auto
> init/de-init libssl change?
>  
> 
Do you call EVP_cleanup() at any point between creating the SSL_CTX objects?

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Pipelining

[Matt Caswell]

I have just pushed to github some code that I have been working on to
implement a feature I have called "pipelining". This is still WIP,
although is fairly well advanced. I am keen to hear any feedback. You
can see the PR here:
https://github.com/openssl/openssl/pull/682

The idea is that some engines may be able to process multiple
simultaneous crypto operations. This capability could be utilised to
parallelise the processing of a single connection. For example a single
write could be split into multiple records and each one encrypted
independently and in parallel (this can only work in TLS1.1+ where we
get a new IV per record).

This initial version only provides pipelining for TLS (no DTLS at this
stage). Documentation still needs to be added (hence WIP).

It works similarly to how the existing MULTIBLOCK code works now. The
primary differences are that MULTIBLOCK only ever deals with batches of
4 or 8 records in one go and the engine is responsible for writing the
entire set of records including all the record headers. This means the
engine ciphers are TLS protocol specific. They couldn't ever be used for
DTLS and it doesn't make any sense to call them directly (i.e. not in
the context of a TLS connection).

The pipelining support is protocol agnostic and hence can be used for
TLS or directly via EVP. It is also much more flexible about the number
of pipelines that are used at any one time.

Two new SSL/SSL_CTX parameters can be used to control how this works in
the "write pipelining": max_pipelines and split_send_fragment.

max_pipelines defines the maximum number of pipelines that can ever be
used in one go for a single connection. It must always be less than or
equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only
one pipeline will be used (i.e. normal non-parallel operation).

split_send_fragment defines how data is split up into pipelines. The
number of pipelines used will be determined by the amount of data
provided to the SSL_write call divided by split_send_fragment.

For example if split_send_fragment is set to 2000 and max_pipelines is 4
then:
SSL_write called with 0-2000 bytes == 1 pipeline used
SSL_write called with 2001-4000 bytes == 2 pipelines used
SSL_write called with 4001-6000 bytes == 3 pipelines used
SSL_write called with 6001+ bytes == 4 pipelines used

split_send_fragment must always be less than or equal to
max_send_fragment. By default it is set to be equal to
max_send_fragment. This will mean that the same number of records will
always be created as would have been created in the non-parallel case,
although the data will be apportioned differently. In the parallel case
data will be spread equally between the pipelines.

Read pipelining is controlled in a slightly different way than with
write pipelining. While reading we are constrained by the number of
records that the peer (and the network) can provide to us in one go. The
more records we can get in one go the more opportunity we have to
parallelise the processing.

There are two parameters that affect this:
The number of pipelines that we are willing to process in one go. This
is controlled by max_pipelines (as for write pipelining)
The size of our read buffer. A subsequent commit will provide an API for
adjusting the size of the buffer.

Another requirement for this to work is that read_ahead must be set. The
read_ahead parameter will attempt to read as much data into our read
buffer as the network can provide. Without this set, data is read into
the read buffer on demand. Setting the max_pipelines parameter to a
value greater than 1 will automatically also turn read_ahead on.

Finally, the read pipelining as currently implemented will only
parallelise the processing of application data records. This would only
make a difference for renegotiation so is unlikely to have a significant
impact.

You need to have an engine that provides ciphers that support this. I
have updated the dasync engine to provide some suitable ciphers. I've
also added some arguments to s_client and s_server to support setting of
the split_send_fragment and max_pipelines variables for write
pipelining, and the size of the read buffer for read pipelining.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] memory leaks detected using libSSL 1.1

[Matt Caswell]

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 the new version, I first
> thought I forget some [new] init/free code.
> 
> I finally used OPENSSL_cleanup() and alikes instead of the previous
> litany calls ;-), but still encounters leaks.
> 
> As it was hard to track them down, I write a simple server test program
> that wait for a client and then return without even receiving data.
> 
> No certificate are loaded.
> 
> Leaks are detected only when a client handshake with the server.
> 
>  
> 
> I might be wrong, but I do not think this is a false positive.
> 
> Could you please have a look at the informations below and share your
> feelings ?

Hmmm. It does look to me like there could be a memory leak here. What's
not clear to me is to why you are only seeing this in 1.1 and not
previous versions, as it looks like the same could happen in 1.0.2 as well!

Anyway, please try the attached patch to see if that helps.

Let me know how you get on.

Thanks

Matt

>From a47094a928f56cb62d57d4b53f2e4e20f9a0a031 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Sat, 13 Feb 2016 23:22:45 +
Subject: [PATCH] Fix memory leaks in tls_decrypt_ticket

Certain code paths in tls_decrypt_ticket could return early without first
freeing the HMAC_CTX or the EVP_CIPHER_CTX.
---
 ssl/t1_lib.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index 522f0e6..0f6d51e 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -3048,7 +3048,7 @@ static int tls_decrypt_ticket(SSL *s, const unsigned char *etick,
 SSL_SESSION *sess;
 unsigned char *sdec;
 const unsigned char *p;
-int slen, mlen, renew_ticket = 0;
+int slen, mlen, renew_ticket = 0, ret = -1;
 unsigned char tick_hmac[EVP_MAX_MD_SIZE];
 HMAC_CTX *hctx = NULL;
 EVP_CIPHER_CTX *ctx;
@@ -3061,20 +3061,28 @@ static int tls_decrypt_ticket(SSL *s, const unsigned char *etick,
 if (hctx == NULL)
 return -2;
 ctx = EVP_CIPHER_CTX_new();
+if (ctx == NULL) {
+ret = -2;
+goto err;
+}
 if (tctx->tlsext_ticket_key_cb) {
 unsigned char *nctick = (unsigned char *)etick;
 int rv = tctx->tlsext_ticket_key_cb(s, nctick, nctick + 16,
 ctx, hctx, 0);
 if (rv < 0)
-return -1;
-if (rv == 0)
-return 2;
+goto err;
+if (rv == 0) {
+ret = 2;
+goto err;
+}
 if (rv == 2)
 renew_ticket = 1;
 } else {
 /* Check key name matches */
-if (memcmp(etick, tctx->tlsext_tick_key_name, 16))
-return 2;
+if (memcmp(etick, tctx->tlsext_tick_key_name, 16)) {
+ret = 2;
+goto err;
+}
 if (HMAC_Init_ex(hctx, tctx->tlsext_tick_hmac_key, 16,
  EVP_sha256(), NULL) <= 0
 || EVP_DecryptInit_ex(ctx, EVP_aes_128_cbc(), NULL,
@@ -3148,7 +3156,7 @@ static int tls_decrypt_ticket(SSL *s, const unsigned char *etick,
 err:
 EVP_CIPHER_CTX_free(ctx);
 HMAC_CTX_free(hctx);
-return -1;
+return ret;
 }
 
 /* Tables to translate from NIDs to TLS v1.2 ids */
-- 
2.5.0

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] openssl-SNAP-20160212 issue

[Matt Caswell]

On 12/02/16 14:31, The Doctor wrote:
> Here is another fix needed:
> 
> making all in ssl...
> gcc -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_EXPERIMENTAL_JPAKE 
> -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS 
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
> -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
> -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/contrib\"" 
> -DENGINESDIR="\"/usr/contrib/lib/engines\"" -fPIC  -pthread -D_THREAD_SAFE 
> -D_REENTRANT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 
> -march=i486 -Wall -g -c t1_trce.c -o t1_trce.o
> t1_trce.c: In function `ssl_get_keyex':
> t1_trce.c:923: `SSL_kECDHr' undeclared (first use in this function)
> t1_trce.c:923: (Each undeclared identifier is reported only once
> t1_trce.c:923: for each function it appears in.)
> t1_trce.c:927: `SSL_kECDHe' undeclared (first use in this function)
> t1_trce.c: In function `ssl_print_client_keyex':
> t1_trce.c:993: `SSL_kECDHr' undeclared (first use in this function)
> t1_trce.c:994: `SSL_kECDHe' undeclared (first use in this function)
> t1_trce.c: In function `ssl_print_server_keyex':
> t1_trce.c:1026: `SSL_kECDHr' undeclared (first use in this function)
> t1_trce.c:1027: `SSL_kECDHe' undeclared (first use in this function)
> *** Error code 1
> 
> Stop.
> *** Error code 1   
> 
> Please repair.
> 

This only happens if you use the enable-ssl-trace config option. It's
already fixed in current master.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Current master branch doesn't compile - fails "make depend"

[Matt Caswell]

On 10/02/16 16:46, Blumenthal, Uri - 0553 - MITLL wrote:
> The complete report is at https://github.com/openssl/openssl/issues/651
> 
> Configuration:
> 
> |$ ./Configure darwin64-x86_64-cc enable-rfc3779 enable-rc5 enable-md2
> enable-deprecated experimental-jpake threads zlib
> enable-ec_nistp_64_gcc_128 shared
> --prefix=/Users/ur20980/src/openssl-1.1
> --openssldir=/Users/ur20980/src/engines-1.1|
> 
> 
> The symptom:
> 
> |making depend in crypto... In file included from init.c:62:
> ../include/internal/conf.h:40:9: error: 'HEADER_INTERNAL_CONF_H' is used
> as a header guard here, followed by #define of a different macro
> [-Werror,-Wheader-guard] #ifndef HEADER_INTERNAL_CONF_H
> ^~ ../include/internal/conf.h:41:10: note:
> 'INTERNAL_CONF_H' is defined here; did you mean
> 'HEADER_INTERNAL_CONF_H'? # define INTERNAL_CONF_H ^~~
> HEADER_INTERNAL_CONF_H 1 error generated. make[1]: *** [depend] Error 1
> make: *** [depend] Error 1 $|

Richard just fixed this.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3824] FEATURE: Please provide a function to unintialize the library

[Matt Caswell via RT]

On Wed Apr 29 05:10:28 2015, noloa...@gmail.com wrote:
> This question crops up on occasion: How do you shutdown the OpenSSL
> library. See, for example:
>
> * "How to properly uninitialize OpenSSL",
> http://stackoverflow.com/questions/29845527/how-to-properly-
> uninitialize-openssl.
> * "Order of Cleanup to avoid memory leaks?",
> http://comments.gmane.org/gmane.comp.encryption.openssl.user/50784
>
> If you look at an answer like questions and answers
> http://comments.gmane.org/gmane.comp.encryption.openssl.user/50784,
> its non-trivial to get right. There were at least ***8*** cleanup
> calls, and 1 was still missed.
>
> In addition, there are some things that cannot be cleaned up because
> they are not accessible outside the library. For example:
>
> * ssl_comp_methods
> *
> https://rt.openssl.org/Ticket/Display.html?id=2561&user=guest&pass=guest
> *
> http://rt.openssl.org/Ticket/Display.html?id=2439&user=guest&pass=guest
> * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584968.
>
> Please provide a function to unintialize the library. I imagine it
> would be similar to SSL_library_init(). But rather than having it
> create things, it would cleanup things.

Done.

In fact master now auto-initialises and deinitialises so no explicit init or
cleanup is required at all in most cases. There are some exceptions - see the
OPENSSL_INIT_crypto_library_start() and OPENSSL_INIT_ssl_library_start() man
pages in the latest master. Where explicit init and deinit is required there is
now a single function for each.

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3824
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] SSL_R_HTTP_REQUEST no longer supported in 1.1.0

[Matt Caswell]

On 08/02/16 20:49, Rainer Jung wrote:
> The constant SSL_R_HTTP_REQUEST is still defined, but I can't find code
> that sets it and practical experiments indicate it is no longer set.
> 
> In Apache land we use it to detect "HTTP spoken on HTTPS port". OpenSSL
> 1.0.2 has code in ssl23_get_client_hello() that checks read bytes
> against "HEAD", "GET", "POST" etc. to detect this situation.
> 
> Was this feature removed intentionally

Well, kinda sorta. The whole version negotiation approach has been
completely rewritten. This made all of the ssl23* files redundant and so
they were deleted.

> or will it come back until the
> final 1.1.0 release?

Realistically I am unlikely to have time before feature freeze to add
this myself. I'd be happy to look at patches though.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] How to do reneg with client certs in 1.1.0 API

[Matt Caswell]

On 08/02/16 15:46, Viktor Dukhovni wrote:
> 
>> On Feb 8, 2016, at 9:49 AM, Matt Caswell  wrote:
>>
>> Actually, yes that is a good point. There could be some subtle security
>> issues there. You probably need to additionally check that you are not
>> halfway through a handshake:
>>
>> SSL_renegotiate(ssl);
>> SSL_do_handshake(ssl);
>> do {
>>read_some_app_data();
>>if(no_client_cert_yet() || SSL_in_init(ssl)) {
>>discard_app_data();
>>}
>> } while(no_client_cert_yet() || SSL_in_init(ssl));
> 
> Indeed, but discarding the data may not be an option,


Sure. I was answering the specific question posed by Tomas:

"What if the server wants to discard all the application data that was
sent before the renegotiation completed?"

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev