I think the concept is fine, my main nit is: do we want to call this secure_setenv for symmetry with the secure_getenv name we use in libc, for use in security-sensitive getenv() calls?

In D56287#1287801, @kevans wrote:

I think the concept is fine, my main nit is: do we want to call this secure_setenv for symmetry with the secure_getenv name we use in libc, for use in security-sensitive getenv() calls?

Good question, I chose boot_setenv to as that seemed to fit with what subr_boot.c looked like, but I'm not wedded to any name

In D56287#1287811, @imp wrote:

I like this, and also @kevans 's suggestion.

So rename it to secure_setenv ?

In D56287#1287814, @sjg wrote:

In D56287#1287811, @imp wrote:

I like this, and also @kevans 's suggestion.

So rename it to secure_setenv ?

Actually I'm not sure that's a good idea, boot_setenv makes no promise about any care it might take, and if check_restricted is false it just calls setenv.
secure_setenv might be appropriate if it for example forced check_restricted true, but that could easily be a POLA violation.