Parse .gitignore

[Kurt-von-Laven]

Summary

It would be ideal to respect .gitignore by default, ignoring the same files that Git does.

Motivation

Files that match patterns in .gitignore are unlikely to be committed to the repository, which is what Secretlint intends to prevent when it detects secrets. Presently, one generally has to duplicate .gitignore in .secretlintignore unless they are identical, in which case one can configure Secretlint to use .gitignore directly.

[azu]

Does --secretlintignore flag resolve this issue?

secretlint --secretlintignore .gitignore

📝 Serceretlint does not lookup .gitignore file. This behavior mimic ESLint behavior. There are not strong reason. https://eslint.org/docs/user-guide/configuring/ignoring-code#using-an-alternate-file

[azu]

If secretlint look up .gitignore by default, we need to think following cases.

• How to disable ignoring behavior?
  • Probably, we may need to add --no-secretlintignore flag
• Which is correct behavior if There are both(.gitignore and .secretlintignore)?
  • Merge both or Select one

Current behavior is redundant, but it is simple.

[Kurt-von-Laven]

Does --secretlintignore flag resolve this issue?

No, that is what I meant by:

[...] unless they are identical, in which case one can configure Secretlint to use .gitignore directly.

The feature request pertains primarily to the case where they are not identical (e.g., because there is at least one version-controlled file that Secretlint should ignore).

Probably, we may need to add --no-secretlintignore flag

Yes, there would probably need to be a flag to not ignore the files listed in .gitignore, although I doubt it would be much used, and I don't find the name --no-secretlintignore intuitive personally.

Which is correct behavior if There are both(.gitignore and .secretlintignore)?

I favor the two files being merged if both are present, and without that I don't think the feature would have enough value to be worthwhile. I would apply .gitignore first and then .secretlintignore so that the latter could override the former.

I don't mean to single out Secretlint. I would argue this is a pain point of most tools that use an ignore file (mainly in large projects where the redundancy grows more cumbersome). jscpd, Mega-Linter, and Super-Linter are examples of tools that support ignoring the same files Git ignores. (Incidentally, when running Mega-Linter or Super-Linter, jscpd tends to pick up duplication between all the various redundant ignore files a project uses.)

[azu]

Thank for details!

I agree with you basically, but there are some edge case.

I favor the two files being merged if both are present, and without that I don't think the feature would have enough value to be worthwhile.

I am careful Merging. I think that gitignore and secretlintignore has some difference points.

• There may difference behavior because implementation is difference
  • However, I do not know actual compatible issue
• gitignore can be cascading, but secrelintignore can not be cascading

.gitignore - A
.secretlintignore -A
a-dir/
  - .gitignore - B
  - .secretlintignore - B

git merge A and B, but secretlint does not merge A and B. secretlint only use <cwd>/.secretlintignore.

Cacading is complex, so I have not implemented it.

[Kurt-von-Laven]

Good points! I would say that it is separately desirable to adopt the same semantics as .gitignore, because I suspect many people make the mistake of assuming this equivalence anyways. I have not tested it, but go-gitignore looks promising. I wonder if they would accept some feature requests to do all of the hard work here since it looks like they already offer much of what would be needed. It also seems tedious for each project with its own ignore file to have to reinvent the wheel.

[Kurt-von-Laven]

Actually, I think the simplest thing to do would be to only support this feature when Git is installed, and run: git-check-ignore. That would just leave the merging to implement.

[sanmai-NL]

I think it's not wise to partly or fully equate .gitignore with .secretlintignore. Should any secret be committed that is covered by .gitignore, then that secret won't be detected. The whole point of the secrets leak risk is that they can inadvertently end up under version control. Indeed, only a few lines pertaining to secret files from the .gitignore should be included in .secretlintignore.

[azu]

@sanmai-NL I agree. It is reasonable.

I think that respecting .gitignore is opt-in feature. I close this issue, and open new issue.

• https://github.com/secretlint/secretlint/issues/337