-
Notifications
You must be signed in to change notification settings - Fork 53
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
Better process for reducing, reviewing, and locking down dependencies #22
Comments
Thanks for opening this issue @madeken! I'm closing #19 in favor of this issue, since you've described some of the concerns really well here. I'm hoping to work out a process for really locking down dependencies for this project and make it easier to review dependency updates. I also really like the idea of isolating the "build" dependencies from other development related ones (e.g. testing infrastructure). Have you seen this in any other projects? Any recommendations for how we should go about implementing that here? |
I really like what you've done with this library, and would really like to use it to replace some hand-rolled crypto I wrote. My biggest concern however is how to verify the build.
If I am not mistaken, the current build process involves at least 1251 unique packages, any of which could potentially subvert the build.
However, fortunately the vast majority of those libraries have no purpose outside of development. I propose that the dependencies are split between those that are essential for reproducing a build, and those for developer convenience.
The text was updated successfully, but these errors were encountered: