`shellEnvBlock` should block `*PASSWORD*`, `*TOKEN*`, `*SECRET*`, etc. by default?

[AkihiroSuda]

lima/pkg/envutil/envutil.go

Lines 14 to 43 in 9e96fe1

	// defaultBlockList contains environment variables that should not be propagated by default.
	var defaultBlockList = []string{
	"BASH*",
	"DISPLAY",
	"DYLD_*",
	"EUID",
	"FPATH",
	"GID",
	"GROUP",
	"HOME",
	"HOSTNAME",
	"LD_*",
	"LOGNAME",
	"OLDPWD",
	"PATH",
	"PWD",
	"SHELL",
	"SHLVL",
	"SSH_*",
	"TERM",
	"TERMINFO",
	"TMPDIR",
	"UID",
	"USER",
	"XAUTHORITY",
	"XDG_*",
	"ZDOTDIR",
	"ZSH*",
	"_*", // Variables starting with underscore are typically internal
	}

I thought the list was initially designed to block *PASSWORD*, *TOKEN*, *SECRET*, etc. by default, but did we change the design on purpose? (because the list cannot be robust?)

Can't find the relevant conversation in:

• Add a --with-env flag to limactl shell #3430
• implement preserving env from host into vm in shell command #3830

[jandubois]

I thought the list was initially designed to block *PASSWORD*, *TOKEN*, *SECRET*, etc. by default, but did we change the design on purpose? (because the list cannot be robust?)

I suggested this in #3852, which is about making it possible (still with opt-in) to enable --preserve-env by default.

That discussion is not yet finished, even the latest suggestion is kind of complex.

#4036 will be required to make an extend blocklist usable. Because right now LIMA_SHELLENV_ALLOW blocks everything not in the allow list, so if you need to specify one exception to an exhaustive block list, you will have to specify all variables you want to pass.

That's why I think at least the first part, but ideally all of #4036 should be implemented before 2.0. Then we can figure out how to expand the feature in a backwards compatible manner afterwards.