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
Https imports integrity checksums #41920
Comments
I also have some concerns/questions about HTTPS imports. I'm interested in security, but also in guarantees that my builds today will keep working tomorrow. My concern is that if this flag is eventually enabled by default:
Even if it's not enabled by default and you don't want to enable it - if any popular packages start using this, then you're going to have to enable it or give up on npm entirely, and it will be very difficult to manage these invisible remote dependencies. With node & npm today, I can be fairly confident that an I think there's one solution that would be interesting to provide security & reliability, going beyond checksums: node could vendor remote dependencies automatically. I.e. when you first import a remote dependency, store the content locally in
This only works if the cache is not node_modules, because that's generally git ignored. |
As I understand it, in the Rust world, you cannot I also completely agree such http imports should have the ability (or requirement) to specify an integrity checksum. Someone on HN proposed this syntax, which seems fine. Without an integrity checksum, Node would have to either download the dependency on startup every time, or it would have to have a confusing caching policy that would lead to unexpectedly failing to download a new version when the developer needed it to, and that's beyond the obvious security implications. |
cc @nodejs/modules @nodejs/security Many of these issues were discussed in #36328 and are either supported via policies (please read https://nodejs.org/dist/latest/docs/api/policy.html) or noted as follow-up efforts. Having a single catchall issue for all HTTPS imports security concerns isn’t very useful, so I’m going to focus this one on integrity checks (per the original post) and please open new issues for other concerns. |
At the moment I don’t think this is something we plan to address. If Deno provides support for such a feature I think we would consider it, probably copying however they implement it. |
I wonder if there could be some sort of http header, like The expensive version is some sort of key signed value in the headers. |
I don’t understand what problem you’re proposing a header would solve. What would the presence or absence of that header do? Non-standard headers rarely solve more problems than they create, IMO. |
The header would allow the server to filter who can import a |
If the server responds with the content of the script at all, the header is just a courtesy that can and would be ignored by someone who wants to import it anyways. The server really should require authentication if it wants to effectively limit who can retrieve some content, as with any other server. |
Ah, an |
Sending headers for a server is likely a different issue than integrity checks, please try to keep issues discrete. It seems fine to make a new issue on servers and access to them. |
Increasing the workload on the server |
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document. |
I really dislike the use of stale bots on any repo. |
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document. |
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment. For more information on how the project manages feature requests, please consult the feature request management document. |
It would be great if node could automatically handle generating integrity checksums for new https resources if they don't exist already. I'm going to assume that most js scripts in the wild don't have their own checksums.
Also, is there a good standard in place for servers that don't want someone just importing their scripts? I'm assuming CORS won't really cover that, considering know doesn't necessarily have to have a concept of it's own server.
Originally posted by @mrozbarry in #36328 (comment)
The text was updated successfully, but these errors were encountered: