| 30 Nov 2025 |
 Sofie 🏳️⚧️ (she/her) | it is far more portable(as in, works on non FHS systems like NixOS);and I don't really believe it could even cause vurnerbalities | 12:10:40 |
| Sofie 🏳️⚧️ (she/her) | * | 12:10:50 |
| Sofie 🏳️⚧️ (she/her) | * | 12:11:01 |
 522 it/its ⛯ΘΔ | i mean i guess if you consider "an attacker can put a malicious bash in your path" to be a vulnerability | 12:13:14 |
| 522 it/its ⛯ΘΔ | (but also they can put malicious "every other tool you use" in your path so) | 12:13:25 |
| 522 it/its ⛯ΘΔ | if your PATH is fucked then you are so very utterly fucked | 12:14:05 |
 aloisw | I suppose this is what they mean by "The nexus of the security vulnerability is that using #!/usr/bin/env ensures that the script itself is unable to sanitize the environment before relying upon it." But does any script actually do that? | 12:25:03 |
 Arian | In reply to @sofiedotcafe:matrix.org
it is far more portable(as in, works on non FHS systems like NixOS);and I don't really believe it could even cause vurnerbalities so /usr/bin/env bash is more portable than. /bin/bash. but less portable than /bin/sh is the thesis. but idk wtf the point is they’re trying to make | 12:28:25 |
| Arian | nobody is writing /usr/bin/env sh | 12:28:33 |
| Arian | Okay yeh if everyone writes POSIX shell /bin/sh is the way to go. but nobody writes POSIX shell. everyone writes bash | 12:29:06 |
| aloisw | Their point seems to be that folks write /usr/bin/env bash where /bin/sh might also work. | 12:29:25 |
| Arian | the problem is they’re argueing against people that were writing /bin/bash before we coerced them into writing /usr/bin/env bash | 12:29:55 |
| Arian | i.e. they’re barking up the wrong tree | 12:30:07 |
| Arian | Maybe we should replace all of it with:
#!/bin/sh
command bash
or something?
| 12:32:27 |
| Arian | as that’s “actually portable” unlike /usr/bin/env | 12:32:35 |
| 522 it/its ⛯ΘΔ | sanitize how
i mean you can tell env to unset PATH for you if you really want | 12:34:32 |
| 522 it/its ⛯ΘΔ | then you can go invent your own PATH | 12:34:39 |
| 522 it/its ⛯ΘΔ | oh, right, for bash | 12:34:51 |
| 522 it/its ⛯ΘΔ | okay, yeah, for scripts that are intended to be ran in an environment where the environment is totally attacker controlled, env is a bad move (but you probably wouldn't be using a bash script then, you'd probably just go compile a statically linked binary or something) | 12:35:42 |
|  @tinwood:matrix.org left the room. | 12:36:27 |
| aloisw | You can't with the #! because it only accepts a single argument though. | 13:07:07 |
| aloisw | Yes, I think what they mean is that the script can then set PATH at its top, but who does that (and even if they do, how often is it complete and correct). | 13:07:59 |
| 522 it/its ⛯ΘΔ | #!/usr/bin/env -S env --unset=HOME --unset=PATH bash | 13:11:14 |
| 522 it/its ⛯ΘΔ | boom | 13:11:15 |
| 522 it/its ⛯ΘΔ | :) | 13:11:16 |
| 522 it/its ⛯ΘΔ | (that second env can be a /usr/bin/env too) | 13:11:47 |
| 522 it/its ⛯ΘΔ | i think | 13:11:54 |
| aloisw | SYNOPSIS
env [-i] [name=value]... [utility [argument...]]
Oh no, -S might be a GNU extension… | 13:12:51 |
 Katalin 🔪 | not quite, macOS also has -S:
-S string
Split apart the given string into multiple strings, and process each of the resulting strings as separate
arguments to the env utility. The -S option recognizes some special character escape sequences and also
supports environment-variable substitution, as described below.
and it also says this, so FreeBSD at least should have it too
The -P, -S and -v options were added in FreeBSD 6.0.
| 15:39:21 |
| Katalin 🔪 | I wonder if there is caniuse.com but for unix system commands and their options :^) | 15:42:59 |
