# 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.