alerts](./alerts.md) and need some way to integrate with the host’s
[MTA]. There are a number of alternatives in that linked document, so
for the sake of discussion, we’ll say you’ve chosen [Method
2](./alerts.md#db), which requires a Tcl interpreter and its SQLite
extension to push messages into the outbound email queue DB, presumably
bind-mounted into the container.

One way to do that is to replace STAGE 2 and 3 in the stock `Dockerfile`
with this:

```
    ## ---------------------------------------------------------------------
    ## STAGE 2: Pare that back to the bare essentials, plus Tcl.
    ## ---------------------------------------------------------------------
    FROM alpine AS run
    ARG UID=499
    ENV PATH "/sbin:/usr/sbin:/bin:/usr/bin"
    COPY --from=builder /tmp/fossil /bin/

    RUN set -x                                                              \
        && echo "fossil:x:${UID}:${UID}:User:/museum:/false" >> /etc/passwd \
        && echo "fossil:x:${UID}:fossil"                     >> /etc/group  \
        && install -d -m 700 -o fossil -g fossil log museum                 \
        && apk add --no-cache tcl sqlite-tcl
```

Build it and test that it works like so:

```
    $ make container-run &&
      echo 'puts [info patchlevel]' |
      docker exec -i $(make container-version) tclsh 
    8.6.12
```

You can remove the installation of `busybox-static` in STAGE 1 since
Alpine is already based on BusyBox.(^We can’t do “`FROM busybox`” since
we need `apk` in this new second stage. Although this means we end up
with back-to-back Alpine stages, it isn’t redundant; the second one
starts fresh, allowing us to copy in only what we absolutely need from
the first.) You should also remove the `PATH` override in the “RUN”
stage, since it’s written for the case where everything is in `/bin`.



Another useful case to consider is that you’ve installed a [server
extension](./serverext.wiki) and you need an interpreter for that
script. The first option above won’t work except in the unlikely case that
it’s written for one of the bare-bones script interpreters that BusyBox
ships.(^BusyBox’s `/bin/sh` is based on the old 4.4BSD Lite Almquist
shell, implementing little more than what POSIX specified in 1989, plus
equally stripped-down versions of AWK and `sed`.)

Let’s say the extension is written in Python. While you could handle it
the same way we do with the Tcl example above, because Python is more
popular, we have more options. Let’s inject a Python environment into
the stock Fossil container via a suitable “[distroless]” image instead:

```
    ## ---------------------------------------------------------------------
    ## STAGE 2: Pare that back to the bare essentials, plus Python.
    ## ---------------------------------------------------------------------
    FROM cgr.dev/chainguard/python:latest
    USER root
    ARG UID=499
    ENV PATH "/sbin:/usr/sbin:/bin:/usr/bin"
    COPY --from=builder /tmp/fossil /bin/
    COPY --from=builder /bin/busybox.static /bin/busybox
    RUN [ "/bin/busybox", "--install", "/bin" ]
    RUN set -x                                                              \
        && echo "fossil:x:${UID}:${UID}:User:/museum:/false" >> /etc/passwd \
        && echo "fossil:x:${UID}:fossil"                     >> /etc/group  \
        && install -d -m 700 -o fossil -g fossil log museum
```






Build it and test that it works like so:

```
    $ make container-run &&
      docker exec -i $(make container-version) python --version 
    3.11.2
```

Relative to the Tcl example, the change from “`alpine`” to [Chainguard’s
Python image][cgimgs] means we have no BusyBox environment to execute
the `RUN` command with, so we have to copy the `busybox.static` binary
in from STAGE 1 and install it in this new STAGE 2 for the same reason
the stock container does.(^This is the main reason we change `USER`
temporarily to `root` here.) There are a few other steps required to
avoid causing a conflict between our previously bare-bones “OS” layer
and what the Chainguard image provides. The compensation for this hassle

is huge: we no longer leave a package manager sitting around inside the
container, waiting for some malefactor to figure out how to abuse it.

Beware that there’s a limit to this über-jail’s ability to save you when
you go and provide a more capable OS layer like this. The container
layer should stop an attacker from accessing any files out on the host
that you haven’t explicitly mounted into the container’s namespace, but