SPDX expression support improvements

[nscuro]

Description

Building upon #2400, this PR adds missing functionality for setting license expressions via REST API, and adds expression validation for both REST API and BOM ingestion.

Invalid expressions submitted via frontend or REST API will result in an API error, whereas invalid expressions encountered during BOM ingestion will be logged and skipped.

Addressed Issue

N/A

Additional Details

N/A

Checklist

• I have read and understand the contributing guidelines
• This PR fixes a defect, and I have provided tests to verify that the fix is effective
• This PR implements an enhancement, and I have provided tests to verify that it works as intended
• This PR introduces changes to the database model, and I have added corresponding update logic
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[hborchardt]

Thanks for following up on this, and making improvements where I was lacking knowledge about the framework's capabilities or intricacies 🚀

[melba-lopez]

Thanks for following up on this, and making improvements where I was lacking knowledge about the framework's capabilities or intricacies 🚀

Thank you @hborchardt for contributing what you have been able to! Sometimes we don't get enough time or have the knowledge (im sure you can reference my PR thats been open for eons now 😸 )

[melba-lopez]

i see this is being changed from notification size >= 5 ... to 6. Is this a 1 to 1 mapping with duration of seconds? @nscuro

[nscuro]

It's an inconsistency in assertions that I noticed while debugging another issue with this test.

This statement is waiting for 6 (previously 5) notifications to be sent, and will wait up to 5 seconds for this to happen.
It's more or less a means of ensuring all asynchronous processing has completed before doing further assertions.

The actual notification content is being asserted later in the test:

dependency-track/src/test/java/org/dependencytrack/tasks/BomUploadProcessingTaskTest.java

Lines 155 to 170 in 06168eb

	assertThat(NOTIFICATIONS).satisfiesExactly(
	n -> assertThat(n.getGroup()).isEqualTo(NotificationGroup.PROJECT_CREATED.name()),
	n -> assertThat(n.getGroup()).isEqualTo(NotificationGroup.BOM_CONSUMED.name()),
	n -> assertThat(n.getGroup()).isEqualTo(NotificationGroup.BOM_PROCESSED.name()),
	n -> {
	assertThat(n.getGroup()).isEqualTo(NotificationGroup.NEW_VULNERABILITY.name());
	NewVulnerabilityIdentified nvi = (NewVulnerabilityIdentified) n.getSubject();
	assertThat(nvi.getVulnerabilityAnalysisLevel().equals(VulnerabilityAnalysisLevel.BOM_UPLOAD_ANALYSIS));
	},
	n -> {
	assertThat(n.getGroup()).isEqualTo(NotificationGroup.NEW_VULNERABILITY.name());
	NewVulnerabilityIdentified nvi = (NewVulnerabilityIdentified) n.getSubject();
	assertThat(nvi.getVulnerabilityAnalysisLevel().toString().equals(VulnerabilityAnalysisLevel.BOM_UPLOAD_ANALYSIS));
	},
	n -> assertThat(n.getGroup()).isEqualTo(NotificationGroup.NEW_VULNERABLE_DEPENDENCY.name())
	);

I noticed that the above assertion is checking for 6 notifications, not just 5... :D

[melba-lopez]

if this is a test to upload a bom that is of SPDX, should we include appropriate spdx nomenclature outside of just the license? I suspect if someone uploads an SPDX bom, they would want that information to stay when downloading it too.

[nscuro]

SPDX BOMs are not supported at all right now; Uploads of such BOMs will be rejected. We have #1746 open, but doesn't look like we're going to address that anytime soon.

For this change, we just want to ensure that SPDX license expressions within a CDX BOM are correctly ingested.

[melba-lopez]

🤦‍♀️ for various reasons we discussed... i swear it was! Thanks for bringing me back to reality 😺

[melba-lopez]

@nscuro 👨‍💻 guru! awesome changes in such a short amount of time. I had 2 comments that could be easy for you to answer/address. Hopefully you can take a look before merging!