Install fails on docker GO run

[obones]

Hello,

I must have missed something, but when I run ./redamon.sh install, after a while I get this error:

Dockerfile:18

--------------------

  16 |     # osv-scanner v2.4.0 needs Go >= 1.26.4; build it here and COPY the binary.

  17 |     FROM golang:1-bookworm AS osv-builder

  18 | >>> RUN GOBIN=/out go install github.com/google/osv-scanner/v2/cmd/osv-scanner@v2.4.0

  19 |

  20 |     FROM python:3.11-slim-bookworm

--------------------

target supply-chain: failed to solve: process "/bin/sh -c GOBIN=/out go install github.com/google/osv-scanner/v2/cmd/osv-scanner@v2.4.0" did not complete successfully: exit code: 1

What have I missed?

[dfbustosus]

You have not missed an installation step. The likely cause is a stale cached copy of the moving golang:1-bookworm image.

osv-scanner v2.4.0 declares Go 1.26.4 as its minimum. A Go 1.26.3 image fails at that exact command, and the official image sets GOTOOLCHAIN=local, so it will not download a newer compiler automatically.

First confirm which compiler Docker is actually using, forcing a fresh image pull:

docker run --rm --pull=always golang:1-bookworm go version

Then refresh the builder images and rebuild the affected services:

docker compose --profile tools build --pull supply-chain supply-chain-analyzer
./redamon.sh install

If BuildKit still reuses the old layer, retry once without cache:

docker compose --profile tools build --pull --no-cache supply-chain supply-chain-analyzer

The excerpt above contains only Docker's final wrapper error. If it still fails after the pull, please include the preceding go: output; a network/module-download failure would need a different diagnosis.

There is also a reproducibility issue in the repository. Both supply_chain_scan/Dockerfile and supply_chain_analyzer/Dockerfile use the mutable golang:1-bookworm tag while the comment requires a specific minimum. Pinning a tested patch release, for example golang:1.26.8-bookworm, would prevent a cached 1.26.3 image from producing this failure. Upstream's v2.4.0 Dockerfile likewise pins its Go builder image.

[obones]

Thanks for the pointers on looking at the preceding lines, in some instances it contained a hint about SSL errors or automatically closed connections.
As it turns out, the company security system intercepts some SSL connections and resigns them with a local certificate. Our computers have its root in the store deployed via GPO, but that does not happen in docker containers.
I had to modify most to include those two lines:

COPY umbrella.crt /usr/local/share/ca-certificates/umbrella.crt
RUN update-ca-certificates

This allowed to move forward much more but the kali image is giving me lots of grief because the same security system simply kills some downloads:

164.1 Setting up python3-flask (3.1.3-4) ...
164.2 Setting up python3-httpx (0.28.1-1.1) ...
164.3 Processing triggers for libc-bin (2.43-4) ...
164.4 E: Failed to fetch http://mirror.fr.cdn-perfprod.com/kali/pool/main/i/impacket/python3-impacket_0.13.0+git20251120-9c2d8b6-0kali1_all.deb?X-OpenDNS-Session=_5baba7ee001e804a430be9c0647fe5a31d379270fc47_GKp592sv_  Error reading from server. Remote end closed connection [IP: 146.112.56.228 80]
164.4 E: Failed to fetch http://kali.download/kali/pool/main/m/masky/python3-masky_0.2.1-0kali1_all.deb?X-OpenDNS-Session=_c2c796c40334f04554087890a4dbbb99223f9270fc47_sPF6M3Va_  Error reading from server. Remote end closed connection [IP: 146.112.56.37 80]

Would it be possible to remove some packages from the mcp/kali-sandbox/Dockerfile file instructions that update the base Kali image?

If so, what would be the expected consequences?

[dfbustosus]

@obones That output confirms a separate corporate-network issue. The X-OpenDNS-Session rewrite shows Umbrella/OpenDNS handling and terminating these downloads. Adding the corporate CA is appropriate for TLS interception, but it cannot fix an intentionally blocked HTTP download.

The two failing packages are not explicitly listed in RedAmon's APT install command. With the current Kali metadata, they are mandatory transitive dependencies:

• netexec depends on both python3-impacket and python3-masky.
• enum4linux-ng also depends on python3-impacket.

Therefore:

• Removing only netexec avoids python3-masky, but enum4linux-ng still pulls python3-impacket.
• Removing both netexec and enum4linux-ng should prevent APT from selecting either failing package with the current dependency graph.
• --no-install-recommends or --fix-missing will not help because these are hard dependencies.

The consequence is loss of the nxc multi-protocol exploitation tool and the standalone enum4linux-ng Windows/Samba enumeration tool. The five MCP server modules themselves do not import either tool, as shown by the image's build-time smoke test, so service startup should remain unaffected. Some AD/Windows skills and generic kali_shell workflows that expect nxc or enum4linux-ng will fail or be degraded.

Impacket is also installed separately into /opt/venv through mcp/requirements.txt, and the Dockerfile creates impacket-* aliases. Those commands should remain available after removing the two APT tools, provided PyPI downloads are allowed.

The more complete fix is to ask the security team to allow the Kali repository and redirected mirror hosts, or provide an approved internal mirror/cache. The Dockerfile permits HTTPS-to-HTTP Kali mirror redirects, so allowing only kali.download may not be sufficient. Kali also documents how to run a private mirror.

[obones]

Thanks for the confirmation, I was able to build all the docker files with just a few things removed.

Now, I'm moving to the "start" part and getting this:

[INFO] Starting services...
WARN[0000] volume "redamon-osv-db" already exists but was not created by Docker Compose. Use `external: true` to use an existing volume
WARN[0000] volume "redamon-sca-intel" already exists but was not created by Docker Compose. Use `external: true` to use an existing volume
[+] up 6/7
 ✔ Container redamon-docker-broker      Started                                                                                          10.6s
 ✔ Container redamon-kali               Started                                                                                          10.6s
 ✔ Container redamon-postgres           Started                                                                                          10.6s
 ⠼ Container redamon-recon-orchestrator Starting                                                                                         10.6s
 ✔ Container redamon-neo4j              Started                                                                                          10.6s
 ✔ Container redamon-webapp             Recreated                                                                                         0.1s
 ✔ Container redamon-agent              Recreated                                                                                         0.1s
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/mnt/wsl/rancher-desktop/run/docker-mounts/f9c0e629-f6a6-421e-bfec-2e98d9f2bba1" to rootfs at "/app/recon/output": create mountpoint for /app/recon/output mount: make mountpoint "/app/recon/output": mkdirat /var/lib/docker/overlay2/8c5b46975cc2bcdad71d8cf5e32bbd24867540e67c0c039f2ba88349f0acdab5/merged/app/recon/output: read-only file system

From what I read around, this could be related to not enough free disk space for the containers, but I checked, there are more than 20G available. Is that not enough?

[obones]

Ok, no, it's an issue with Rancher Desktop but removing the ro flags allowed to run to completion

[obones]

Ok, I gave up altogether, moved to an out of corporate network VM instead of WSL and it started working much better.