Add digital signature to envoy.exe windows artifacts.

[RameshKandukuriB]

As a envoy-proxy windows user, I want the binaries (envoy.exe) to be digitally signed with the version number, description & other information so that I can deploy in production with a valid digital signature.

[davinci26]

cc @envoyproxy/windows-dev

[wrowe]

There is specific logic within bazel for stamped deps. It's an additional link step implemented
differently on linux vs. macOS, and needing a unique implementation on Windows. Embedding
that in the .rc/.res file and linking the .res to the binary object is pretty obvious, and we can
pursue this. You can grep on build_id for what envoy is doing today.

Self-signing the binary with an untrusted secret (known only to the core CI maintainers and the
build pipeline) is fairly straightforward, if time consuming. That secret would exist throughout
the envoy releases,

Signing with a trusted secret is much more complex. Last I checked, signing certs are never
issued to a "department" or "project", but to an organization. In this case, the CNCF. We will
need to go through the exercise of determining what binaries are successfully signed by the
CNCF and how to coordinate that code signing cert in a secure manner, and if this hasn't
been done before, work through k8s sig-windows to agree on a group policy.

One obvious question, are all builds signed? Including CI pipeline pull-request builds?
Or only the GA release builds? I'd think signing all pipeline builds is very unwise.

[dlorenc]

Ref #14076

[wrowe]

Ref #14076

To clarify, package signatures are unrelated to this ask for Code Signed executables.

The GPG ascii armored signature for a tarball is generated and attached after the fact and can be done independently of the CI. The code signing of a binary artifact is an attached signature embedded in the binary and is prepared on the target build environment, and then replaces any earlier unsigned binary artifact.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[RameshKandukuriB]

"help wanted" / "no stalebot"

[wrowe]

At this time, the CNCF isn't in a position to "certify" binary results; the releases the CNCF produces are source code which are compiled by any number of parties.

The "Envoy Project" binaries will not be signed for the time being; if you pick up the binary result from a partner of the project, those binaries may be signed by the corresponding organization.

[wrowe]

Since there is current interest in this topic, and we are reassessing whether CNCF the organization now has this capacity for signing or would be interested in contracting it out, reopening for the time being.

[wrowe]

There are a host of questions about signed packages. Package signing isn't at all related to Windows Code Signing. This needs to be handled 100% independently (and Windows builders might also appreciate signed source packages just as on linux.)

One space the CNCF has wanted code signing is device drivers or code running at kernel layer (where this is actually close to an absolute requirement), but most CNCF projects target userspace deployment and code isolation, so it hasn't bee a priority. What's happened historically is that vendors re-spin Windows binaries under their own org's code signing cert.