snyk security vuln. - update sshpk version #68
Conversation
✗ High severity vulnerability found on sshpk@1.13.1 - desc: Regular Expression Denial of Service (ReDoS) - info: https://snyk.io/vuln/npm:sshpk:20180409 - from: node_services@1.0.0 > node-gyp@3.6.2 > request@2.83.0 > http-signature@1.2.0 > sshpk@1.13.1 Your dependencies are out of date, otherwise you would be using a newer sshpk than sshpk@1.13.1.
|
+1 |
|
Can we please get this merged @arekinath @davidlehn? Thanks in advance. |
|
@austinkelleher I'm not a maintainer here, just a former contributor and user. Note that in this case it's likely a semver based install will use the newer sshpk version anyway. |
|
FWIW, even if I remove |
|
@wyardley security problem was fixed with |
|
GitHub needs a community pull voting system that does not require permission of a maintainer. This project has 24 contributors, but appears to only have one maintainer @arekinath? Not good. Democracy should rule all, looks like I need to submit a pull request under GitHub to enable? :-) |
|
Or you could simply not create unnecessary pull requests. You're pulling in an old, out of date dependency, most likely caused by your own package lock file. There is a hint right there in your snyk output. When you see something like
Snyk is telling you that you are pinning sshpk at @1.13.1, and it's not node-http-signature. |
|
@benwiggins - haha, I was unaware of this, thanks for educating me about this. Right on. |
|
On that note, closing pull request and exiting building... |
|
Lock file nonsense aside, this PR is still a good idea to ensure a proper sshpk version is used. |
|
What I am gathering so far is that you can solve this issue now by utilizing the snyk package. Personally, I run snyk wizard twice per day to ensure my system is up to par. or then Follow the prompts accordingly to patch your system, updating local dependencies and applying available patches wherever possible. If my general assessment stated here is incorrect or you have any additional helpful recommendations, please share... |
|
Don’t get me wrong, I 100% agree that bumping the minimum version to a known “good” version is good practice / courtesy. But it does nothing to educate those tearing their hair out creating pull requests and issues because they don’t understand how dependency resolution/semvers/package locks actually work. Nor does it necessarily solve someone’s nsp or snyk “security issue” if your package is a nested(-nested-nested) dependency, which in this case being a request dependency, is pretty likely. It just moves the pull request/issue noise somewhere else :) |
package.json
Outdated
| @@ -30,7 +30,7 @@ | |||
| "dependencies": { | |||
| "assert-plus": "^1.0.0", | |||
| "jsprim": "^1.2.2", | |||
| "sshpk": "^1.7.0" | |||
| "sshpk": "^1.14.1" | |||
There was a problem hiding this comment.
This should now be ^1.14.2 to account for the new Buffer usage fix. See TritonDataCenter/node-sshpk#46
There was a problem hiding this comment.
Done, resubmitted pull request with 1.14.2
There was a problem hiding this comment.
@BYK Is this going to be merged? Thanks in advance.
There was a problem hiding this comment.
You're pinging the wrong person, I am neither a contributor nor a maintainer here 😊
|
Done as of PR #86 |
✗ High severity vulnerability found on sshpk@1.13.1
Your dependencies are out of date, otherwise you would be using a newer sshpk than sshpk@1.13.1.