Thanks for your investigation and this PR!

I am somewhat torn about it though… Technically, golang.org/x/crypto/... are not a part of the standard library, and it's infeasible for GopherJS to maintain patches for arbitrary libraries that may not be compatible upstream. I can see an argument that golang.org/x has somewhat of a special status in the ecosystem, but we are currently not testing new releases against any of those libraries, so it is likely to regress in future.

In particular, the plans we had for #1021 had an explicit assumption that we only augment standard library sources. Third-party libraries may or may not be available at that stage and specific versions will depend on a particular project.

@flimzy @dmitshur do you have any thoughts?

@nevkontakte thanks for the response.

Imho an exception is necessary here. Our project is running on GopherJS, we invested quite heavily in this stack. As you said, x/crypto has a special status, it is treated kind of like the stdlib. Our code using this library used to work nicely until this issue came up.

but we are currently not testing new releases against any of those libraries, so it is likely to regress in future.

We could add this particular internal to the test suite, and add some tests exercising chacha20poly1305 , so it wouldn't regress.

It would be great if we could find a solution to this.

My thoughts, mostly off the top of my head, so I may be overlooking something:

1. For truly third-party packages, (i.e anything not in the stdlib and not in golang.org/x), the approach would be to ask the package maintainers to support GopherJS. I've had pretty good success with random third-party libraries accepting PRs to this end. I wonder if golang.org/x would be willing to do the same?
2. If we do decide we need to augment this, can it be done in a separate library? Can we maintain a gopherjs.org/x repo, for example, so as not to complicate the core GopherJS package?

@benma my primary concern here is that there are only two active GopherJS maintainers and both of us have very limited time we can dedicate to it. It is barely enough to keep up with the existing scope and taking on more maintenance burden will likely put us back into the state the project was for the previous couple of years. If your team is actively using GopherJS, would you be interested in contributing some of your time to the project? Having an active group of contributors would allow us to be more ambitious about how much we can support.

Besides that, there's also a technical problem to consider. A significant technical difference between golang.org/x and the actual standard library is that they are released separately. GopherJS releases are very tightly coupled with Go releases, so for every Go version a matching release of GopherJS must be used. The problem is that a user can use absolutely any version of golang.org/x/crypto libraries with any version of Go and GopherJS. That would require us to maintain and ship a whole set of patches for different versions of the library, and build some kind of new infrastructure to detect and apply the correct patch — build tags will no longer be enough.

Echoing @flimzy's comment, maybe we could submit a patch to golang.org/x/crypto instead?

Neither location is absolutely ideal. It's a patch that makes use of:

• internal GopherJS APIs (which may become different depending on GopherJS version)
• internal x/crypto APIs (which may become different depending on x/crypto version)

If added to GopherJS, then GopherJS maintainers need to keep up with x/crypto internal API changes. But if added to x/crypto, then x/crypto maintainers need to keep up with GopherJS internal API changes.

This is indeed tricky.

I was thinking that there could be a version of this patch that avoids pointer arithmetic, but also doesn't use GopherJS APIs. Or maybe we could try to improve GopherJS support for unsafe or reflect so that a patch wouldn't be necessary. I haven't looked at the surrounding code closely to tell for sure though.

I don't think that x/crypto is the right place to make changes - they should not be concerned with maintaining GopherJS compatibility, unless you can think of a trivial change that is not likely to regress on their end.

The problem is that a user can use absolutely any version of golang.org/x/crypto libraries with any version of Go and GopherJS.

While that is true, I don't see it as a great maintenance burden.

In my humble opinion, it wouldn't hurt to merge this PR as is, to make GopherJS work with x/crypto like it used to, and leave it at that. Chances are no new issues will come up, and if there will, we can cross the bridge when we get there.

Or maybe we could try to improve GopherJS support for unsafe or reflect so that a patch wouldn't be necessary. I haven't looked at the surrounding code closely to tell for sure though.

That would indeed be the best, but I am not familiar enough with the internals to judge if that is possible.

Ok, here's my plan then:

1. I'll wait until tomorrow on the off-chance that someone comes up with a better alternative.
2. If no suggestions are made until then, I'll merge this PR as-is to unblock @benma and his colleagues, but with a significant caveat.

The caveat: we are unable to guarantee that this fix will work in the long term. I'll try to find a few hours to look at x/crypto code and see if there may be a patch I could send upstream that would not rely on GopherJS internals, but avoid pointer arithmetics as well. If I succeed — great, if not the following will likely happen:

• The fix will exist as is, as long as it works.
• If we decide to go forward with Proposal: materialize augmented GOROOT on disk before building #1021 and we don't find a way to make this approach work with overlays for outside of the standard library, the fix will be removed from the overlays.
• We might set up a forked version of x/crypto as a substitute, if we find a reasonably automated way to keep it up to date with the upstream. Cryptography in particular is one of those domains where being out of date can be an actual vulnerability, so if we find no automated solution to maintain a fork under the gopherjs umbrella, it will be up to the community to create and maintain one.

@flimzy @dmitshur please let me know what you think of this plan.

Alright, since there don't seem to be any objections, I am merging this PR. Thanks all!

Thanks a lot!

For posterity, I've looked into options for implementing AnyOverlap() without reliance on pointer arithmetics, and unfortunately I can't see any that would be sufficiently reliable to submit upstream. I found a discussion in https://groups.google.com/g/golang-nuts/c/_Pj9S_Ljp9o, which proposes comparing addresses of the last element of the underlying array, but one of the messages states that this will no longer be reliable if golang/go#395 gets fixed, and it recently was.

So as dissatisfying as this might be, a fork is probably the only long-term option.