Port OpenSSL backend to go1.19

[qmuntal]

This PR ports the OpenSSL backend from dev.boringbranch into main following the same generic backend strategy as in previous Go versions.

Upstream Go did several refactors to how BoringCrypto was being integrated into crypto. Our port can leverage almost all work done upstream, except for the following issues:

• AES and ECDSA keys are cached using a runtime-backed map which does not allocate. The map implementation is located in crypto/internal/boring, and we can't depend on it, so I've copy-pasted the relevant files into crypto/internal/backend/bcache and updated the runtime package to back this new package. See https://groups.google.com/g/golang-dev/c/h6iFPvOnPkg for more context.
• The whole crypto/internal/boring API is now free of big.Int. It instead crypto/internal/boring.BigInt and a helper package to cast from big.Int to boring.BigInt located at crypto/internal/boring/bbig. As we can't depend on crypto/internal/boring.BigInt, I've created a bidge package at crypto/internal/backend/bbig which implements the casts to the right BigInt type:
  • If build flag goexperiment.boringcrypto is set, it uses crypto/internal/boring/bbig.
  • If build flag goexperiment.opensslcrypto is set, it github.com/microsoft/go-crypto-openssl/openssl/bbig.
    See Remove math/big and encoding/asn1 deps from openssl package go-crypto-openssl#26 for more context.
• TestAllocations test from crypto/ed25519 has been disabled when goexperiment.opensslcrypto is set. boring.Enabled is not known at compile time when using OpenSSL backend, as it can be encabled/disabled at runtime, so there are some optimizations that the compiler skip, which make us allocate more even if boring.Enabled==false

[dagood]

Changes LGTM, just a couple comments about the patch arrangement.

[dagood]

Hmm, when I see this, my first thought is that it might belong in the first patch so it's clearer that this is part of a file move. I think Git would also count that as a rename so it would also make the diff clearer (the package name change).

But I remember the idea here is that first patch is add-only (avoiding conflicts), making this deletion part of integration.

Maintenance-wise, I think this might cause a problem down the line. If upstream adds a fix to this file, we'll hit a conflict in this patch, and whoever's resolving it needs to know to not only resolve the conflict in this patch, but also go back to the first patch and redo copying src/crypto/internal/boring/cache.go to src/crypto/internal/backend/bcache/cache.go. It seems like it might be easy to miss and end up not getting the upstream fix in our build.

I think a reasonable middle ground is to split the deletion into a "cleanup" patch file (before or after the integration patch) with a clear description that conflicts need to ported back to the first patch. We don't have a mechanism for it yet, but we could also add a patch test in the outer repo that makes sure the copy is always the same (other than package name).

But actually, I think it might be best to put both the add and remove into the same patch file before even adding the OpenSSL crypto module. Basically, design the patch so that we could even submit it to upstream if they're willing to help us out with https://groups.google.com/g/golang-dev/c/h6iFPvOnPkg. (Maybe it's not quite that simple--the dir structure we want might be different than what upstream would take?) Then, we can simply zap the patch file if upstream merges the change. In the meantime, merge conflicts should be easy to resolve.

[qmuntal]

I like the idea of putting this change into its own file. It will also be clearer which refinements we are doing to existing boring package for the sake of reusability.

[qmuntal]

Done! Git does count it as a rename, so we saved almost 500 lines of diffs and future headaches if the original files we changed 😄

[dagood]

Should the command from the old summary get copied over here?

go/patches/0102-Vendor-OpenSSL-crypto-library.patch

Lines 4 to 7 in 669b2bd

	Subject: [PATCH] Vendor OpenSSL crypto library
	To reproduce, run 'go mod vendor' in 'go/src'.
	---

More generally about these summaries: I don't think we need to be concerned about including big descriptions for each patch in the initial PR. But, I think we should probably plan to include more in the future, especially as we start to collaborate with other Go distro maintainers. It seems to me like the natural place for people to look to start understanding what we've done.

[qmuntal]

Done! Agree that we should have a small description in each patch, but let's do it in another PR :)

[dagood]

I noticed some changes from https://github.com/microsoft/go/blob/microsoft/dev.boringcrypto.go1.18/patches/0103-Adjust-Go-tests-to-work-with-crypto-module.patch aren't in here. If they're not necessary anymore, that's great, but in case the issues come up in CI, figured I should point it out. 😄

[qmuntal]

Good catch, I wanted to run the CI without those changes just in case they are not needed anymore, but I'll probably end up adding them 😋