[allow-insecure] Allow insecure packages with --allow-insecure flag

[mikeland73]

Summary

This allows installing insecure packages using the --allow-insecure flag:

devbox add nodejs@16 --allow-insecure

This saves the allow insecure state to lock file.

If user tries to do add/shell/run/install and there are insecure pacakges that are not in marked in lock file, they will see an error indicating they should use flag.

I used flag (instead of prompt) to limit the size of this already massive PR. TODO (in follow up):

• When installing an insecure package, ask the user if they want to allow it, update the devbox.json, and install it.

How was it tested?

devbox add nodejs@16
devbox add nodejs@16 --allow-insecure
devbox run run_test
# edited lockfile to remove allow_insecure
devbox run run_test # error
devbox install # error
devbox shell # error

See examples/insecure

[gcurtis]

@mikeland73 should I hold off on reviewing this for now?

[LucilleH]

Will this error for the fallthrough case?

[mikeland73]

good catch. Will test and fix.

[mikeland73]

This works, because in the fallthrough case resolve works fine. It actually enters non-fallthrough packages twice (and then cleans it up when lock.Tidy() is called). I'm gonna see if I can make this better.

[LucilleH]

So this will add allow insecure field to all the packages in the add command, even though some of them may not need allow insecure?

[mikeland73]

Yeah. The idea is that the flag affects all packages being added in that command. e.g.

devbox add curl go --allow-insecure will mark both of them as allow insecure. If user only wants it to apply to one of them, they should add one at a time.

I think this is a reasonable tradeoff, otherwise we probably end up needing a new cli command e.g. devbox allow-insecure <pkg> or something like that.

[LucilleH]

😭

[mikeland73]

yeah this is not the best. An alternative is to loop though all packages and check if any of them are insecure, that would make errors much slower so it's a tradeoff.