-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: cmd/go: make GOTELEMETRY settable like other env vars #69113
Comments
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
Thanks for filing this proposal following our discussion in #68960. Regarding the two implementation options in your proposal, I think we should focus on the first (separating "local" data vs "on" data). The fact that we keep track of the time that telemetry was enabled is really an artifact of the current implementation, where the telemetry mode is stored in a user-global configuration file that is independent of process environment. Preserving some notion of a start time in the per-process environment seems unnecessarily complex. The current design went through a lengthy internal review, public discussion, and public proposal process (#58894), as did the To be clear, I don't think we'd have to revisit everything that has been discussed, but want to emphasize that the cost of implementing this proposal would not be technical: any change to the way telemetry data is stored or the way that telemetry is enabled would have to be scrutinized, especially if the change makes it even marginally easier to enable telemetry uploading, which I think this proposal does. |
Improved understandability, consistency, simplicity, and security. When working with the telemetry configuration for the first time, I was confused by how it worked. I wrote an email to golang-nuts that described that confusion:
According to the error messages, GOTELEMETRY wasn't even a known go command variable. Users shouldn't have to explore with trial and error to discover for themselves how configuration works. GOTELEMETRY is listed as an environment variable, and the user is supposed to be able to set it to on/off/local as they please, yet you can't set it with a process environment variable or The Go 1 compatibility promise doesn't cover tooling, IIRC. Making GOTELEMETRY a normal env var wouldn't break compatibility anyway; all it would do is render the
It seems like a security footgun that a user can ignorantly or accidentally do In #68960 (comment), I wrote:
So I would ask for the argument for why the severity of accidentally GOTELEMETRY=on is greater than that of accidentally setting GODEBUG=execerrdot=0. I don't see how the severity is greater. If the severity is the same or less, then I don't see a problem. |
Also, as I mentioned in #68960 (comment):
|
The time to have this discussion was before Go 1.23. This ship has sailed, and it sailed to |
This proposal has been declined as infeasible. |
Proposal Details
go env
,go env -w
,go env -u
, andgo env -changed
should work with GOTELEMETRY like other settable env vars.GOTELEMETRY should be inherited from the process env, like other env vars.
To do this, GOTELEMETRY=on data should be put in a separate place than GOTELEMETRY=local data, so that processes with GOTELEMETRY=on in their env know that it's always safe to upload GOTELEMETRY=on data, without needing an extra timestamp stored somewhere to separate the two types of data.
Alternatively, if GOTELEMETRY=on and GOTELEMETRY=local data aren't separated, then a separate GOTELEMETRYSTART env var should be added to specify the cut-off timestamp that separates the two types of data. If GOTELEMETRY="on", but GOTELEMETRYSTART="", then telemetry is disabled. When
go env -w GOTELEMETRY=on
is run, thengo env -w GOTELEMETRYSTART=$now
is run under the hood for the user.Filing per #68960 (comment).
The text was updated successfully, but these errors were encountered: