Improve naming of methods to add arguments to git calls #22592
Conversation
delvh
added
type/refactoring
GiteaBot
added
the
lgtm/need 2
GiteaBot
added
lgtm/need 1
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
GiteaBot
added
lgtm/done
| // AddTrustedArguments adds new git argument(s) to the command. | ||
| // Each argument must be safe to be trusted, so only string literals should be passed. | ||
| // User-provided arguments should be passed to AddUntrustedArguments instead. | ||
| func (c *Command) AddTrustedArguments(args ...CmdArg) *Command { |
There was a problem hiding this comment.
- That's not true:
so only string literals should be passed. - Why I didn't choose
AddTrustedArguments: it could be misleading. For example, there are codes like:cmd.AddTrustedArguments("-c", CmdArg("user.name="+opts.Committer.Name): is theCommiterNametrusted or not?cmd.AddTrustedArguments(CmdArg("--prefix=" + filepath.Base(strings.TrimSuffix(repo.Path, ".git")) + "/")): is the generated path trusted?
There was a problem hiding this comment.
but I think in these calls you're declaring that you believe that "user.name="+opts.Committer.Name is a safe and trustworthy argument that does not need further checking by git.Command.
There was a problem hiding this comment.
2 is just my worry about the readability.
Trusted is a very strong word, it could lead to misunderstand more easliy.
And, using AddTrustedArguments could also have other problems (the comment below).
|
To answer the question in the table:
It's clear that it only accepts literal string or Even after this PR's change, ps: In mind mind at that time, I was trying to name the argument type by Although I didn't take it at that time (due to the long-name), however now, maybe it seems good to have The framework should do its best to avoid low-level mistakes like #22098 (comment) , make the mistakes more noticeable for reviewers. ps: there are still some things to do to improve the git module, for example: hide the |
|
My plan was Now here it is. |
…22678) This PR follows #21535 (and replace #22592) ## Review without space diff https://github.com/go-gitea/gitea/pull/22678/files?diff=split&w=1 ## Purpose of this PR 1. Make git module command completely safe (risky user inputs won't be passed as argument option anymore) 2. Avoid low-level mistakes like #22098 (comment) 3. Remove deprecated and dirty `CmdArgCheck` function, hide the `CmdArg` type 4. Simplify code when using git command ## The main idea of this PR * Move the `git.CmdArg` to the `internal` package, then no other package except `git` could use it. Then developers could never do `AddArguments(git.CmdArg(userInput))` any more. * Introduce `git.ToTrustedCmdArgs`, it's for user-provided and already trusted arguments. It's only used in a few cases, for example: use git arguments from config file, help unit test with some arguments. * Introduce `AddOptionValues` and `AddOptionFormat`, they make code more clear and simple: * Before: `AddArguments("-m").AddDynamicArguments(message)` * After: `AddOptionValues("-m", message)` * - * Before: `AddArguments(git.CmdArg(fmt.Sprintf("--author='%s <%s>'", sig.Name, sig.Email)))` * After: `AddOptionFormat("--author='%s <%s>'", sig.Name, sig.Email)` ## FAQ ### Why these changes were not done in #21535 ? #21535 is mainly a search&replace, it did its best to not change too much logic. Making the framework better needs a lot of changes, so this separate PR is needed as the second step. ### The naming of `AddOptionXxx` According to git's manual, the `--xxx` part is called `option`. ### How can it guarantee that `internal.CmdArg` won't be not misused? Go's specification guarantees that. Trying to access other package's internal package causes compilation error. And, `golangci-lint` also denies the git/internal package. Only the `git/command.go` can use it carefully. ### There is still a `ToTrustedCmdArgs`, will it still allow developers to make mistakes and pass untrusted arguments? Generally speaking, no. Because when using `ToTrustedCmdArgs`, the code will be very complex (see the changes for examples). Then developers and reviewers can know that something might be unreasonable. ### Why there was a `CmdArgCheck` and why it's removed? At the moment of #21535, to reduce unnecessary changes, `CmdArgCheck` was introduced as a hacky patch. Now, almost all code could be written as `cmd := NewCommand(); cmd.AddXxx(...)`, then there is no need for `CmdArgCheck` anymore. ### Why many codes for `signArg == ""` is deleted? Because in the old code, `signArg` could never be empty string, it's either `-S[key-id]` or `--no-gpg-sign`. So the `signArg == ""` is just dead code. --------- Co-authored-by: Lunny Xiao <[email protected]>
|
replaced by #22678 |
AddDynamicArgumentsAddUntrustedArgumentsAddArgumentsAddTrustedArgumentsWith this, we can ensure that all commands use the correct method to prevent security issues:
String literals should be added using
AddTrustedArguments, the rest usingAddUntrustedArguments.The only remaining question is what is better: The old name for
AddTrustedArgumentsas it is significantly shorter and hence stands out more in comparison toAddUntrustedArguments, or the new name which clarifies its purpose better?