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

[mattyjones]

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]

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]

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 https://github.com/N0MoreSecr3ts/wraith/pull/139#issuecomment-1229307850 - 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]

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]

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