Closed pravi closed 6 months ago
I don't think we can upgrade a dependency as critical as the network stack without a major bump, which we can't do here.
Additionally, the vulnerability seems to be only a bypass of a protection that we didn't enable anyway (ssrf-req-filter
), so that doesn't seem relevant in our case 🤔
Debian release team agreed to give an exception and we will ship yarn 1.x in bookworm with request module. Thanks for the reply. Since our goal is to remove request module, even if the security issue don't affect yarn, we won't be able to keep request module in debian. But now we have ~2 years to move to yarn berry for debian trixie.
Related https://github.com/yarnpkg/yarn/issues/8081 (adding for completeness)
yarnpkg in debian is updated to 4.0.2 -> https://tracker.debian.org/news/1488930/accepted-node-yarnpkg-402dfsg-2-source-into-unstable/
So closing this issue.
Just a note, we also have node-corepack package which can be used as yarn classic with (corepack yarn command).
request module is unmaintained for sometime and it now has a security issue https://github.com/request/request/issues/3442
In debian, we are still shipping yarn 1.x, as building newer yarn versions from corepack sources is still not completed. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980316#43 Eventually we'd like to move to yarn berry, but we can't do that in time for our next release bookworm which can happen in next few months (we are in hard freeze).
So if possible, having just one more yarn 1.x releases without request dependency will help us to keep providing yarn 1.x for our bookworm release and for next release we hope to move to yarn berry.
If we are removing request, we should probably remove request-capture-har as well (which is a wrapper for request).
Note: I understand yarn 1.x is unmaintained, but adding it here for documenting