search

eirslett / frontend-maven-plugin

"Maven-node-grunt-gulp-npm-node-plugin to end all maven-node-grunt-gulp-npm-plugins." A Maven plugin that downloads/installs Node and NPM locally, runs NPM install, Grunt, Gulp and/or Karma.
Apache License 2.0
4.2k stars 868 forks source link

Verify checksum for downloaded Node.js archive (fixes #645) #1119

Closed AndreasHae closed 8 months ago

AndreasHae commented 8 months ago

Summary

As explained in #645, we should verify downloaded archives to ensure its integrity to 1. mitigate issues when the file has been corrupted and 2. to prevent security issues when the file has been tampered with.

Tests and Documentation

I wrote two unit tests for verifying checksums. I ran the integration tests to make sure not to introduce a breaking change.

By the way, not related to this PR, but I noticed the file structure could use some cleanup as there are quite a lot of classes accumulating in one package. Is this something you would be open to @eirslett?

eirslett-visma commented 8 months ago

I considered this approach before (in my head) but never wrote the code for it.

I think nr. 1 (corrupted downloads) are finally solved with https://github.com/eirslett/frontend-maven-plugin/pull/1118 which is in the latest version of the plugin (1.4.2). I think the chance of the Node.js CDN serving a full binary response with 200 OK header - but with a corrupt file - is very low. The main issue before was that files were only half-downloaded, because of bottlenecks on the CDN and timeouts.

Regarding issue nr. 2, the main issue with this PR is that it downloads the shasums from the same CDN that it downloads Node from. So anybody who tampered with the Node binaries could easily tamper with the SHASUM file as well, to fool the verification check. The SHASUMS from nodejs.org are signed with GPG keys, but the GPG signature is not verified. For that, you would need an up-to-date way of verifying the "official" Node.js GPG key, which could be updated/replaced in case of security breaches, or just replaced regularly as part of a security regime. You see how this is becoming a real rabbit hole?

At that point, I think a better security measure would be to host your own private asset repository (Like a Nexus instance for example) and then fetch the binaries from there instead of from nodejs.org.

AndreasHae commented 8 months ago

I understand. Would you be open to me exploring the option to verify GPG signatures as well, or do you think the maintenance burden would be too high?

eirslett commented 8 months ago

I think it's out of scope for this plugin. Maybe a separate Maven plugin for verifying shasums? Once you dive into this - remember that your whole .m2 folder also consists of stuff that is downloaded from (probably) Maven Central. It would make sense to check shasums for those to as well, right? For example for spring-core: https://repo1.maven.org/maven2/org/springframework/spring-core/6.0.13/spring-core-6.0.13.jar.sha1 But to make sure that the shasum can be trusted, you also have to check the GPG key: https://repo1.maven.org/maven2/org/springframework/spring-core/6.0.13/spring-core-6.0.13.jar.asc

I'm sure 99 % of organizations don't actually verify trust in their dependencies. That's what makes the software world so vulnerable to supply chain attacks. Maven itself (as far as I know) doesn't come with any built-in signature checks at all. But there's a plugin for it: https://www.simplify4u.org/pgpverify-maven-plugin/ maybe you could fork it, and make it work with node/npm downloads as well.