deprecate using GOPRIVATE in favor of GOGARBLE #427
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Piggybacking off of GOPRIVATE is great for a number of reasons: * People tend to obfuscate private code, whose package paths will generally be in GOPRIVATE already * Its meaning and syntax are well understood * It allows all the flexibility we need without adding our own env var or config option However, using GOPRIVATE directly has one main drawback. It's fairly common to also want to obfuscate public dependencies, to make the code in private packages even harder to follow. However, using "GOPRIVATE=*" will result in two main downsides: * GONOPROXY defaults to GOPRIVATE, so the proxy would be entirely disabled. Downloading modules, such as when adding or updating dependencies, or when the local cache is cold, can be less reliable. * GONOSUMDB defaults to GOPRIVATE, so the sumdb would be entirely disabled. Adding entries to go.sum, such as when adding or updating dependencies, can be less secure. We will continue to consume GOPRIVATE as a fallback, but we now expect users to set GOGARBLE instead. The new logic is documented in the README. While here, rewrite some uses of "private" with "to obfuscate", to make the code easier to follow and harder to misunderstand. Fixes burrowers#276.
|
I think while at it we should also change the default to obfuscate everything instead of only the current module. |
|
Hmm. I'd say it's too early for that - bugs like #410 are still relatively common. I think a requirement for that is to first implement #240, to have a very wide corpus of Go code that we know we can obfuscate at all times. I'd also prefer to do incremental steps. This is an incremental step to decouple "what packages to obfuscate" from "what packages are private". Swapping the default to be "obfuscate as many packages as possible" can be another incremental step in the future. |
lu4p
approved these changes
Dec 4, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(see commit message)