feat: swap to using the git CLI directly #14
Conversation
|
✅ Code Quality
|
![datadog-datadog-prod-us1[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
| // Returns the files changed in the given commit, along with their contents | ||
| // Deleted files will have an empty value | ||
| func (r *Repository) changedFiles(commit string) (map[string][]byte, error) { | ||
| cmd := exec.Command("git", "diff-tree", "--no-commit-id", "--name-status", "-r", commit) |
There was a problem hiding this comment.
🔴 High: Code Vulnerability
Check command call and ensure there is no unsanitized data used. The variable `commit` may need to be validated (...read more)
In Go, the exec.Command function is used to run external commands. Using this function carelessly can lead to command injection vulnerabilities. Carefully review the data flow that leads to a command execution and ensures no data can be injected by a third-party.
Command injection occurs when untrusted input is passed directly to a system shell, allowing an attacker to execute arbitrary commands. This can result in unauthorized access to the system, data leaks, or other security breaches.
Avoid executing commands constructed using user-provided data, or if you must, always validate and sanitize user inputs before passing them to exec.Command.
How to remediate?
Either remove the user-controlled data, filter the potential command with a list of allowed command or sanitize the command before execution.
There was a problem hiding this comment.
Commit hashes are validated in the calling function.
|
|
||
| diff, err := ptree.Diff(tree) | ||
| func (r *Repository) catfile(commit string) ([]string, string, string, error) { | ||
| cmd := exec.Command("git", "cat-file", "commit", commit) |
There was a problem hiding this comment.
🔴 High: Code Vulnerability
Check command call and ensure there is no unsanitized data used. The variable `commit` may need to be validated (...read more)
In Go, the exec.Command function is used to run external commands. Using this function carelessly can lead to command injection vulnerabilities. Carefully review the data flow that leads to a command execution and ensures no data can be injected by a third-party.
Command injection occurs when untrusted input is passed directly to a system shell, allowing an attacker to execute arbitrary commands. This can result in unauthorized access to the system, data leaks, or other security breaches.
Avoid executing commands constructed using user-provided data, or if you must, always validate and sanitize user inputs before passing them to exec.Command.
How to remediate?
Either remove the user-controlled data, filter the potential command with a list of allowed command or sanitize the command before execution.
There was a problem hiding this comment.
Commit hashes are validated in the calling function.
This patch replaces `git-go` with calls directly to the `git` CLI. While it's not ideal to depend on a subprocess, the fact is that using `git-go` required a lot of lines of code for simple operations, and often disagreed with `git` on a local repository (which wasn't reproducible outside of a CI environment). The `git` CLI commands in-use in this patch are all "plumbing" (versus "porcelain") commands which generally have stable output: they are designed explicitly for machine consumption.
| // Returns the files changed in the given commit, along with their contents | ||
| // Deleted files will have an empty value | ||
| func (r *Repository) changedFiles(commit string) (map[string][]byte, error) { | ||
| cmd := exec.Command("git", "diff-tree", "--no-commit-id", "--name-status", "-r", commit) |
There was a problem hiding this comment.
🔴 High: Code Vulnerability
Check command call and ensure there is no unsanitized data used. The variable `commit` may need to be validated (...read more)
In Go, the exec.Command function is used to run external commands. Using this function carelessly can lead to command injection vulnerabilities. Carefully review the data flow that leads to a command execution and ensures no data can be injected by a third-party.
Command injection occurs when untrusted input is passed directly to a system shell, allowing an attacker to execute arbitrary commands. This can result in unauthorized access to the system, data leaks, or other security breaches.
Avoid executing commands constructed using user-provided data, or if you must, always validate and sanitize user inputs before passing them to exec.Command.
How to remediate?
Either remove the user-controlled data, filter the potential command with a list of allowed command or sanitize the command before execution.
There was a problem hiding this comment.
Commit hashes are validated in the calling function.
|
|
||
| diff, err := ptree.Diff(tree) | ||
| func (r *Repository) catfile(commit string) ([]string, string, string, error) { | ||
| cmd := exec.Command("git", "cat-file", "commit", commit) |
There was a problem hiding this comment.
🔴 High: Code Vulnerability
Check command call and ensure there is no unsanitized data used. The variable `commit` may need to be validated (...read more)
In Go, the exec.Command function is used to run external commands. Using this function carelessly can lead to command injection vulnerabilities. Carefully review the data flow that leads to a command execution and ensures no data can be injected by a third-party.
Command injection occurs when untrusted input is passed directly to a system shell, allowing an attacker to execute arbitrary commands. This can result in unauthorized access to the system, data leaks, or other security breaches.
Avoid executing commands constructed using user-provided data, or if you must, always validate and sanitize user inputs before passing them to exec.Command.
How to remediate?
Either remove the user-controlled data, filter the potential command with a list of allowed command or sanitize the command before execution.
There was a problem hiding this comment.
Commit hashes are validated in the calling function.
This patch replaces
git-gowith calls directly to thegitCLI. While it's not ideal to depend on a subprocess, the fact is that usinggit-gorequired a lot of lines of code for simple operations, and often disagreed withgiton a local repository (which wasn't reproducible outside of a CI environment).The
gitCLI commands in-use in this patch are all "plumbing" (versus "porcelain") commands which generally have stable output: they are designed explicitly for machine consumption.