,jd fails with 'Exception in hmac: crypto error (rc=-2)' after ,unlock #87

New issue

Open

opened 2026-09-16 23:01:20 -04:00 by ober · 0 comments

ober commented

2026-09-16 23:01:20 -04:00

Owner

Summary

On macOS, after a successful ,unlock ("Unlocked 806 embedded files."), every
,jd command fails immediately:

jdisk error: Exception in hmac: crypto error (rc=-2)

Reproduced with ,jd ls while the embed store is unlocked.

Reproduction

Start the shell.
,unlock → passphrase accepted, files unlocked.
,jd ls → jdisk error: Exception in hmac: crypto error (rc=-2)

Environment

Host: macOS (darwin), jsh-macos binary
jerboa-shell VERSION: 0.10.53

Analysis

The error chain:

jdrive's per-component name encryption runs HKDF-SHA256
(vendor/jerboa-shell-extras/vendor/jerboa-drive/jdrive/s3/namecrypto.ss,
hkdf-sha256-expand, and component-nonce), calling hmac-sha256 from the
(jerboa-crypto) library.
(jerboa-crypto)'s hmac calls the C entry jerboa_hmac and raises
(error 'hmac "crypto error (rc=...)") via check-rc
(jerboa-crypto/src/jerboa-crypto.ss:278-280), which is what prints as
Exception in hmac: crypto error (rc=-2).
rc -2 comes from the ffi shim jerboa_hmac
(support/extras-jdisk-crypto-compat.c:286-296): it returns -2 whenever
jerboa_hmac_sha256 (the ring-backed Rust native) returns non-zero — which
includes the dynamic-stub path where dlsym("jerboa_hmac_sha256") fails and
the resolver returns -1 (jc_hmac_sha256, lines 77-83).

So the hmac native symbol is effectively missing/unresolvable in this build.
Note the mainline builds dropped the OpenSSL jerboa-crypto shim in favor of the
Rust ring natives; jdrive/jdisk still reaches jerboa_hmac through the
(jerboa-crypto) ABI, and this is the integration seam that is broken on the
macOS binary at VERSION 0.10.53.

Suggested investigation

Confirm jerboa_hmac_sha256 is resolved (static link of libjerboa_native.a
vs JSH_FFI_DYNAMIC_STUB_EMBED dlsym path) in the failing jsh-macos build
and whether jerboa_hmac is routed through the ring native.
Check the macOS build (and make features-all extras integration) can perform
a hmac-sha256 round-trip, e.g. via
,jd unlock-test / a small HKDF name-encryption path, before ls.
Confirm unlock uses a different primitive path (PBKDF2/scrypt + chacha20 via
the natives) so ,unlock succeeds while name-crypto's HMAC path fails.

## Summary On macOS, after a successful `,unlock` ("Unlocked 806 embedded files."), every `,jd` command fails immediately: ``` jdisk error: Exception in hmac: crypto error (rc=-2) ``` Reproduced with `,jd ls` while the embed store is unlocked. ## Reproduction 1. Start the shell. 2. `,unlock` → passphrase accepted, files unlocked. 3. `,jd ls` → `jdisk error: Exception in hmac: crypto error (rc=-2)` ## Environment - Host: macOS (darwin), `jsh-macos` binary - jerboa-shell VERSION: `0.10.53` ## Analysis The error chain: 1. jdrive's per-component name encryption runs HKDF-SHA256 (`vendor/jerboa-shell-extras/vendor/jerboa-drive/jdrive/s3/namecrypto.ss`, `hkdf-sha256-expand`, and `component-nonce`), calling `hmac-sha256` from the `(jerboa-crypto)` library. 2. `(jerboa-crypto)`'s `hmac` calls the C entry `jerboa_hmac` and raises `(error 'hmac "crypto error (rc=...)")` via `check-rc` (`jerboa-crypto/src/jerboa-crypto.ss:278-280`), which is what prints as `Exception in hmac: crypto error (rc=-2)`. 3. rc `-2` comes from the ffi shim `jerboa_hmac` (`support/extras-jdisk-crypto-compat.c:286-296`): it returns `-2` whenever `jerboa_hmac_sha256` (the ring-backed Rust native) returns non-zero — which includes the dynamic-stub path where `dlsym("jerboa_hmac_sha256")` fails and the resolver returns `-1` (`jc_hmac_sha256`, lines 77-83). So the hmac native symbol is effectively missing/unresolvable in this build. Note the mainline builds dropped the OpenSSL jerboa-crypto shim in favor of the Rust ring natives; jdrive/jdisk still reaches `jerboa_hmac` through the `(jerboa-crypto)` ABI, and this is the integration seam that is broken on the macOS binary at VERSION 0.10.53. ## Suggested investigation - Confirm `jerboa_hmac_sha256` is resolved (static link of `libjerboa_native.a` vs `JSH_FFI_DYNAMIC_STUB_EMBED` dlsym path) in the failing `jsh-macos` build and whether `jerboa_hmac` is routed through the ring native. - Check the macOS build (and `make features-all` extras integration) can perform a `hmac-sha256` round-trip, e.g. via `,jd unlock-test` / a small HKDF name-encryption path, before `ls`. - Confirm unlock uses a different primitive path (PBKDF2/scrypt + chacha20 via the natives) so `,unlock` succeeds while name-crypto's HMAC path fails.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ober/jerboa-shell#87

No description provided.

Rows
Columns