Repository navigation
Troubling notices on socket.dev #670
Description
Activity
This looks like a really important challenge for danfojs-node's security and adoption
i am a student who want to contribute to open source, and I'd love to take a shot at investigating and fixing these Socket.dev notices. Is it okay if I start looking into this?Reacted by Rising Odegua@jasonsantoleo sure, go for it.
Reacted by Jason santoHi RisenW,
Subject: My understanding of socket.io dependency health for Danfo.js
Following up on our chat, I did some research on the socket.dev notices for Danfo.js—it’s really interesting
Here are my thoughts:-
General Dependency Clean-Up
What I saw: A bunch of small, older packages (like es-define-property, function-bind, etc.). The scanner suggests these could be updated for better code health and compatibility.
My thoughts: This seems like a good, feasible fix. We can use npm override to point to the recommended versions with low risk. -
Deprecated Packages
What I saw: Some packages are marked as officially deprecated (e.g., glob, npmlog, rimraf, uuid). This is a bit more serious, especially since deprecated packages won’t receive future updates—particularly security patches.
My thoughts: Updating to a newer, actively maintained version is a better long-term solution. For most of them, it should work fine.
One problem: The request package is not only deprecated but also has known security vulnerabilities like SSRF. Since it's completely unmaintained, the best fix would be to swap it out for a modern library like axios. But this might require a bigger change. -
Deep Dependencies (like TensorFlow)
What I saw: tfjs-node (and a few others like core-js, ajv, detect-libc) got flagged for things like using eval, network access, native code, install scripts, and shell access.
My thoughts: After looking into it, this is just how tfjs-node is designed to work—to support native TensorFlow code, download models, and offer performance benefits. Trying to “fix” these would likely break the library. So, I think the best approach is to understand why these flags are there and document that this is expected behavior.
One exception: The ajv package was flagged for using eval. It might be possible to fix this by updating ajv to a newer version. -
Trivial Package
What I saw: A tiny package called set-blocking (just 7 lines of code).
My thoughts: If Danfo.js directly uses this code, we could just copy those 7 lines directly into the danfojs-node code and remove the dependency entirely.
These are my thoughts so far. Before making any changes, I’d really appreciate your input on how to work through these issues.
- Which of these issues would you consider the highest priority for me to tackle first?
- Specifically for the deprecated packages, would you like me to try updating them and see if any breaking changes occur, or should I hold off for now?
- And for request, does the idea of migrating to node-fetch or axios sound like the right path—even if it’s a bigger task?
This is a heavy task for a newbie like me 😅, so your guidance would really mean a lot
Thanks again
-
Some troubling notices for this package on socket.dev. Worth investigating because high scores and no (or lightly severe) notices make it easier to push for adoption of this package.