bash shouldn't be assumed to be in /bin for portability

[jgedarovich]

No description provided.

[pda]

Howdy @jgedarovich 👋🏼
Sorry for taking a long time to reply.

Could you describe the problem you're encountering?

The bash scripts this PR changes can be categorised into:

• .buildkite/* — CI build & release process.
• *_test.go — some integration tests that write and execute temporary shell scripts.
• install.sh— bash install script (designed to be piped into bash -c?)
• packaging/docker/*/entrypoint.sh — docker entrypoints for specific base images
• packaging/linux/root/usr/share/buildkite-agent/hooks/*.sample — sample hooks, could run on any system
• scripts/*.sh — I believe these are primarily used in the CI build & release process

Of those, I can imagine these might have portability issues:

• *_test.go — for running integration tests on machines without /bin/bash
• …/hooks/*.sample — when installed on machines without /bin/bash, and then customised by the user without fixing the shebang.

While /bin/bash is less flexible/portable, the tradeoff of /usr/bin/env bash is susceptibility to $PATH manipulation; where an attacker could trick the agent or its operator into running a malicious bash command elsewhere on the system. Admittedly this seems like a far-fetched scenario, and control over $PATH would be bad anyway.

I'd be interested to hear if you're running into one of the described scenarios, or something I didn't think of.