This is indeed a useful approach to limiting the scope of environment variables, and I try to use that rather than exporting when possible. Using files (especially "special" files like the command-substitution fd…
As pointed out by evgpbfhnr, I do avoid using environment variables and justify it (though with different reasoning than yours). Your justification is the kind of thing I mention as out-of-scope (for my purposes!) in my…
Process substitution (the `<(echo ...)` approach I used in the post) is practically equivalent to this, creating a path that can be read by the shell and its child processes (and, at least as expanded, _only_ by them)…
I touch on this possibility with the `rbw` example: >`$ token=$(rbw get gitlab-access-token) # get the token from a command-line password manager`
It's definitely a powerful approach; I don't think it's particularly viable for the sort of use cases where you're throwing secrets around in a shell: - It's not supported natively by most software (if I wanted to use…
As I mention in the post: >One way to avoid this is to prevent the command from being written to history. Bash has a configuration variable named HISTCONTROL, which when set to include ignorespace prevents commands…
"reproducible" means you get the same result, bit-for-bit, when running a build in different circumstances. It's trivial to write non-reproducible Nix derivations by placing timestamps, randomly generated data, or…
I've been planning to implement NixOS tests based on virtiofs instead of 9p for a while, but haven't got it working yet (at the time I tried, the available uid mapping strategies didn't cover what was needed for NixOS…
Great job, me. I fixed it in the source but didn't deploy it to the site. Thanks for pointing it out!
It doesn't actually go through a "real network" at all, the VM speaks 9p to the host via a virtio pipe (not sure what the technically correct term for this is) so there's none of the overhead that you'd have with…
This is indeed a useful approach to limiting the scope of environment variables, and I try to use that rather than exporting when possible. Using files (especially "special" files like the command-substitution fd…
As pointed out by evgpbfhnr, I do avoid using environment variables and justify it (though with different reasoning than yours). Your justification is the kind of thing I mention as out-of-scope (for my purposes!) in my…
Process substitution (the `<(echo ...)` approach I used in the post) is practically equivalent to this, creating a path that can be read by the shell and its child processes (and, at least as expanded, _only_ by them)…
I touch on this possibility with the `rbw` example: >`$ token=$(rbw get gitlab-access-token) # get the token from a command-line password manager`
It's definitely a powerful approach; I don't think it's particularly viable for the sort of use cases where you're throwing secrets around in a shell: - It's not supported natively by most software (if I wanted to use…
As I mention in the post: >One way to avoid this is to prevent the command from being written to history. Bash has a configuration variable named HISTCONTROL, which when set to include ignorespace prevents commands…
"reproducible" means you get the same result, bit-for-bit, when running a build in different circumstances. It's trivial to write non-reproducible Nix derivations by placing timestamps, randomly generated data, or…
I've been planning to implement NixOS tests based on virtiofs instead of 9p for a while, but haven't got it working yet (at the time I tried, the available uid mapping strategies didn't cover what was needed for NixOS…
Great job, me. I fixed it in the source but didn't deploy it to the site. Thanks for pointing it out!
It doesn't actually go through a "real network" at all, the VM speaks 9p to the host via a virtio pipe (not sure what the technically correct term for this is) so there's none of the overhead that you'd have with…