nscuro
commented
6 days ago I knew people were abusing PURLs, but exceeding even 786 characters is new to me :laughing:
Note, we might need some custom pre-flight checks after schema validation, but before dispatching the BOM for asynchronous processing, that check for DT-specific limitations like this.
Another offender could be components having an empty name field, which the CycloneDX schema currently does not cover: https://github.com/CycloneDX/specification/issues/461
Will need to keep in mind that uploaded BOMs can be large, so repeated parsing will cause significant overhead. Either we find a way to parse once, and re-use that across schema- and custom validation, or the custom validation needs to make use of streaming, similar to https://github.com/DependencyTrack/dependency-track/blob/44aa924425ae6e085994bebd10c0ac3cab339919/src/main/java/org/dependencytrack/parser/cyclonedx/CycloneDxValidator.java#L126-L135
Current Behavior
When uploading a BOM file containing PURL addresses that exceed the 786-characters limit, the upload fails and is logged as an error.
_stacktrace: javax.jdo.JDOFatalUserException: Attempt to store value "..." in column ""PURL"" that has maximum length of 786. Please correct your data!
However, the message "BOM uploaded" can be misleading, as it suggests that the BOM upload was successful. When using the /v1/bom REST API, a success status code (200) is returned without any error message, which can cause confusion.
Steps to Reproduce
Expected Behavior
Return an error message indicating that the PURL addresses exceed the 786-character limit
Dependency-Track Version
4.11.4
Dependency-Track Distribution
Container Image
Database Server
PostgreSQL
Database Server Version
15.5
Browser
Google Chrome
Checklist