fix: only use packaged hosted suppression file if using the default URL

[jeremylong]

resolves #8478

[chadlwilson]

Can you replicate the issue as described? I cannot....

This doesn't seem entirely desirable to me - but maybe it highlights a different issue. Won't it disable all of the suppressions which we migrated from base -> hosted on the assumption that they will be included in snapshots? These would lead to people reporting false positives whenever they use a custom URL (even if it's a proxy) because they are now missing a chunk of suppressions that are actually distributed with ODC but not inside the "legacy" base suppressions file.

This will be very difficult to reason about for support purposes. When reviewing i expect people to have at least base + last-release-hosted so I can ask people to upgrade or update their hsited suppressions.

In my opinion, the logic to use the hosted suppression snapshot file should not be guarded behind hosted.suppressions.enabled either - in my view these are essentially a second set of base suppressions that happen to be from a different file and I don't think its good that users can override/remove them due to the reasons above. ODC doesn't allow people to disable "normal" base suppressions does it?

I think users should only be able to disable the remote sourcing of suppressions, not the use of the snapshotted suppressions, since these are no different to our maintained base suppressions which are "part of the product".

[chadlwilson]

Additionally, is it actually the goal of setting a custom hosted suppression url to override/remove a whole chunk of our curated suppressions? It seems to me it's supposed to be for pass through proxies or caches of our curated ones, not for what seems to be done in #8478 as a way to source extra user suppressions from a remote URL?

[jeremylong]

I've been testing several things with this - I created this PR too quickly while I was still testing. Closing this now as things appear to be working as expected.

[chadlwilson]

Ahh ok. It’s possible there is something weird happening here in certain sequence of events, I just can’t quite recreate the problem as described right now.

If you agree that we should generally “always include/consider/load the snapshot suppressions if the file can be loaded from within in the jar, as per the legacy/base suppressions” I might look at a change to alter this a bit so the “enabled” flag only guards the remote retrieval and the two sources are dealt with more independently so configuration for the remote data source (enabled, url etc) doesn’t interact with the snapshotted version.

If possible. 😅

[cpfeiffer]

To give a bit of context, we're using a hosted suppressions file in order to quickly fix false positives among many similar projects. We pull your curated publishedSuppressions.xml and extend that with our own suppressions.

[jeremylong]

you don't need to use the hosted suppression file. just configure a normal suppression file.