You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The generated glue code should be able to be ran without requiring the internet the first time and there are also security vulnerabilities that can spawn from relying on third-party code. The external import for deno.land/x/plug makes the calling of the FFI stuff does make it easier to cache in our code. However, I don't really think we should depend on external code sources, especially deno.land/x. If this project is under the same guise as the standard library's code manual (which I think it should), then it would violate the first STD-specific rule:
Do not depend on external code.
https://deno.land/std/ is intended to be baseline functionality that all Deno programs can rely on. We want to guarantee to users that this code does not include potentially unreviewed third party code.
The fact of the matter is that it would need to be ensured with every version bump that all of the dependencies in the tree from /x/plug would need to be reviewed after every version for the dependency to remain safe. Every single person that uses this bindgen helper would be vulnerable if someone accidentally bumped the plug version without realizing there was a bad egg three levels down in the dependency tree that did some malicious stuff. Or, if x/plug or a sub dependency was using an untagged dependency in which case code that had been previously reviewed could have changed so no one would have ever known there was even a vulnerability.
Now, I don't really have a good solution to this, though, as the caching implemented by /x/cache and /x/plug is really good. The only problem is that it's external code. Therefore, I'd just like to open this issue to open it for discussion and put out the idea of this being a possible issue along the line that we might need to fix.
The text was updated successfully, but these errors were encountered:
#48 might make this easier to deal with as we could just remove the caching capabilities from the base behavior and people could choose to use plug to load the binary then call the new attach function on lib.
The generated glue code should be able to be ran without requiring the internet the first time and there are also security vulnerabilities that can spawn from relying on third-party code. The external import for
deno.land/x/plug
makes the calling of the FFI stuff does make it easier to cache in our code. However, I don't really think we should depend on external code sources, especially deno.land/x. If this project is under the same guise as the standard library's code manual (which I think it should), then it would violate the first STD-specific rule:The fact of the matter is that it would need to be ensured with every version bump that all of the dependencies in the tree from /x/plug would need to be reviewed after every version for the dependency to remain safe. Every single person that uses this bindgen helper would be vulnerable if someone accidentally bumped the plug version without realizing there was a bad egg three levels down in the dependency tree that did some malicious stuff. Or, if x/plug or a sub dependency was using an untagged dependency in which case code that had been previously reviewed could have changed so no one would have ever known there was even a vulnerability.
Now, I don't really have a good solution to this, though, as the caching implemented by
/x/cache
and/x/plug
is really good. The only problem is that it's external code. Therefore, I'd just like to open this issue to open it for discussion and put out the idea of this being a possible issue along the line that we might need to fix.The text was updated successfully, but these errors were encountered: