Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audit failed, problems with node-static #431

Closed
Jean-Luc-Picard-2021 opened this issue Nov 25, 2023 · 12 comments
Closed

Audit failed, problems with node-static #431

Jean-Luc-Picard-2021 opened this issue Nov 25, 2023 · 12 comments

Comments

@Jean-Luc-Picard-2021
Copy link

He was using:

$ node -v
v20.10.0

Now it shows me after npm ci:

npm ci
npm WARN deprecated [email protected]: Renamed to read-package-up

added 798 packages, and audited 1062 packages in 22s

194 packages are looking for funding
  run `npm fund` for details

5 vulnerabilities (1 low, 1 moderate, 1 high, 2 critical)

To address issues that do not require attention, run:
  npm audit fix

Some issues need review, and may require choosing
a different dependency.

Run `npm audit` for details.

Can I ignore?

@Jean-Luc-Picard-2021 Jean-Luc-Picard-2021 changed the title Audit failed, problems with Audit failed, problems with node-static Nov 25, 2023
@Jean-Luc-Picard-2021
Copy link
Author

# npm audit report

Gives me this result:

# npm audit report

minimist  <=0.2.3
Severity: critical
Prototype Pollution in minimist - https://github.com/advisories/GHSA-vh95-rmgr-6w4m
Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h
fix available via `npm audit fix`
node_modules/optimist/node_modules/minimist
  optimist  >=0.6.0
  Depends on vulnerable versions of minimist
  node_modules/optimist

node-static  *
Severity: high
Denial of Service in node-static - https://github.com/advisories/GHSA-8r4g-cg4m-x23c
node-static and @nubosoftware/node-static vulnerable to Directory Traversal - https://github.com/advisories/GHSA-5g97-whc9-8g7j
No fix available
node_modules/node-static

3 vulnerabilities (1 high, 2 critical)

@jeswr
Copy link
Collaborator

jeswr commented Nov 25, 2023

These only affect dev dependencies; not dependencies that we use in the packaged version of this tool, see:

$ npm audit --omit=dev
found 0 vulnerabilities

Neither of the vulnerabilities listed pose threats to building this tool as far as I can tell.

@jeswr jeswr closed this as not planned Won't fix, can't repro, duplicate, stale Nov 25, 2023
@Jean-Luc-Picard-2021
Copy link
Author

Jean-Luc-Picard-2021 commented Nov 25, 2023

But your npm-swipl-wasm does not provide swipl.js, so that one can do:

node swipl.js <Prolog Text> <Argument1> .. <Argumentn>

This is not contained here:

https://www.npmjs.com/package/swipl-wasm

It was described here:

https://swi-prolog.discourse.group/t/whoa-what-is-swipl-js-is-it-what-it-appears-to-be/5051/4

I am looking for an easy way to obtain it, but you didn't bundle it, right?

@jeswr
Copy link
Collaborator

jeswr commented Nov 25, 2023

The swipl.js referenced in that thread is included in the swipl-wasm package; it can be found in /dist/swipl/swipl.js.

@jeswr
Copy link
Collaborator

jeswr commented Nov 25, 2023

Note that if your goal is to use swipl in javascript then I would just refer to https://github.com/SWI-Prolog/npm-swipl-wasm?tab=readme-ov-file#swipl-wasm for the best ways to use this package.

@Jean-Luc-Picard-2021
Copy link
Author

Jean-Luc-Picard-2021 commented Nov 28, 2023

Concerning batch testing, without building wasm, but with downloading
an NPM package, you told me I should look here:

https://www.npmjs.com/package/swipl-wasm

But there is no swipl.js use case listed, which is what I am looking for. So
I have absolutely no clue what I need to do for batch testing.

Also the documentation doesn't reflect newest node, so its
vary hard to follow, because most of the examples don't work as is.

See also this other defect:

#432

It was closed in favor of an identical other defect #433 . Which
doesn't make sense, because in # 433 there is no info given what is

broken with readme.MD.

@jeswr
Copy link
Collaborator

jeswr commented Nov 29, 2023

But there is no swipl.js use case listed, which is what I am looking for. So
I have absolutely no clue what I need to do for batch testing.

There is no swipl.js use case listed because you shouldn't be needing to use that file directly. https://www.npmjs.com/package/swipl-wasm provides an abstraction on top of that file which bundles everything you need together and exports the SWIPL function which should be able to do everything you need and is described in the getting started section of the readme.

If you need to be loading a full prolog file rather than using basic functions described in that section of the readme, then your input to that SWIPL function probably needs to look something like https://github.com/eyereasoner/eye-js/blob/1ebd963d3c72d672ebefc2cca4c1ef784b659b80/lib/transformers.ts#L23-L25 or https://github.com/eyereasoner/eye-js/blame/54138910829146f97fd5407609430e2af64a13ad/lib/transformers.ts#L16-L39. Indeed it would be great to have documentation for this in the README, and PRs are happily accepted :)

#433 is a PR to update the readme, not an issue. You can see the readme updates in https://github.com/SWI-Prolog/npm-swipl-wasm/pull/433/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5.

@jeswr
Copy link
Collaborator

jeswr commented Nov 29, 2023

As this is a community run project there is no resourcing for the readme to be completely comprehensive and fully up to date.

If anything else is unclear, you're welcome to open up an issue specifying how you want to use the library and we can try and find solutions.

@Jean-Luc-Picard-2021
Copy link
Author

Jean-Luc-Picard-2021 commented Nov 30, 2023

There is no swipl.js use case listed because
you shouldn't be needing to use that file directly.

Well you then don't understand my question and/or swipl.js in your npm package
is another swipl.js than I am refering to. I am refering to this swipl.js here in
Jan Wielemakers recent GIT update, where he included WASM testing:

system('swipl-wasm',
       'SWI-Prolog (WASM,-O)',
       path(node),
       Speedup,
       ['../build.wasm/src/swipl.js',
        '-O', 'run.pl', '--csv', '--speedup', Speedup],
       [],
       "").

https://github.com/SWI-Prolog/bench/blob/master/compare.pl

What do you think I was refering to when I asked for swipl.js ?
I described what swipl.js does when I wrote:

But your npm-swipl-wasm does not provide swipl.js, so that one can do:

node swipl.js <Prolog Text> <Argument1> .. <Argumentn>

Can you confirm that you have nowhere a swipl.js of this kind in any of
your distributions, right? And stop pretending your answers would help me?

@jeswr
Copy link
Collaborator

jeswr commented Dec 5, 2023

I'm not sure if the swipl.js generated there for testing is particularly different from the one used in this package. I would imagine not, but I'll let @JanWielemaker confirm.

In this package we create ../build.wasm/src/swipl.js in this dockerfile and then copy the swipl.js into dist/swipl/swipl.js using this command. You will not see this file in the GitHub repo as it is an artefact of the build process and so .gitignored. It is available in the dist/swipl/swipl.js directory of the swipl-wasm package (you can visually navigate the folders in that package here).

I described what swipl.js does when I wrote:

The reason I pointed to this link was to demonstrate how you could write a JS script to achieve what you're after using the abstractions exported by the swipl-wasm package. In particular you should be able to achieve what you've written by doing the following (there could be bugs, I don't have time to test the code right now)

import SWIPL from "swipl-wasm"

/**
 * Executes a query
 * @param Module The module to execute the query on
 * @param name The name of the query function
 * @param args The arguments of the query function
 * @returns The result of the query
 */
export function query(Module: SWIPLModule, name: string, args: string[] | string) {
  const queryString = `${name}(${
    /* istanbul ignore next */
    typeof args === 'string'
      ? `"${args}"`
      : `[${args.map((arg) => `'${arg}'`).join(', ')}]`
  }).`;
  return Module.prolog.query(queryString);
}

export function queryOnce(Module: SWIPLModule, name: string, args: string[] | string) {
  return query(Module, name, args).once();
}

async function main() {
   const Module = await SWIPL();
   Module.FS.writeFile('example.pl', strToBuffer(/* prolog string */ ));
   queryOnce(Module, 'consult', 'example.pl');
   queryOnce(Module, 'main', ['<Argument1>', ..., '<ArgumentN>']);
}

I hope that clarifies any confusion in my above responses.

@Jean-Luc-Picard-2021
Copy link
Author

Jean-Luc-Picard-2021 commented Dec 6, 2023

I wonder what you mean by "archive". It surely doesn't "archive" a CLI. To use
inside scripting we need something that works with CLI as follows. I am willingly
to repeat this requirement over and over and answer specific questions:

But your npm-swipl-wasm does not provide swipl.js, so that one can do:

node swipl.js <Prolog Text> <Argument1> .. <Argumentn>

CLI = command line interface. Mostlikely it will use process.argv somewhere.
To grab the command line arguments. Or some library that does that for you.
So hardcoding main() isn't a solution, because it lacks the parameter passing.

Also traditionally the argv should land in the Prolog flag argv, which exists
in SWI-Prolog. I have opened a new ticket especially for this feature request
and/or clarification. Reason: A CLI has much more going on beneath

than what might meet the eye in the first place.

@JanWielemaker
Copy link
Member

The src/swipl.js should probably be considered a build artifact. It can only function inside the build tree as it relies on the home directory that is created by the build process and contains the Prolog boot file and the Prolog libraries. I think @jeswr is right that the proper route is to add a JavaScript file that creates the commandline version based on the NPM distribution. On the other hand, can this both use the Prolog resources from e.g., the bundle and access the file system?

Note that, at least in theory, we also can embed the Prolog resources into the C (and thus WASM) code rather than using the virtual filesystem. I don't know whether that changes the equation.

I guess it all depends on the use cases. Running in the browser is obviously something we want. Running under Node is less clear. On Discourse it was mentioned for including in some cloud infrastructure. WASM produces a nicely portable version of course. For Node, one can also consider embedding the native version, providing much better scaling (at the cost of more complicated installation and loosing portability).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants