feat: Extend authentication to support Bearer token for many resources

[aikebah]

Description of Change

Builds on top of the changes of #7255 that added pre-emptive basic authentication, so should be merged after that.

Adds HTTP Bearer authentication configuration possibility for

• NVD API Datafeed
• Known Exploited Vulnerabilities mirror site
• User suppression files
• Hosted Suppressions File mirror site
• RetireJS Repo mirror site
• Central Content URL mirror site
• Central Search URL mirror site

Adds HTTP Basic authentication configuration possibility for:

• Known Exploited Vulnerabilities (CLI/Maven)
• Hosted Suppressions File mirror site (Ant/CLI/Maven)
• User suppression files (Ant/CLI)
• Central Search URL mirror site (CLI)

Related issues

• fixes Download of suppression files with authorization header #5783
• fixes authentication credentials for hostedSuppressionsUrl #5387
• fixes Authenticate with Google cloud storage bucket #6826
• fixes Not being able to authenticate for central.content.url and analyzer.central.url #7093

Have test cases been added to cover the new functionality?

no - as testcases would require live endpoints that host the various files behind a HTTP Basic- or HTTP Bearer authentication.

[aikebah]

Awaiting merge of #7255 before looking into the reported merge conflicts

[aikebah]

@jeremylong let me know if you'd rather have this merged into the branch of #7255 to then merge both in one go into main

[jeremylong]

I've approved #7255 - feel free to merge it. See #7255 (comment)

[jeremylong]

LGTM - thanks for moving some of the Ant configuration from Check to Update where it should have been.

[jeremylong]

Looks like an NPE in the test?

[aikebah]

Not sure how that suddenly surfaced, was convinced I've run a full build even with the latest fixes, but apparently not. The fixup of the last commit is what currently makes it break.

Looking into its root cause (testcase fails to .configure(Settings settings) the Downloader before triggering code that uses parts of the Downloader that access the settings).

I think the Downloader singleton initialisation within the various bootstraps would best be changed to a Downloader cached by the Engine and initialized during Engine construction. In practice it would be the same as a singleton (as there would typically only a single engine instance), but it would allow for correct behaviour in case of multiple engine instances with different settings running in the JVM and would require no special care in the testcases.

[aikebah]

diff --git a/core/src/test/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzerTest.java b/core/src/test/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzerTest.java
index 36009f597..33c656ba9 100644
--- a/core/src/test/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzerTest.java
+++ b/core/src/test/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzerTest.java
@@ -32,6 +32,7 @@ import org.owasp.dependencycheck.Engine.Mode;
 import org.owasp.dependencycheck.analyzer.exception.AnalysisException;
 import org.owasp.dependencycheck.dependency.Dependency;
 import org.owasp.dependencycheck.exception.InitializationException;
+import org.owasp.dependencycheck.utils.Downloader;
 import org.owasp.dependencycheck.utils.Settings;
 import org.owasp.dependencycheck.utils.Settings.KEYS;
 import org.owasp.dependencycheck.xml.suppression.SuppressionRule;
@@ -152,6 +153,7 @@ public class AbstractSuppressionAnalyzerTest extends BaseTest {
         getSettings().setString(KEYS.SUPPRESSION_FILE, path);
         final AbstractSuppressionAnalyzerImpl fileAnalyzer = new AbstractSuppressionAnalyzerImpl();
         fileAnalyzer.initialize(getSettings());
+        Downloader.getInstance().configure(getSettings());
         Engine engine = new Engine(Mode.EVIDENCE_COLLECTION, getSettings());
         fileAnalyzer.prepare(engine);
         int count = AbstractSuppressionAnalyzer.getRuleCount(engine);

Would solve the symptom, but I think it's better to solve it by going from singleton to managed-by-engine downloader instance. @jeremylong WDYT?

[aikebah]

I experimented a bit to take the root-cause way and make the downloader managed by the engine, but encountered so many places where the downloader (or the engine) would need to passed downwards on calls (and/or cached in local fields) that I think fixing up the testcase to initialize the singleton is the better approach.

[jeremylong]

LGTM

[aikebah]

@jeremylong Have you already started integrating this (new configuration parameters) into the gradle plugin? Or shall I make a start with updating that?

[jeremylong]

I havent started, but the changes should be simple. If you don’t get to it, I'll update it closer to the release

…

On Wed, Jan 1, 2025, 10:07 AM Hans Aikema ***@***.***> wrote: @jeremylong <https://github.com/jeremylong> Have you already started integrating this (new configuration parameters) into the gradle plugin? Or shall I make a start with updating that? — Reply to this email directly, view it on GitHub <#7277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGSVQVCU3V6QTPIKEIQE7L2IQAEFAVCNFSM6AAAAABUMXVGY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRXGA2DGNZYHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>