@claui Maybe you want to review this PR?

Upstream PR commit sha has changed due to a commit message typo fix, I kept the old patch commit here to avoid rebuild.

As this is openssl, we also want to be extra careful with patches if they have not been merged upstream.
We all know this is critical software; and we do not want to introduce subtle security bugs, so we need a clear GO from upstream.

If this change is never backported to 1.1.1, I think we need to gather more opinions if we want to bypass openssl's decision at the package manager level.

@iMichka I fully understand your concerns, however the code has been used for a long time on iOS 64-Bit ports of OpenSSL and only adds a build target. It has also already been accepted in master, the decision for 1.1.1 is mainly based on wether this is a bugfix or a feature, so it is a policy question.

Updated to use PR openssl/openssl#12369 from the prior work by @stuartcarnie as the source for the patch (Thanks!).
The actual changes are identical.

I'm currently working with upstream to get the patch merged into OpenSSL 1.1.1 stable, which requires a vote by the OMC (OpenSSL Management Comittee?), since adding new platforms to a stable/LTS release is usually not allowed.

The proposal has not yet been submitted, but is visible here: https://gist.github.com/ee30b5c8f52e030629dc2de95f81d8b1

Any comments welcome, but if they are for the proposal, please post them on the gist not here.

For the discussion leading up to the proposal see the upstream PR I mentioned in my previous comment.

The patch has little risk, has been okayed on technical grounds by upstream, but is being held from a backport on policy reasons. I don't have an objection to shipping it in Homebrew, but I wonder: the current formula is not broken, it simply builds without any assembly code, and is therefore slower. But does the extra bit of performance really warrant including the patch?

Let's hold off on patching openssl until upstream decides one way or another.

Status Update:

The proposal has been posted to the openssl-project mailing list and feedback will be gathered for a few days:

https://mta.openssl.org/pipermail/openssl-project/2020-November/002457.html

After this feedback phase a formal vote will be raised with the OMC through @mattcaswell, who has been kind enough to offer his help in this regard and guide me in the formal process.

@fxcoudert wrote:

But does the extra bit of performance really warrant including the patch?

We're talking about 30x speedup for AES-128 GCM, the most popular compression codec for HTTPS and about 40x speedup for AES-128 CTR used for ssh and scp, so yes it is very important.

Without the patch you're much better off using the x86_64 versions through Rosetta 2, which reach about 65% of the performance of the ARMv8 assembly.

There is also the ongoing discussion that non-hardware accelerated implementations of AES-GCM are vulnerable to side-channel attacks, so we should probably avoid that.

The OMC vote has started.

When will the vote finish? I can't build Ruby on my M1 machine without using this patch

When will the vote finish? I can't build Ruby on my M1 machine without using this patch

OMC votes take a maximum of 2 weeks. But normally they are much quicker.

When will the vote finish? I can't build Ruby on my M1 machine without using this patch

You can, but TLS throughput will be lower. You can also install the outstanding PR:

brew reinstall https://raw.githubusercontent.com/Homebrew/homebrew-core/243cf2359686117fd93dfde3c7f0fede3b5d5423/Formula/openssl%401.1.rb

Upstream has approved the PR, so unblocking here. I have removed the revision line (since we have not shipped ARM nor support it for now), rebased and pushed so testing can start anew.

Testing passed on 10.14, some unrelated conflicts/linkage issues for which I am opening PRs. Merging without bottles, as it affects only ARM.