Some `ref` fields have no meaning

CycloneDX / cyclonedx-node-npm

Create CycloneDX Software Bill of Materials (SBOM) from Node.js NPM projects.

https://cyclonedx.org/

Apache License 2.0

73 stars 20 forks source link

Some `ref` fields have no meaning #1111

Closed eviler007 closed 1 year ago

eviler007 commented 1 year ago

Describe the bug

Some ref and bom-ref fields are incorrect

To Reproduce

create a empty folder and enter it.
install the test pacakge: npm i @angular/cli@17.0.0-next.4
run cyclone-npm: cyclonedx-npm --ignore-npm-errors --package-lock-only --omit dev --omit peer --flatten-components --short-PURLs --spec-version 1.3 --mc-type library --output-file ./bom.json

Expected behavior

The ref and bom-ref fields will be like name@version

Screenshots or output-paste

{
  "components": [
    {
      "name": "string-width",
      "version": "4.2.3",
      "bom-ref": "BomRef.xxxxxxxxxxx.xxxxxxxxxx",
    }
  ],
  "dependencies": [
    "ref":  "@isaacs/cliui@8.0.2",
    "dependsOn": [
       "BomRef.xxxxxxxxxxxx.xxxxxxxxxxx"
    ]
  ]
}

Environment

@cyclonedx/cyclonedx-npm version: v1.12.1
NPM version: 9.8.1
Node version: 16.15.0
OS: windows10

jkowalleck commented 1 year ago

I will look into this. but it is no bug and has no urgency - for the reasons described below.

@eviler007 according to CycloneDX document standard, ref and bom-ref do not necessarily have any meaning. they can be arbitrary strings with the sole purpose to match each other.

eviler007 commented 1 year ago

I will look into this. but it is no bug and has no urgency - for the reasons described below.

@eviler007 according to CycloneDX document standard, ref and bom-ref do not necessarily have any meaning. they can be arbitrary strings with the sole purpose to match each other.

ok, thank you

jkowalleck commented 1 year ago

ran a test:

$ npm init
$ npm i @angular/cli@17.0.0-next.4

added 256 packages, and audited 257 packages in 17s

$ npx @cyclonedx/cyclonedx-npm@1.12.1 --ignore-npm-errors --package-lock-only --omit dev --omit peer --flatten-components --short-PURLs --spec-version 1.3 --mc-type library --output-file ./bom.json
Need to install the following packages:
  @cyclonedx/cyclonedx-npm@1.12.1
Ok to proceed? (y) y
DEBUG | options: {"ignoreNpmErrors":true,"packageLockOnly":true,"omit":["dev","peer"],"flattenComponents":true,"shortPURLs":true,"specVersion":"1.3","outputFormat":"JSON","outputFile":"./bom.json","validate":true,"mcType":"library"}
DEBUG | packageFile: /tmp/fdsfdsfdsf/package.json
INFO  | projectDir: /tmp/fdsfdsfdsf
DEBUG | detected a package lock file
DEBUG | command: npx-cli.js usage detected, checking for npm-cli.js ...
DEBUG | makeNpmRunner caused execFileSync "/usr/bin/node" with  "-- /usr/local/lib/node_modules/npm/bin/npm-cli.js"
INFO  | detect NPM version ...
DEBUG | detected NPM version [9,4,2]
INFO  | gather dependency tree ...
DEBUG | npm-ls: run npm with ["ls","--json","--long","--all","--package-lock-only","--omit=dev","--omit=peer"] in "/tmp/fdsfdsfdsf"
INFO  | build BOM ...
LOG   | serialize BOM
LOG   | try validate BOM result ...
LOG   | writing BOM to ./bom.json

$ jq '.. | objects | select(has("bom-ref")) | select(.["bom-ref"] | startswith("BomRef.")) | .["bom-ref"]' bom.json
"BomRef.rbmmcj3eiv.c2c786g67s8"
"BomRef.t6f0h9umhug.n6f20o9g63"

bom.json as attached: bom.json.zip

jkowalleck commented 1 year ago

based on https://github.com/CycloneDX/cyclonedx-node-npm/issues/1111#issuecomment-1735244627 the details look like:

string-width@4.2.3 was installed multiple times, so one bom-ref was changed, to make them unique.
caused by package-aliasing of dependencies in @isaacs/cliui@8.0.2 install locations:
- node_modules/string-width
- node_modules/string-width-cjs
strip-ansi@6.0.1 was was installed multiple times, so one bom-ref was changed, to make them unique.
caused by package-aliasing of dependencies in @isaacs/cliui@8.0.2 install locations:
- node_modules/strip-ansi-cjs
- node_modules/strip-ansi

so there is no issue. all as usual. :heavy_check_mark: detection of packages worked as expected :heavy_check_mark: discriminator made bom-refs unique as expected -- as part of https://github.com/CycloneDX/cyclonedx-javascript-library

@eviler007 this was an interesting case. and i am happy to tell that all is working as expected, no evidence lost, SBOM is fully populated. :-D

eviler007 commented 1 year ago

基于#1111（评论），详细信息如下所示：

string-width@4.2.3安装了多次，因此bom-ref更改了一个，以使其独一无二。由安装位置中的依赖项的包别名引起@isaacs/cliui@8.0.2 ：

node_modules/string-width

node_modules/string-width-cjs

strip-ansi@6.0.1已安装多次，因此bom-ref更改了其中一个，以使它们独一无二。由安装位置中的依赖项的包别名引起@isaacs/cliui@8.0.2 ：

node_modules/strip-ansi-cjs

node_modules/strip-ansi

所以没有问题。一切如常。 ✔️ 包检测按预期工作 ✔️ 鉴别器使bom-refs 按预期唯一 - 作为https://github.com/CycloneDX/cyclonedx-javascript-library的一部分

@eviler007这是一个有趣的案例。我很高兴地告诉大家，一切都按预期进行，没有丢失任何证据，SBOM 已完全填充。:-D

Thank you very much for explaining, but I think the name@version is unique in itself，and in addition, the package "wrap-ansi" is also referenced many times, but the performance is as expected.

jkowalleck commented 1 year ago

Thank you very much for explaining, but I think the name@version is unique in itself，and in addition, the package "wrap-ansi" is also referenced many times, but the performance is as expected.

nope. see your own package.lock file.

see package-lock.json.zip

"node_modules/@isaacs/cliui": {
      "version": "8.0.2",
      "resolved": "https://registry.npmjs.org/@isaacs/cliui/-/cliui-8.0.2.tgz",
      "integrity": "sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA
==",
      "dependencies": {
        "string-width": "^5.1.2",
        "string-width-cjs": "npm:string-width@^4.2.0",
        "strip-ansi": "^7.0.1",
        "strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
        "wrap-ansi": "^8.1.0",
        "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"
      },
      "engines": {
        "node": ">=12"
      }
    },

see the output of npm ls -a --omit=dev --lockfile-only and you will find multiple occurrences of wrap-ansi@^7.0.0. So not only is this very tools sure about multiple un-deduped occurrences, but also NPM itself is sure about it.

eviler007 commented 1 year ago

Thank you very much for explaining, but I think the name@version is unique in itself，and in addition, the package "wrap-ansi" is also referenced many times, but the performance is as expected.

nope. see your own package.lock file.

see package-lock.json.zip
"node_modules/@isaacs/cliui": {
      "version": "8.0.2",
      "resolved": "https://registry.npmjs.org/@isaacs/cliui/-/cliui-8.0.2.tgz",
      "integrity": "sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA
==",
      "dependencies": {
        "string-width": "^5.1.2",
        "string-width-cjs": "npm:string-width@^4.2.0",
        "strip-ansi": "^7.0.1",
        "strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
        "wrap-ansi": "^8.1.0",
        "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"
      },
      "engines": {
        "node": ">=12"
      }
    },
see the output of npm ls -a --omit=dev --lockfile-only and you will find multiple occurrences of wrap-ansi@^7.0.0. So not only is this very tools sure about multiple un-deduped occurrences, but also NPM itself is sure about it.

It's true, I've done some processing on my side, and that's why it's happening. Thank you for your patience.