DependencyTrack / DependencyTrack/dependency-track

BOM upload fails without feedback due to field max length

Open
#1,665 8 comments 4 reactions 0 assignees View on GitHub
defect
Dominant language
Java
Stars
4.2k
Forks
811
Avg merge
8h 39m
Merged PRs (30d)
237

Description

A BOM file that contains a component with a "publisher" field with more than 255 character fails due to the constraints of the field. However, there is no feedback or way to know that the BOM upload failed other than figuring it out from the log file.

### Current Behavior:
When uploading a broken BOM file (see bom-broken.xml in [bom-broken.zip](https://github.com/DependencyTrack/dependency-track/files/8788432/bom-broken.zip)), no components will be loaded, and there is no way to see that the BOM processing failed outside the log file. See "Additional Details" section for the stacktrace.

I manually created the BOM file to only include the broken component, however, this is how https://github.com/CycloneDX/cyclonedx-dotnet would generate the component for Hangfire.PostgreSql@1.9.6.

### Steps to Reproduce:
- Create a BOM file with a component that has a publisher value of more than 255 characters
-- Or use the bom-broken.xml in [bom-broken.zip](https://github.com/DependencyTrack/dependency-track/files/8788432/bom-broken.zip)
- Upload the BOM file to Dependency Track manually in a test project
- Note that no errors are raised, and no components are loaded

To test that the issue is with the publisher field, simply truncate the field in the XML file and reupload it to Dependency Track. The component should appear correctly in the Components tab.

### Expected Behavior:
I expect one of 2 behaviors:
1. The BOM processing should succeed and limits put on fields should be removed unless explicitly stated by the CycloneDX specification
2. There should be a way to see that the BOM processing failed in the frontend, especially when uploaded manually

I think option 1 is better than option 2. The restriction makes it a problem for using automation as there is no way to predict if a component will break Dependency Track. Since the specification does not contain restrictions on field lengths, Dependency Track should not enforce arbitrary ones.

### Environment:

- Dependency-Track Version: 4.4.2 and 4.5.0
- Distribution: Docker
- BOM Format & Version: XML 1.3
- Database Server: PostgreSQL (but should apply to all)
- Browser: Chrome 100.0.4896.127

### Additional Details:
DT stacktrace
```
2022-05-27 16:37:25,861 [] ERROR [org.dependencytrack.tasks.BomUploadProcessingTask] Error while processing bom
javax.jdo.JDOFatalUserException: Attempt to store value "Frank Hommers and others (Burhan Irmikci (barhun), Zachary Sims(zsims), kgamecarter, Stafford Williams (staff0rd), briangweber, Viktor Svyatokha (ahydrax), Christopher Dresel (Dresel), Vytautas Kasparavičius (vytautask), Vincent Vrijburg, David Roth (davidroth)." in column "PUBLISHER" that has maximum length of 255. Please correct your data!
at org.datanucleus.api.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:615)
at org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:720)
at org.datanucleus.api.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:740)
at alpine.persistence.AbstractAlpineQueryManager.persist(AbstractAlpineQueryManager.java:417)
at org.dependencytrack.persistence.ComponentQueryManager.createComponent(ComponentQueryManager.java:320)
at org.dependencytrack.persistence.QueryManager.createComponent(QueryManager.java:379)
at org.dependencytrack.tasks.BomUploadProcessingTask.processComponent(BomUploadProcessingTask.java:170)
at org.dependencytrack.tasks.BomUploadProcessingTask.inform(BomUploadProcessingTask.java:124)
at alpine.event.framework.BaseEventService.lambda$publish$0(BaseEventService.java:99)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.datanucleus.exceptions.NucleusUserException: Attempt to store value "Frank Hommers and others (Burhan Irmikci (barhun), Zachary Sims(zsims), kgamecarter, Stafford Williams (staff0rd), briangweber, Viktor Svyatokha (ahydrax), Christopher Dresel (Dresel), Vytautas Kasparavičius (vytautask), Vincent Vrijburg, David Roth (davidroth)." in column "PUBLISHER" that has maximum length of 255. Please correct your data!
at org.datanucleus.store.rdbms.mapping.column.CharColumnMapping.setString(CharColumnMapping.java:253)
at org.datanucleus.store.rdbms.mapping.java.SingleFieldMapping.setString(SingleFieldMapping.java:183)
at org.datanucleus.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:158)
at org.datanucleus.state.StateManagerImpl.providedStringField(StateManagerImpl.java:1853)
at org.dependencytrack.model.Component.dnProvideField(Component.java)
at org.dependencytrack.model.Component.dnProvideFields(Component.java)
at org.datanucleus.state.StateManagerImpl.provideFields(StateManagerImpl.java:2528)
at org.datanucleus.store.rdbms.request.InsertRequest.execute(InsertRequest.java:352)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.insertObjectInTable(RDBMSPersistenceHandler.java:162)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.insertObject(RDBMSPersistenceHandler.java:138)
at org.datanucleus.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:4569)
at org.datanucleus.state.StateManagerImpl.makePersistent(StateManagerImpl.java:4546)
at org.datanucleus.ExecutionContextImpl.persistObjectInternal(ExecutionContextImpl.java:2026)
at org.datanucleus.ExecutionContextImpl.persistObjectWork(ExecutionContextImpl.java:1869)
at org.datanucleus.ExecutionContextImpl.persistObject(ExecutionContextImpl.java:1724)
at org.datanucleus.ExecutionContextThreadedImpl.persistObject(ExecutionContextThreadedImpl.java:219)
at org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:715)
... 10 common frames omitted
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.