Problem
When running `netclaw status` inside the official Docker container (built via `scripts/docker/build-image.sh`), update checks fail with:
```
update: unknown (check failed [Could not initialize platform-specific components. NSec may not be supported on this platform. See https://nsec.rocks/docs/install for more information.] — run 'netclaw update --check' to retry)
```
Root Cause
The update check pipeline uses `MinisignVerifier.Verify()` which depends on `NSec.Cryptography` for Ed25519 signature verification. NSec relies on platform-specific native crypto bindings that are not included in self-contained single-file publishes targeting Ubuntu 24.04 containers.
The Dockerfile publishes with:
```
dotnet publish -c Release -r linux-x64 --self-contained true /p:PublishSingleFile=true /p:EnableCompressionInSingleFile=true /p:IncludeNativeLibrariesForSelfExtract=true
```
Despite `IncludeNativeLibrariesForSelfExtract=true`, NSec's native components fail to initialize at runtime inside the container.
Affected Paths
All three update check paths funnel through `MinisignVerifier.Verify()`:
- CLI `status` command
- Daemon `BinaryUpdateCheckService` (startup + periodic)
- CLI background update check
Proposed Fixes
Short-term: Graceful degradation
Make `MinisignVerifier.Verify()` catch NSec initialization failures and return a non-fatal result (e.g., `VerifyResult.Unavailable`) instead of throwing. This lets update checks show as "unknown" rather than erroring loudly.
Medium-term: Container hardening
Either:
- Add required NSec native dependencies to the Dockerfile (`apt-get install`)
- Or use `NETCLAW_DAEMON_DISABLEUPDATES=true` in containers (see companion issue about config option)
- Or make the self-contained publish explicitly include NSec runtime natives
Long-term: Alternative verification
Consider a pure-managed Ed25519 implementation as fallback when NSec is unavailable, avoiding native dependency entirely for the update check path.
Reproduction
```bash
cd /home/petabridge/repositories/stannardlabs/netclaw
./scripts/docker/build-image.sh
docker run --rm ghcr.io/aaronontheweb/netclawd:dev netclaw status
```
Related
- Companion issue: add config option to disable update checks entirely (for containers where image = versioned artifact)
Problem
When running `netclaw status` inside the official Docker container (built via `scripts/docker/build-image.sh`), update checks fail with:
```
update: unknown (check failed [Could not initialize platform-specific components. NSec may not be supported on this platform. See https://nsec.rocks/docs/install for more information.] — run 'netclaw update --check' to retry)
```
Root Cause
The update check pipeline uses `MinisignVerifier.Verify()` which depends on `NSec.Cryptography` for Ed25519 signature verification. NSec relies on platform-specific native crypto bindings that are not included in self-contained single-file publishes targeting Ubuntu 24.04 containers.
The Dockerfile publishes with:
```
dotnet publish -c Release -r linux-x64 --self-contained true /p:PublishSingleFile=true /p:EnableCompressionInSingleFile=true /p:IncludeNativeLibrariesForSelfExtract=true
```
Despite `IncludeNativeLibrariesForSelfExtract=true`, NSec's native components fail to initialize at runtime inside the container.
Affected Paths
All three update check paths funnel through `MinisignVerifier.Verify()`:
Proposed Fixes
Short-term: Graceful degradation
Make `MinisignVerifier.Verify()` catch NSec initialization failures and return a non-fatal result (e.g., `VerifyResult.Unavailable`) instead of throwing. This lets update checks show as "unknown" rather than erroring loudly.
Medium-term: Container hardening
Either:
Long-term: Alternative verification
Consider a pure-managed Ed25519 implementation as fallback when NSec is unavailable, avoiding native dependency entirely for the update check path.
Reproduction
```bash
cd /home/petabridge/repositories/stannardlabs/netclaw
./scripts/docker/build-image.sh
docker run --rm ghcr.io/aaronontheweb/netclawd:dev netclaw status
```
Related