[BUG] Error was: Input length = 1 while publishing bom.json in Jenkins pipeline

[bubi1311]

Describe the bug

The upload of a bom.json of an angular project to the Dependency-Track server is not possible due to the error:
"[DependencyTrack] Es ist ein Fehler beim verarbeiten des Artefakts "path_to_file\angular_sbom.json" aufgetreten. Der Fehler war: Input length = 1"
In English:
"[DependencyTrack] An error occurred processing artifact "path_to_file\angular_sbom.json". Error was: Input length = 1"

Environment

• Plugin Version: 4.2.0
• Jenkins Version: 2.386
• Java Version for Jenkins: openjdk 11.0.17 2022-10-18 LTS (Red Hat)
• Type of Jenkins Job: declarative pipeline
• Dependency-Track Version: 4.6.2
• cyclonedx/cyclonedx-npm Version: 1.7.2

To Reproduce

Steps to reproduce the behavior (in a declarative pipeline):

1. Create the bom.json by using: cyclonedx-npm <path_to_angular-project>\package.json --output-reproducible --short-PURLs --output-file angular_sbom.json (using the jenkinsfile)
2. dependencyTrackPublisher artifact: "${angularOutputFile}", projectName: "${projectName}", projectVersion: "${projectVersion}", synchronous: "${dtSynchronous}", dependencyTrackApiKey: "<top-secret>"
   As you can imagine, the variables are filled correctly. The reason why I'm quite sure about it is that it's the same why I upload a bom.json for a nuget project and that works fine.

Expected behavior

The bom.json can be uploaded successfully to the Dependency-Track server.

Additional context

1. Manual upload of the same generated bom.json using the GUI of Dependency-Track or curl is working fine.
2. If a firewall blocks the communication between jenkins and Dependency-Track server the error occures, too. So it is not a problem of the Dependency-Track server itself.
3. Additional informations can be read at the issue 2202 in the dependency-track project.

[sephiroth-j]

Please check the encoding of the file and the encoding of the Jenkins machine where this actions runs on. The source of the MalformedInputException is likely to be located in Jenkins core functionality.

    /**
     * Reads this file into a string, by using the current system encoding on the remote machine.
     */
    public String readToString() throws IOException, InterruptedException {
        return act(new ReadToString());
    }


    private static class ReadToString extends MasterToSlaveFileCallable<String> {
        private static final long serialVersionUID = 1L;


        @Override
        public String invoke(File f, VirtualChannel channel) throws IOException, InterruptedException {
            return Files.readString(fileToPath(f), Charset.defaultCharset());
        }
    }

https://github.com/jenkinsci/jenkins/blob/5cecd13ec34c7a710b782db1a5d9f751d3e1c07c/core/src/main/java/hudson/FilePath.java#L2365-L2379

Versions of Jenkins prior to 2.346 did not used the default charset (1, 2), they used Files.readAllBytes(Path). Now, Files.readString(Path, Charset) is used and the only difference that matters is this call .

        return JLA.newStringNoRepl(ba, cs);

https://github.com/openjdk/jdk11u-dev/blob/edf4fb0a00b49141bd6c02d184901f93c2d09100/src/java.base/share/classes/java/nio/file/Files.java#L3287

[bubi1311]

Thank you @sephiroth-j !

The file encoding of the bom.json was UTF-8. But the jenkins was the problem.

In our environment we have a jenkins master running on Linux and a jenkins slave running on windows 2019.
I added two user environment variables:

• JAVA_TOOL_OPTIONS = -Dfile.encoding=UTF-8
• LANG = en_US.UTF-8

Source of this information was: https://www.linkedin.com/pulse/how-resolve-utf-8-encoding-issue-jenkins-ajuram-salim#:~:text=In%20normal%20cases%20Jenkins%20pass%20the%20characters%20in,4%20bytes%29%20which%20can%20encode%20all%20possible%20characters.

After that, the bom.json for angular is uploaded successfully. So the ticket can be closed / rejected.

I just wonder why I could upload a bom.json for nuget-packages in the same jenkinsfile and environment and with the bom.json for npm/angular it did not work.

Maybe that's a point for the documentation?

Thank you and sorry for opening the issue!

Stefan

[sephiroth-j]

The next major release will update the Jenkins baseline and incorporate the file reading changes introduced in Jenkins 2.346.