strict pnpm version in engines in 11.8.0

[alebianco-doxee]

Hi,
we noticed a change in 11.8.0 of @cyclonedx/cdxgen that pins the pnpm version to a very specific/strict version (10.17.1).
This has caused some failing builds in a project of ours that used a slightly older version (10.16.1).

We use @cyclonedx/cdxgen directly through pnpx, like:

pnpx @cyclonedx/[email protected] \
	--required-only \
	--spec-version 1.4 \
	--server-url *** \
	--api-key *** \
	--project-name *** \
	--project-version *** .

which resulted in

 ERR_PNPM_UNSUPPORTED_ENGINE  Unsupported environment (bad pnpm and/or Node.js version)

Your pnpm version is incompatible with "***/Caches/pnpm/dlx/37547e4d50dde8c8f8ae3dae7858ea7a406f71674be087f71c08cf025b8e97f5/19975fb73eb-c730/node_modules/@cyclonedx/cdxgen".

Expected version: 10.17.0
Got: 10.16.1

two questions:

• are we using cdxgen in the right way?
• isn't this a bit too restrictive for the users?

for now, even if we upgraded pnpm, we choose to use v11.7.0 of cdxgen, to avoid recurring issues we upgrade or the tool is updated

[prabhu]

I will let @malice00 and @setchy share their views on this. My personal view is that this error is correct and using pnpx (pnpm dlx) must be limited to non-prod environments. This is because this particular command will resolve dependencies from scratch. If users use an older version of pnpm (even diverging versions), then the core maintainers may not know what dependencies you might get at a particular point in time, making the setup vulnerable to supply-chain attacks (like new versions of debug with bundled malware being released, etc).

My personal preference would be the container images or our single executable application binaries, followed by pnpm install with a lock file.

We will update the readme and docs to move the insecure install options such as npm install -g or pnpm dlx to the end.

[malice00]

This was recently introduced, when I was trying to force us and any contributors to use a specific version of pnpm. Node's documentation states that this option is advisory unless a specific config flag is set. Apparently pnpm does not see this configuration as advisory and doesn't acknowledge the flag when set to false -- but only when trying to run it directly. All seems to be fine when cdxgen is simply added as a dependency to a project and run using a script.

I'm not quite sure if I completely agree with you @prabhu, about not running pnpx in prod environments. Since the script mentioned is running cdxgen as a server, I feel these dependencies aren't influencing anything from any project, since there (hopefully) isn't one.
Continuing on this train of thought, I feel therefore it shouldn't be much of an issue for you to use a different version of pnpm. But I also feel we should not force you to, unless absolutely necessary -- and in that case it should be clearly documented on our side.

I feel we can reset this configuration to allow users to run cdxgen on older versions of pnpm. For us devs there is another configuration, which is also set, which keeps our workspaces using the correct version.

So, let's discuss the pros & cons some more and decide on a solution. For now: sorry we broke your script and I hope you can either update to pnpm 10.17.0, or use our previous release.

[alebianco-doxee]

thanks @malice00 and don't worry, nothing to be sorry about

I was waiting for another feedback, because I didn't fully understand the point of @prabhu about this change relating to dependency security

If I can add my 2 cents:

We use the engines setup on our project for the same reason but in our case it's internal and used only by the devs. If cdxgen uses some specific pnpm feature it's not unreasonable to set a minimun version for it ... just not a super specific single version in my opinion

Also, I explored the other options mentioned (cli binaries and docker) but on our CI environment (bitbucket pipelines) are both more inconvenient:

• the docker image has to run on a docker-in-docker setup with limited resources and the officiale image itself is 15GB and it that would be downloaded multiple times a day (it might be because of our specific setup, but still ... yikes)
• the binary (I tested with the one installed through brew) works but requires ruby I think, and that would mean more setup scripts to run on CI runners - also i'm sure there's a binary hat i can easily and cleanly install on a unix machine ...

[prabhu]

curl -L https://github.com/CycloneDX/cdxgen/releases/download/v11.8.0/cdxgen-linux-amd64 -o cdxgen
chmod +x cdxgen
./cdxgen

To always get the latest (Not recommended)

curl -L https://github.com/CycloneDX/cdxgen/releases/latest/download/cdxgen-linux-amd64 -o cdxgen

We also have slim, arm64, and musl versions.

[alebianco-doxee]

nice, i totally missed it. to be honest i might end up using this instead of pnpx :D

[prabhu]

You still raised a key question which is worth discussing and agreeing on a threat model and shared responsibilities collectively. Thank you!

[malice00]

@alebianco-doxee In case you still (want to) use pnpx, 11.9.0 is here!

[malice00]

I set the engine to >=10, as it had been before.

[nil4]

Would it be possible to make a new release, including the fix in 987ec73, to unblock using cdxgen with later pnpm versions?

[malice00]

@nil4 I will try to get a release out within the next 2 days.

[nil4]

Much appreciated, thank you @malice00!

[malice00]

@nil4 11.9.0 is here!