Skip to content
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

If the number of commits is set to 1, the scans do not function properly. #71

Open
mattyjones opened this issue Sep 18, 2020 · 4 comments
Labels
Bug Something isn't working Discovery How the secrets are found Hacktoberfest Hacktoberfest specific issues

Comments

@mattyjones
Copy link
Collaborator

mattyjones commented Sep 18, 2020

If you set the number of commits to 1 in either a config file or on the command line, it will not scan anything. I am not sure why yet.

@mattyjones mattyjones added Bug Something isn't working Discovery How the secrets are found Hacktoberfest Hacktoberfest specific issues labels Sep 18, 2020
@mattyjones mattyjones added this to the Milestone 1 milestone Sep 23, 2020
@mattyjones
Copy link
Collaborator Author

A cheap way to fix this in the meantime would be to do a local scan for this condition and then switch to a repo scan.

In the long run the code should be refactored to handle this condition automatically.

@shreyas-sriram
Copy link
Contributor

Did some digging around this.

Wraith steps for this scan scenario

  1. Clone repo until commit-depth 1
  2. Traverse through the commits
  3. Get changes (diff) from the parentCommitTree and commitTree (GetChanges())
  4. Look for secrets

The problem lies in Step 3 when the changes are being fetched. Since the repository is cloned only for 1 commit, the parent commit is not present and hence attempts to fetch the details of the parent commit (code) fails.

Although the commitHash of the parent is known, the Commit object itself is unknown.

Another issue discovered

When there are no parent commits, wraith attempts to create a dummy commit using CommitObject() (code).

However, this fails because the hash used (4b825dc642cb6eb9a060e54bf8d69288fbee4904) is not a valid commit in this repository and the function throws "object not found". Function description is given below.

// CommitObject return a Commit with the given hash. If not found
// plumbing.ErrObjectNotFound is returned.
func (r *Repository) CommitObject(h plumbing.Hash) (*object.Commit, error) {...}

This also explains the issue mentioned in #139 (comment) - there is not parent commit for the initial commit.

Possible solutions

  1. Clone x + 1 commits (in this case, 2) and stop scans when commit-depth is reached (this still fails for initial commit)
  2. Find a different way to create a dummy commit or commitTree (sample solution)

@mattyjones
Copy link
Collaborator Author

I may break this out but I found an issue where the command line flag --commit-depth does not work. The default and config file work just fine in the correct order. The command line flag should overide everything but it never even get seen. It will default to to all other values for some reason.

@shreyas-sriram
Copy link
Contributor

I cannot reproduce this issue locally. commit-depth seems to be parsed and overwritten in the correct priority - default -> config file -> CLI args.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working Discovery How the secrets are found Hacktoberfest Hacktoberfest specific issues
Projects
Status: 🏗 In progress
Development

No branches or pull requests

2 participants