Coral issues found during the XLibre desktop ports effort

Bug reports / improvement notes for the Coral team (we do not patch Coral source — per project policy). File these upstream as appropriate.

---

CORAL-1: coral build <category>/<name> (relative path) fails exit 127

• Found: 2026-07-22, building base/util-macros on hh-alpha9 (Hammerhead), coral 0.4.5.
• Severity: High (blocks every relative-path build; silent-ish — exits 127 with a confusing "can't open input file" error).

Symptom

$ cd /usr/zports && coral build base/util-macros -y
...
cd "$SRCDIR" && export ... && zsh "base/util-macros/build.sh"
zsh: can't open input file: base/util-macros/build.sh    # exit 127

Root cause (from reading Coral source — NOT modified)

coral build <category>/<name> stores the CLI path string verbatim as port.port_dir
(src/core/port.reef:397 — port.port_dir = port_path). Later, the build step joins it
with build.sh (src/commands/build.reef:974 — path.join_path(ctx.port.port_dir, "build.sh"))
and hands that relative path to a shell that has already cd'd into $SRCDIR (the
extracted-tarball work dir). Because cwd changed, the relative port path no longer resolves,
so zsh <relative>/build.sh can't find the script. Happens for any relative CLI port argument
regardless of the invoking cwd.

Workaround (in use)

Always pass an absolute port path:

coral build /usr/zports/base/util-macros -y      # works

Suggested fix (for the Coral team)

Resolve port_dir to an absolute path at load time (in port.reef when port_dir is set),
or compute build.sh's absolute path before the cd "$SRCDIR" in build.reef, so the
build-script path is independent of the shell's working directory.

---

CORAL-2: source download fails against some HTTPS hosts that system curl fetches fine

• Found: 2026-07-22, building devel/nasm on hh-alpha9 (Hammerhead), coral 0.4.5.
• Severity: Medium (blocks coral build for any port sourced from an affected host;
  has a reliable workaround, so not a hard blocker).

Symptom

$ coral build /usr/zports/devel/nasm -y
...
-> Downloading sources...
error: Failed to download: nasm-2.16.03.tar.xz (all sources failed)
error: Failed to download sources

No further detail in either the console output or the per-build log
(.../coral-build-nasm-*.log — just "Failed to download sources", nothing from
the underlying transport). -v/--verbose on the build subcommand adds nothing.

What did NOT reproduce it

• curl -L -f -s -S -o ... https://www.nasm.us/pub/nasm/releasebuilds/2.16.03/nasm-2.16.03.tar.xz
  (the exact flag set strings /usr/bin/coral shows coral invoking) succeeds from the
  same host, as both root and the unprivileged zygaena build user.
• Same URL over plain openssl s_client completes a full TLS handshake and the server
  presents a chain openssl considers valid.
• The same port category/build machinery worked fine minutes earlier and later for
  base/util-macros (xorg.freedesktop.org), lang/python (www.python.org),
  devel/ninja (github.com/codeload.github.com) — all HTTPS, all succeeded via
  coral build's normal download path.

Suspected root cause (not confirmed — read-only investigation, Coral not modified)

The one systematic difference found between the failing host and the working ones is
the TLS certificate chain's intermediate/root naming:

$ echo | openssl s_client -connect www.nasm.us:443 -servername www.nasm.us
 0 s:CN=www.nasm.us
   i:C=US, O=Let's Encrypt, CN=YR2      <-- unusual intermediate name

vs. e.g. xorg.freedesktop.org's chain terminating in the well-known ISRG Root X1 /
R13 naming. strings /usr/bin/coral shows the binary statically links its own
OpenSSL (many OSSL_*/SSL_CTX_* symbols) rather than shelling out to the system's
curl/OpenSSL for the actual source-tarball fetch (curl only shows up in strings next
to repository-manifest/signature messages, e.g. (using curl) ..., No signature found (repo.toml.sig)). Working theory: coral's statically-linked OpenSSL carries an
older/incomplete embedded CA trust store that doesn't recognize this particular
Let's Encrypt intermediate, while the system curl/openssl (using the OS trust
store) verifies it fine. Not confirmed with a packet capture — filed as a lead, not
a diagnosis, for the Coral team to verify against their embedded trust store.

Workaround (in use)

Pre-populate coral's source cache before calling coral build — coral trusts a
checksum-matching file already sitting in [paths].sources (/usr/zports/pkgs/sources
by default) and skips its own download entirely:

# download with system curl (or scp from a host that can), verify sha256 first
curl -sL -o nasm-2.16.03.tar.xz https://www.nasm.us/pub/nasm/releasebuilds/2.16.03/nasm-2.16.03.tar.xz
sha256sum nasm-2.16.03.tar.xz   # confirm matches package.toml's checksum
scp nasm-2.16.03.tar.xz root@<build-host>:/usr/zports/pkgs/sources/nasm-2.16.03.tar.xz
coral build /usr/zports/devel/nasm -y   # now logs "Using cached: nasm-2.16.03.tar.xz"

Confirmed both devel/nasm (nasm.us) and, pre-emptively for devel/ninja/devel/meson
(github.com), that priming the cache this way lets coral build proceed normally
(checksum verify → extract → build) with no other change needed.

Suggested fix (for the Coral team)

1. Surface the underlying TLS/transport error instead of the generic "Failed to
   download: ... (all sources failed)" — even the per-build log has nothing more
   specific, making this look identical to a dead URL or an actual checksum failure.
2. Refresh/replace the embedded CA trust store (or link against the system trust
   store / system curl for source fetches) so coral build isn't a stricter TLS
   client than the OS it runs on.