Baseten Truss
external_data Dockerfile

truss/templates/server.Dockerfile.jinja, external_data RUN · truss/util/jinja.py · serving_image_builder.py dest list · tests in test_jinja.py

This is the finding that matters. The builder walks external_data and emits one RUN per file. On 40ba448 the URL was interpolated into a double-quoted shell argument. That is not quoting. It is wrapping. The first " inside the value ends the wrap.

RUN mkdir -p {{ dst.parent }}; curl -L "{{ url }}" -o {{ dst }}

The public example from the pull request is enough to see the break. A yaml value of the form http://example.com/x" ; command ; echo " produces a RUN where command is no longer an argument to curl. It is a sibling command in the same shell line. It runs when the image is built.

Truss already had dockerfile_env_value for ENV SERVER_START_CMD. That filter follows BuildKit's double-quoted ENV rules. It escapes ", \, and $. RUN is not ENV. Docker still hands the line to /bin/sh. In that shell, backticks and $() still run. cretz wrote the review in those words. A URL like http://example.com/`cmd` still executed under the ENV filter. The test test_env_filter_still_executes_backticks_in_posix_sh keeps that fact on the record so nobody puts the ENV filter back on this line.

RUN mkdir -p {{ dst.parent | string | dockerfile_shell_value }}; curl -L {{ url | dockerfile_shell_value }} -o {{ dst | string | dockerfile_shell_value }}

dockerfile_shell_value is shlex.quote. It uses single quotes. That stops the substitutions /bin/sh would still make after ENV quoting. Line breaks are rejected without echoing the value, because a URL can embed a secret.

The check you think you have is "this field is a URL, so curl fetches it." That check does not hold when the value can close the quote. A pass on a config review that only looks at the host name is a miss. I did not call it Critical. No funds move. The process that runs the extra command is the build you already started.

serving_image_builder.py dest construction on 5ff9717. Fixed in PR 2627.

The image is Linux. The dest is supposed to be /app/data/<local_data_path>. The builder used the host's pathlib.Path and called resolve() on it:

data_dir = Path("/app/data/")
(data_dir / ext_file.local_data_path).resolve()

On Windows that becomes C:\app\data\weights\model.bin. That string went into the Dockerfile curl -o line. The file is then not where the model looks. I hit this while adding tests for PR 2616. Windows CI produced the drive path, so those tests dropped the /app/data assertion just to stay green. The generated Dockerfile was still wrong for anyone running truss build on Windows with external_data.

truss migrate already built the same path with PurePosixPath. PR 2627 matches that. After the merge the dest is a POSIX container path on every host.

container_data_dir = PurePosixPath("/app/data")
container_data_dir / ext_file.local_data_path

The image still builds. The weights land in the wrong place, so the model misses them. That is a quiet failure on a host OS a lot of contributors use. It is not extra shell. It is not a quote breakout.

PR 2486 by lollinng. download_external_data. Open on 7 September 2026.

The runtime downloader checks that local_data_path stays inside the data directory before it writes. The check uses path.parents without resolving .. first, so a value like ../evil.bin can pass the guard and still write outside the directory after resolve(). That is a different function from the Dockerfile curl line. PR 2616 does not close it. I am not scoring it here. I am saying it is still open, so nobody should treat the build-time quote fix as the whole external_data story.