all questions regarding PR#13

[jkowalleck]

all questions from #13 could go below

[jkowalleck]

Q: What are sensible defaults for the parameters?

[jkowalleck]

• --spec-version should default to 1.5
• --output-format should default to JSON -- its just native to the JavaScript world,
• --output-file should default to printing to STDOUT
• --component-type should default to application
• --production should default to false

[jkowalleck]

Q: Decision on license. Am I correct to assume the contained components can be used as part of a Apache-2.0 licensed project? Are you aware of any tool that takes a list of SPDX identifiers for dependencies (or SBOM) and answers which licenses could be chosen?

[jkowalleck]

well, i think we need to considder two things here:

1. what is the license of the code that is hosted in this repository?
2. what is the license of the build result?

Answer to 1: Apache-2.0

Answer to 2: nothing to bother now. as long as all components' licenses are properly listed with the aggregated build result, we are good for now.

[AugustusKling]

I was thinking about license for this repository which is a non-issue as Apache-2.0 is fine.

The more difficult part is the packaging and license for the compiled bundled. Since they contain at least parts of the dependencies one needs to provide a component listing and license texts to confirm with the licenses of the dependencies. Also the license for the bundle must safisfy all dependency licenses. My current understanding is that including ./bundles/components-licenses.md in the bundle is okay given the current dependencies but maybe linking to the file is good enough.

However if direct or transitive dependencies are change, this may no longer hold true. Manual verification is tedious and error-prone. I'd hope some tool exists that can be fed SPDX identifiers of the desired license and the licenses of all dependencies. It should then break the build in case anything is incompatible. Perhaps a build step calling https://github.com/jslicense/spdx-satisfies.js would work?

[jkowalleck]

I do understand the situation.
Since this is legal territory, I'd stop thinking about this. Should lawyers guide us.

I will seek the legal support from OWASP for guidance.

[AugustusKling]

Thanks. I'm curious to learn what OSWAP is going to suggest regarding component listings + licenses of dependencies for bundles.

[jkowalleck]

After some modifications to the CycloneDX library, it was possible to help esbuild with the tree shaking, so no unintended components were bundled.
Then, it required some tweaks to the yarn plugin builder, so that it was possible to gather the actual bundled components and their respective licenses.

Then i worked to a state where only apache2 compatible licenses were bundled. Then I talked with my OWASP colleagues and we assessed the licenses and compliance.

final result: we are ready to publish a bundle/assembly.
And this is where we are now 🎉 finally.

see also:

• [LEGAL] sort out license situation #104
• ci: assert license compatibility #117
• https://github.com/CycloneDX/cyclonedx-node-yarn/blob/1.0-dev/tools/write-3rd-party-licenses.cjs
• [Feature] add builder option to produces esbuild's metafile yarnpkg/berry#6211

[jkowalleck]

Q: Treatment of the root component in the SBOM. Should it be put in the metadata only or also within the components property?

[jkowalleck]

especially in $.metadata.tools[]

[jkowalleck]

Q: Many files in the root folder are basically empty templates.

[jkowalleck]

which in particular? what about those files?

[AugustusKling]

• .gitignore
• CODEOWNERS, linked https://github.com/orgs/CycloneDX/teams/javascript-maintainers does not exist.
• CONTRIBUTING.md
• HISTORY.md

Maybe the files should only be created from the templates when putting content in that is specific to this repository.

[jkowalleck]

.gitignore

was boilerplate with a basic setup for this project.
feel free to modify to your needs.

CODEOWNERS, linked https://github.com/orgs/CycloneDX/teams/javascript-maintainers does not exist.

it does exist, it is just no group you might have access to.

CONTRIBUTING.md

it was prepared to be used, not a template. is just had some gaps, since there was no processes for some cases, since the was no code yet.

feel free to fill those gaps

HISTORY.md

it was prepared to be used, not a template. since there was no history, there was just no details. ;-)

[jkowalleck]

Q: Do you have sample projects with known expected output regarding listed components and licenses?

[jkowalleck]

nope, not for yarn. feel free to establish all the examples and test beds you need - for (unit/functional/integration) test or showcasing purposes

[jkowalleck]

Q: Fallback for component licenses.

[jkowalleck]

in the SBOM? none in particular, component.licenses is an optional list.

[AugustusKling]

Do you intent to have a dependency on something like https://github.com/CycloneDX/license-scanner in some distant future as part of this project?

[jkowalleck]

never say no. if there was a reason for it, a feasible way and a reasonable effort, why not.
but this would require them having a stable programmable interface, see CycloneDX/license-scanner#9

[jkowalleck]

Q: How would one calculate the hash for https://cyclonedx.org/docs/1.5/json/#components_items_hashes for a folder representing a component?

[jkowalleck]

just don't for now. this would not be part of an minimal viable product. leave this feature for future development.

the hash or the external reference to the distributional instead, this one should be feasible, as it is in most yarn locks already.

[AugustusKling]

I don't know how the checksum from the yarn.lock is calculated nor how stable it is across lockfile versions. Reading bug reports like yarnpkg/berry#6068 and yarnpkg/berry#6105 suggests that the algorithm of the checksum is not defined.

[jkowalleck]

well, then leave it for now. can be added in the future, after the details are clear.

[jkowalleck]

Q: Which are the important/desired properties in the generated SBOM files besides those marked as required in the JSON schema?

[jkowalleck]

Whatever you feel relevant for a minimal viable product. :-)
Future development may add additional features/information, so there is no need for a complete solution right away.

[jkowalleck]

Q: Is the reproducible results flag mentioned in #8 important? Shouldn't this be a task for a SBOM consumer by masking out properties?

[AugustusKling]

To quote your quote 😉

... SHOULD be used in $.metadata.properties.

Since I cannot find generic properties in CDX.Models.Metadata, I wonder how this cdx:reproducible could be put there. Say we have const bom = new CDX.Models.Bom(); how would one set the flag to express that the SBOM was created with --reproducible. Can you give a code example?

[jkowalleck]

something like (untested pseudocode)

bom.metadata.properties.push(new CDX.Models.Property('cdx:reproducible', 'true'))

PS: atleast if the properties would be implemented.
seams like nobodu had a use case for them before, so there is no implementation for it, yet -- https://github.com/CycloneDX/cyclonedx-javascript-library/blob/main/src/models/metadata.ts

[jkowalleck]

if you find a feature being missing from the library, feel free to create a ticket for it. :-)

the library is a living implementation. each feature is added when needed. This enables the library to be published/available as soon as possible. New features are added on demand. ;-)

[AugustusKling]

You code example is what I had attempted but it didn't work as the model was incomplete. See CycloneDX/cyclonedx-javascript-library#1019 for a potential fix.

[AugustusKling]

@jkowalleck, Property was added with b8ff4f7

[jkowalleck]

Q: I've only used this plugin with Yarn 4.1.0. It may or may not work with other Yarn versions.

[jkowalleck]

One could add some automated tests to check. what i have un mind is a setup as follows:

use github workflows as a automation for:

1. build
   1. setup the project in this repo
   2. build the project
   3. artifact the build result
2. tests: have a test matrix with all relevant versions of yarn and all relevant versions of node
   1. setup node in the version desired by the matrix
   2. setup yarn in the version desired by the matrix
   3. fetch the artifact from the "build" step and use it for the following tests
   4. setup the project in this repo (skip build!)
   5. run all unit/functional/integration tests in an automated manner
3. dog-fooding: have a test matrix with all relevant versions of yarn and all relevant versions of node
   1. setup node in the version desired by the matrix
   2. setup yarn in the version desired by the matrix
   3. fetch the artifact from the "build" step and install it
   4. setup the project in this repo (skip build!)
   5. run the yarn plugin over this very setup, and print the result to screen

similar is done here: https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/.github/workflows/nodejs.yml