novasamatech/parity-signer

Bugrisk : Set the SHELL option -o pipefail before using RUN with a pipe character

philipjonsen opened this issue · 2 comments

DESCRIPTION
Some RUN commands depend on the ability to pipe the output of one command into another, using the pipe character (|), as in the following example:

RUN wget -O - https://some.site | wc -l > /number
Docker executes these commands using the /bin/sh -c interpreter, which only evaluates the exit code of the last operation in the pipe to determine success. In the example above this build step succeeds and produces a new image so long as the wc -l command succeeds, even if the wget command fails.

If you want the command to fail due to an error at any stage in the pipe, prepend set -o pipefail && to ensure that an unexpected error prevents the build from inadvertently succeeding.

Since there are some shells that do not accept the -o pipefail option, it is not enough to add set -o pipefail inside the RUN instruction. Therefore, we recommend to always explicitly set the SHELL before using pipes in RUN.

You can read more about best practices of using pipes here.

BAD PRACTICE

RUN wget -O - https://some.site | wc -l > /number

RECOMMENDED

SHELL ["/bin/bash", "-o", "pipefail", "-c"]
RUN wget -O - https://some.site | wc -l > /number
Or in case of busybox in an Alpine image:

SHELL ["/bin/ash", "-eo", "pipefail", "-c"]
RUN wget -O - https://some.site | wc -l > /number

Set the SHELL option -o pipefail before RUN with a pipe in it. If you are using /bin/sh in an alpine image or if your shell is symlinked to busybox then consider explicitly setting your SHELL to /bin/ash, or disable this check here: parity-signer/blob/master/docker/Dockerfile#L20-L20

krodak commented

@prybalko do you find it relevant for any of your flows? I think iOS github workflow actions are fine, same goes for custom scripts, as we don't require any custom error handling.
If it's same for you, we could close this one down

@prybalko do you find it relevant for any of your flows? I think iOS github workflow actions are fine, same goes for custom scripts, as we don't require any custom error handling. If it's same for you, we could close this one down

Agreed