Skip to content
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

feat: remove generated code dependencies #49

Open
sno2 opened this issue Jan 27, 2022 · 2 comments
Open

feat: remove generated code dependencies #49

sno2 opened this issue Jan 27, 2022 · 2 comments

Comments

@sno2
Copy link
Contributor

sno2 commented Jan 27, 2022

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.

@sno2
Copy link
Contributor Author

sno2 commented Jan 27, 2022

#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.

@eliassjogreen
Copy link

My pr makes the dependency optional, allowing for using the Deno.dlopen method instead in case that is preferred.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants