You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's well-established that tartufo will examine configuration files in the target repository in order to parameterize a scan, but it is not possible to specify what version of those files actually get used. I polled my team regarding this behavior and they regard it as a bug rather than a feature. Basically:
tartufo scan-remote-repo uses the configuration that is in the "default" branch of the repository (i.e. the one that is checked out by default when a clone operation completes)
tartufo scan-local-repo uses the configuration that is current in the local working directory (which might well be the "default" branch in the context of a CICD workflow)
Using the --branch option has no effect on this behavior -- it controls only which commits are scanned
An additional parameter, such as --config-branch foo, should be provided to address the use case elaborated below.
To Reproduce
Pick any arbitrary repository that has been configured to use tartufo
Create a new branch (such as "test") and check it out
Create a file with a forbidden expression or a high-entropy string
Commit the file
tartufo scan-local-repo . will report an issue
Add the exclusion to the configuration file (i.e. pyproject.toml)
Commit the configuration file
tartufo scan-local-repo . will not report the issue
Check out a different branch (for example, main)
tartufo scan-local-repo . reports the issue
tartufo scan-local-repo --branch test . reports the issue (use the branch created above)
Although the configuration is properly updated in the repository, it is ignored unless it happens to be in the current branch.
Expected Behavior
It should be possible to scan a repository using the configuration in a specified branch. This behavior should be independent of the decision to restrict the scope of a scan to a particular branch (with --branch).
In particular, if I have a new branch that contains both "false-positive" issues and exclusions permitting them, it should be possible to specify that branch for configuration retrieval and perform a full-repository scan which passes, instead of spuriously failing because configuration from a different branch was chosen outside of my control.
The text was updated successfully, but these errors were encountered:
🐛 Bug Report
It's well-established that tartufo will examine configuration files in the target repository in order to parameterize a scan, but it is not possible to specify what version of those files actually get used. I polled my team regarding this behavior and they regard it as a bug rather than a feature. Basically:
tartufo scan-remote-repo
uses the configuration that is in the "default" branch of the repository (i.e. the one that is checked out by default when a clone operation completes)tartufo scan-local-repo
uses the configuration that is current in the local working directory (which might well be the "default" branch in the context of a CICD workflow)--branch
option has no effect on this behavior -- it controls only which commits are scannedAn additional parameter, such as
--config-branch foo
, should be provided to address the use case elaborated below.To Reproduce
tartufo scan-local-repo .
will report an issuetartufo scan-local-repo .
will not report the issuetartufo scan-local-repo .
reports the issuetartufo scan-local-repo --branch test .
reports the issue (use the branch created above)Although the configuration is properly updated in the repository, it is ignored unless it happens to be in the current branch.
Expected Behavior
It should be possible to scan a repository using the configuration in a specified branch. This behavior should be independent of the decision to restrict the scope of a scan to a particular branch (with
--branch
).In particular, if I have a new branch that contains both "false-positive" issues and exclusions permitting them, it should be possible to specify that branch for configuration retrieval and perform a full-repository scan which passes, instead of spuriously failing because configuration from a different branch was chosen outside of my control.
The text was updated successfully, but these errors were encountered: