Open BrianKopp opened 1 year ago
Here's the expected behavior:
> ripsecrets && echo "no secrets found"
no secrets found
> ripsecrets --strict-ignore && echo "no secrets found"
no secrets found
> ripsecrets --strict-ignore test.txt && echo "no secrets found"
no secrets found
Notably, running ripsecrets --strict-ignore test.txt && echo "no secrets found"
should not fail, since --strict-ignore
means that test.txt
should get ignored even though it was passed in as a CLI argument. Any time the behavior of --strict-ignore
changes depending on whether the [secrets]
section is present is a bug.
This might have been fixed in this commit (https://github.com/sirwart/ripsecrets/commit/cce91ae1f38d18381e823eac61fd6bd749853519). Could you try building from source and see if the issue is still present? If so then I just need to build a new binary.
Hi sirwart! Thanks for the reply! You're correct. The latest code on main does produce that expected behavior!
Hi there! First off, thanks for this awesome tool!
I'm seeing some unexpected / inconsistent behavior where secrets files are being sometimes being ignored, based on whether the
[secrets]
section is present in the.secretsignore
file.Setup:
So when using normally, with no positional file/directory specified, it comes back exit code 0. But when the file is provided as a positional argument, it comes back with a failure.
But, if we add a
[secrets]
tag to the.secretsignore
file, then the command comes back with exit code 0.I think this is because in
src/find_secrets.rs
, it conditionally ignores the explicitly provided files only if there's aignore_matcher.is_some()
(permalink), which looks like it's coming fromignore_info.rs
behind this conditional.Is this expected behavior? If not, I'm happy to contribute a fix!
Thanks again! Cheers!