Question: Any plans for "request" migration?

[sseide]

Description/Steps to reproduce

I just want to ask if there are any plans already to move from the abandoned "request" library to another maintained library.
(https://github.com/request/request). As this is deprecated since Februar last year is is just a question of time until higher priority problems arise with this lib.

By now there is only one low prio thing with old sha1 hashes in oauth (request/request#3385) but it will probably not be the last one...

Is there a decision which new library shall be used? A possible comparison of different libraries use compile here:
https://github.com/sindresorhus/got#comparison

Link to reproduction sandbox

Expected result

Additional information

[dhmlau]

@sseide, thanks for the reference. We've used axios for some (maybe one) of the loopback-next packages but I think @marioestradarosa was having some issues with that.

@marioestradarosa, any insights?

[sseide]

@marioestradarosa any information or thoughts about this?

And as expected - some more things coming up in "request" dependencies that will not be fixed as they need updates to "request" itself to allow newer versions of the libraries. Therefor it is safe to assume CVE-2021-3918 within "json-schema" (with score high) as an indirect dependency will not be fixed in "request" because request needs an updated "http-signature" library...

And these things start to be reported in automated security scanners, will probably generate a lot of requests about request in the forseeable future.

[s100]

request now has a significant CVE in it which will not be fixed.

Please note that strong-soap also makes use of request indirectly, via httpntlm-maa. I have raised an issue against httpntlm-maa, but the package has not been maintained for over three years, and I do not expect it to be fixed. So, please could you also consider stopping using httpntlm-maa or migrating away from it to something else.

[sseide]

@s100 httpntlm-maa has no direct dependency to request - its only declared as a peer-dependency of either request or node-fetch. IT does not install these by itself.

Therefor it is up to the user which one he uses... But as strong-soap requires request too, this one is used.
As soon as strong-soap might switch to node-fetch dropping request everything is fine - even for httpntlm-maa

[s100]

@s100 httpntlm-maa has no direct dependency to request - its only declared as a peer-dependency of either request or node-fetch. IT does not install these by itself.

This was true at one point but this is no longer the case. Starting from npm 7 (which is part of Node.js 15+, October 2020), peer dependencies such as request are installed by default.

[sseide]

Oh - thanks for the reply. Did not realize this as these packages where direct dependencies here too on our side...

To bad, nothing to show what might be ok without installing it right away, and "optionalDependencies" are installed to per default, not installing them must be requested explicit too (same as with peer now) ... :-/
Do you now another solution except not mentioning these dependencies at all?

[s100]

There are plenty of alternative HTTP packages to request which you could use to get equivalent functionality. I like node-fetch, personally. Or, as this is software intended to run in Node.js, you could use the built-in http package directly.

I don't know what alternatives there are for httpntlm-maa - I don't know what this package is or does.

[s100]

• Following fix: resolve CVE-2023-26136 #701, as of [email protected], there is no longer a direct dependency on request.
• Following chore: switch to httpntlm and fix flaky test #717, as of [email protected], there is no longer a direct dependency on httpntlm-maa either - this means there is no longer an indirect on request either.

This issue is fixed and can now be closed.