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
I'm quite confident everyone would agree that dealing with C deps is a huge pain compared to go packages. I'm even developing a build command for my package to pull and build C deps before building the package.
When I saw vgo I thought, it would be nice if this did the work instead of having to write a build command. I know that would mean allowing arbitrary code execution unless go had it's own makefile/configure/etc... parser.
If it is not automatic and the user can inspect the build commands. I believe it's no more dangerous than putting in a readme asking users to download and install a C library,
The text was updated successfully, but these errors were encountered:
go get was running the commands automatically without the user knowing before hand so I can understand why blocking that would be important. However if a user has to opt in with a flag then they are given the chance to audit the commands and is not any more harmful than a line in the readme saying go download and install this lib running these commands.
I'm quite confident everyone would agree that dealing with C deps is a huge pain compared to go packages. I'm even developing a build command for my package to pull and build C deps before building the package.
When I saw vgo I thought, it would be nice if this did the work instead of having to write a build command. I know that would mean allowing arbitrary code execution unless go had it's own makefile/configure/etc... parser.
If it is not automatic and the user can inspect the build commands. I believe it's no more dangerous than putting in a readme asking users to download and install a C library,
The text was updated successfully, but these errors were encountered: