openssl: delete cgo-less experiment and promote to default

[gdams]

This is for go 1.27 and onwards

[github-actions]

Patch Consistency Review - Issues Found

I've reviewed PR #2106 for patch consistency and found 3 consistency issues that need to be addressed:

Summary of Changes

The PR is removing the ms_nocgo_opensslcrypto experiment and making CGO-less OpenSSL the default behavior on Linux for supported architectures. The patches 0002 and 0003 have been correctly updated to remove this experiment.

Issues Found

1. Patch 0001 (Vendor dependencies): Line 723 still references ms_nocgo_opensslcrypto in the telemetry configuration string. This needs to be removed to maintain consistency.

2. Migration Guide Documentation (lines 143 & 153): The documentation still mentions the experimental flag and suggests users enable it explicitly, which contradicts the PR's goal of making it the default behavior.

Impact

These inconsistencies could lead to:

• Incorrect telemetry data being collected for a non-existent experiment
• User confusion from outdated documentation that references a removed feature
• Mixed messaging about whether users need to explicitly enable CGO-less support

Recommendation

Please update:

1. The telemetry configuration in patch 0001 to remove the ms_nocgo_opensslcrypto reference
2. The MigrationGuide.md to reflect that CGO-less OpenSSL is now the default on supported architectures and no longer requires explicit enablement

I've added specific inline comments on each location that needs attention. The core patch changes (0002 and 0003) look good and are internally consistent with each other.

AI generated by Patch Consistency Review Agent

[gdams]

The telemetry configuration in patch 0001 to remove the ms_nocgo_opensslcrypto reference

This is part of the go-infra package so we can't remove this here. I also don't think it makes sense to remove it from go-infra for now as we need it for Go 1.26.

The MigrationGuide.md to reflect that CGO-less OpenSSL is now the default on supported architectures and no longer requires explicit enablement

I've tried to get the balance right in the migration guide, considering that most users will be running Go 1.26 so mentioning the experiment still makes sense.

[dagood]

It's not clear to me on an initial read, but based on this, is the plan to use cgo if cgo happens to be enabled for some other reason, and use cgoless if cgo isn't enabled globally? What if someone wants to use cgo e.g. because they're targeting a different platform? Or if they don't want to use cgo for the backend, but do want to use it for their own C library they're using?

What are the current limitations of the cgoless implementation? Are there performance differences, functional differences (even if slight)?

Worth an ADR to explore?

[qmuntal]

is the plan to use cgo if cgo happens to be enabled for some other reason, and use cgoless if cgo isn't enabled globally

Yes. This fact needs to be better documented, probably as part of this PR @gdams.

What if someone wants to use cgo e.g. because they're targeting a different platform? Or if they don't want to use cgo for the backend, but do want to use it for their own C library they're using?

Mixing cgo with cgoless OpenSSL is possible, but I don't see why someone would want to do that, and that means more testing and complexity on our side.

What are the current limitations of the cgoless implementation? Are there performance differences, functional differences (even if slight)?

This also needs to be documented. There are some few limitations and differences that I want to smooth out before Go 1.27.

Worth an ADR to explore?

I should have made an ADR for all this enchilada one year ago. IMO it is a bit late now, we should focus instead on writing good docs.

[gdams]

I've updated the docs to explain this slighlt more clearly

[dagood]

We talked about this in sync, and a feature doc sounds good. (IMO it can serve just fine as the de-facto Record of our Architecture Decision. 🙂) We also talked about potentially adding a dedicated roadmap somewhere, which could take pressure off this cgoless doc potentially having to explain the whole rollout plan.

[dagood]

The telemetry configuration in patch 0001 to remove the ms_nocgo_opensslcrypto reference

This is part of the go-infra package so we can't remove this here. I also don't think it makes sense to remove it from go-infra for now as we need it for Go 1.26.

I think the agent needs to be taught that it shouldn't pay attention to vendored Go code in general.

[qmuntal]

I think the agent needs to be taught that it shouldn't pay attention to vendored Go code in general.

The comment from the agent was useful to me, it surfaced the need to update the telemetry configuration at some point in the future. The recommendation is wrong, that's true, we don't want to do it now.

[github-actions]

Patch Consistency Review Summary

I've reviewed the patch file changes in this PR, which promotes the cgo-less OpenSSL implementation from an experimental feature (ms_nocgo_opensslcrypto) to the default behavior on Linux.

Changes Overview

The PR makes consistent changes across:

• Patch 0002: Removes the ms_nocgo_opensslcrypto experiment definition files
• Patch 0003: Simplifies build tags from goexperiment.opensslcrypto && (cgo || goexperiment.ms_nocgo_opensslcrypto) to just goexperiment.opensslcrypto
• Documentation & Pipeline Config: Updates to reflect the new default behavior

Issue Found

There is one inconsistency that needs to be addressed:

Patch 0001 (Vendor patch) still contains a reference to ms_nocgo_opensslcrypto in the telemetry counter configuration. I've left an inline comment on the specific line that needs updating.

Recommendation

Please update the telemetry configuration in patch 0001 to remove the ms_nocgo_opensslcrypto reference to maintain consistency across all patches.

AI generated by Patch Consistency Review Agent

[dagood]

Split the line for reading/scanning clarity--put the version noticeably at left edge.

Suggested change

	> In Go 1.26, there is a cgo-less experiment available for Linux: `ms_nocgo_opensslcrypto`. For Go 1.27 this experiment will be removed and the cgo requirement for `systemcrypto` on Linux will be lifted by default.
	> In Go 1.26, there is a cgo-less experiment available for Linux: `ms_nocgo_opensslcrypto`.
	>
	> In Go 1.27, the experiment will be removed and the cgo requirement for `systemcrypto` on Linux will be lifted by default.
	>

[dagood]

This should be in its own doc IMO and linked from here as a "for more details". As long as this selection is done properly and there are no feature/perf gaps, it seems to me that it will "just work" and the vast majority reading this doc don't need the details.

[dagood]

I don't think we use caps for emphasis normally?

Suggested change

	> The cgo-less backend is only used when cgo is disabled AND you're on a supported architecture.
	> The cgo-less backend is only used when cgo is disabled **and** you're on a supported architecture.

[dagood]

Why would you enable cgo for cross-compiling for a different platform?

[dagood]

I might be forgetting a convention, but isn't it bad/unexpected to have a file named openssl_linux.go that doesn't have a linux build tag? (And does this really imply that we have Windows/macOS/etc. support here?)

[dagood]

Leave out .. Some shells' URL parsers could probably handle it to make it clickable without breaking the URL, but not all. It might also be manually copy-pasted by selection, and it's easier to do that when there aren't adjacent garbage characters.

Also, branch is wrong.

Suggested change

	+ For more information, including how to request support for additional architectures, visit https://github.com/microsoft/go/blob/main/eng/doc/MigrationGuide.md#cgo-is-not-enabled.
	+ For more information, including how to request support for additional architectures, visit https://github.com/microsoft/go/blob/microsoft/main/eng/doc/MigrationGuide.md#cgo-is-not-enabled