Clarify file separator to be used in `filePath` suppressions

[kwin]

In https://dependency-check.github.io/DependencyCheck/general/suppression.html there are some example to suppress by filePath. For example

<filePath>c:\path\to\some.jar</filePath>

However it is unclear how to use a relative file path (leveraging regex) in an OS agnostic way. Which file separator can/should be used? Is forward slash also supported on Windows? At the same time it would be nice if relative file paths are supported (and which path they should be relative to).

[chadlwilson]

PRs are accepted. Any reason you can’t just try it out?

There’s really no such thing as an OS “agnostic” absolute path due to drive lettering (just dodgy slash and drive translation) and IIRC relative path matching is probably best handled with regex. Or avoid path matching at all, and uses hashes or exclusions.

In the meantime, suggest you look at how the paths are serialized in your ODC json or html report and use that. Since the examples already show that you can use a regex, you can do so to create a slash-agnostic relative path.

[kwin]

Let me rephrase, IIUC the code is not normalizing file paths (

DependencyCheck/core/src/main/java/org/owasp/dependencycheck/xml/suppression/PropertyType.java

Line 112 in a9c835d

public boolean matches(String text) {

and

DependencyCheck/core/src/main/java/org/owasp/dependencycheck/xml/suppression/SuppressionRule.java

Line 564 in a9c835d

if (filePath != null && !filePath.matches(dependency.getFilePath())) {

). It uses the Dependency's filePath as set in

DependencyCheck/core/src/main/java/org/owasp/dependencycheck/dependency/Dependency.java

Line 207 in a9c835d

this.actualFilePath = file.getAbsolutePath();

which uses File.getAbsoluteFilePath() which is

1. absolute and
2. filesystem specific

Both factors make it hard to come up with OS agnostic suppression file.

I would say that in order to be able to use suppression rules among different OSes leveraging filePath there should be:

• a normalized file path used for comparison (using forward slashes only)
• it should be relativized to the current working directory if located within (depending on the context, e.g. in Maven plugin relative to the project basedir)

In order to be backwards compatible one would probably need to introduce a new suppression element like normalizedFilePath.

[chadlwilson]

No it is not normalizing them - and I would argue there is no good way to actually do that - and instead there are many attempts (across cygwin/mysys/ant path syntax/ruby etc etc), which are all inconsistent and all have gotchas.

I am instead trying to explain that absolute paths still need to be supported and thus trying to come up with an OS agnostic path suppression syntax is not a valid goal, outside of using regex (which is already possible).

if you start trying to support both absolute and relative, especially with slash replacements, things become ambiguous

• now you need to change the schema to allow specifying whether the path is absolute or relative to remove the ambiguity caused by C:\ (or is it /c/? or c:/ ?) What happens with Windows UNC paths like \\Server\path?)
• paths inside archives (tars/jars etc) become even more ambiguous as to how they should be denoted.

What's the actual problem with using regexes as I noted above? It's already possible to do what you ask, so I see no reason anyone would want to make it more complex and open a can of worms that pushes complexity to ODC - when suppression by path is likely not a recommended approach in the first place, and need for OS agnostic path suppressions is surely an edge case.

<filePath regex="true">.*[/\\]path[/\\]to[/\\]some\.jar</filePath>

Anyway, are you asking for the documentation to be improved, or an enhancement? You started by asking a question, and now you're arguing the tool needs new capabilities. Seems like this is more appropriate as a discussion than an issue?

[kwin]

Let's only track the documentation with this. I raised #8354 for this. For additional improvement I will raise a discussion first. Thanks.