Skip to main content

Module policy_forbidden_strings

Module policy_forbidden_strings 

Source
Expand description

The optional forbidden-strings policy over the linked scanner, with redacted findings. What: The optional security/forbidden-strings policy: scan every candidate’s exact bytes and pathname through the linked scanner and report each match, redacted. Why: The installed wrapper wrote candidate bytes to temporary files, started the scanner executable and parsed its standard error. Here the same scanner is a library: rules are loaded once per invocation, only when a candidate can be scanned, and each finding carries the scanner’s masked display path and an opaque rule name, never the matched text. A scan that could not complete ends the policy with the code of its cause, never as a clean result.

In TS you’d write (pseudocode):

// const findings = await scanCandidates({ builtinRules, repositoryRoot, candidates });

Structs§

ScannerSettings
What: Where the rules come from: the policy’s options and the value of FORBIDDEN_STRINGS_RULES in the invocation’s environment. Why: The lifecycle reads both once; the check resolves them against the repository root only when it scans.
ScannerState
What: The scanner of one invocation, loaded on first use, or the remembered failure. Why: Rules are loaded once per invocation and only when a candidate needs scanning.

Constants§

ENGINE_ERROR_MESSAGE
The engine-failure message of a scan a matcher could not complete.
FORBIDDEN_STRING_CODE
The policy-local code of a match.
LINE_BREAK_MESSAGE
The engine-failure message of a pathname the line-based scanner cannot inspect.

Functions§

check_forbidden_strings
What: Scan every candidate the scanner is given and report each match. &ScannerSettings borrows where the rules come from; &mut ScannerState lends the invocation’s scanner. Why: Deleted candidates, the rule sources and the rules file itself are not scanned, as the installed wrapper skips them. When nothing is left, no rules are loaded, so a missing rules file stops nothing that would not have been scanned.
default_scanner_settings
What: Settings with the default options and no variable. Why: A lifecycle that loads no configuration and has no candidates never scans.
unloaded_scanner
What: A state that has loaded nothing. Why: Loading waits until a candidate can be scanned.