Description
Note
This proposal has been changed to implement loadSystemRoots in crypto/x509, as the p11-kit trust module can only provide anchors, and cannot verify as initially proposed.
For farther details #71799 (comment)
Proposal Details
Developers are creating desktop-class applications with Go using toolkits such as Fyne and Gio, and are providing these applications to users via Flatpak. Users may install certificates into their system trust store for many reasons (including but not limited to man-in-the-middle debugging, redirecting requests to alternative servers, and—yes, also—draconian IT policies). Go on the host will automatically pickup these anchors in crypto/x509. However, applications running in a Flatpak are isolated from the host system and Flatpak does not copy the host certificates into the isolated environment. Instead, the expectation is application use the p11-kit Trust Policy Module which forwards trust anchors from the host.1 From flatpak/flatpak#2721 (comment):
Closing this as not Flatpak's bug.
What is now meant to happen is that apps (or the SSL/TLS libraries used by apps) should use p11-kit as their trust store. If they do that, then they will automatically pick up a socket forwarded by Flatpak from the host system, and trust whatever certificates the host trusts. If they do not do that, then that's a bug (or at least a limitation) in that app or the SSL/TLS library that it uses, and not a bug in Flatpak itself.
I would like to see crypto/x509 be extended on Unix:
- Support delegating verification to p11-kit socket as the implementation for the (internal)
systemVerifyused byx509.Certificate.Verify. - A
GODEBUGtoggle, such asx509p11kit=(0|1), which can allow this to be selectively disabled or enabled, and defaulted by an application.
Go already implements similar behavior on macOS, iOS, and Windows where certificate verification is delegated to the operating system for system CertPools. On all other Unix platforms systemVerify currently returns nil and certificates are verified only by the loaded certificate files.
The communication between Go and the system verifier would be an RPC over the p11-kit socket in the runtime directory or defined by environment variable P11_KIT_SERVER_ADDRESS2, rather than a dlopen over the p11-kit-client shared library. There is previous work implementing this RPC in module github.com/google/go-p11-kit.
While this proposal focuses on p11-kit in the context of delegating certificate validation in Flatpak, it is a separate project and can be used outside of Flatpak, and use could be extended in future proposals to sign with HSMs.
x509.Certificates.Verify
The documentation for x509.Certificates.Verify already denotes that a system verify may be used, so no documentation change would be necessary.
If opts.Roots is nil, the platform verifier might be used, and verification details might differ from what is described below. If system roots are unavailable the returned error will be of type SystemRootsError.
However, the requirement of returning error if system verifiers are unavailable should be soften, as Go can fallback to the current behavior.
x509.SystemCertPool
The documentation for x509.SystemCertPool current documents a difference for macOS:
On Unix systems other than macOS the environment variables SSL_CERT_FILE and SSL_CERT_DIR can be used to override the system default locations for the SSL certificate file and SSL certificate files directory, respectively.
This documentation is missing the current behavior for iOS and no note is provided for Windows. Nevertheless, this proposal would add that system verifiers may be used on Unix and when doing so these environment variables would be ignored. A note could be updated to something similar to:
When not delegating to system verifies, the environment variables SSL_CERT_FILE and SSL_CERT_DIR can be used to override the system default locations for the SSL certificate file and SSL certificate files directory, respectively.
Footnotes
-
Flatpak environments ship configuration for OpenSSL, GnuTLS, and NSS to verify with the p11-kit socket described herein. ↩
-
The upstream p11-kit C library checks the
P11_KIT_SERVER_ADDRESSenvironment variable first in its autodiscovery mechanism. It is also documented in the Forwarding docs. It falls back to determining a runtime directory if the environment variable is unset. ↩
Metadata
Metadata
Assignees
Labels
Type
Projects
Status