feat: extract Rust SDK as five workspace crates

[FSM1]

Summary

• Extract five Rust crates (cipherbox-crypto, cipherbox-core, cipherbox-api-client, cipherbox-fuse, cipherbox-sdk) mirroring the TypeScript SDK hierarchy under a Cargo workspace
• Replace all duplicated crypto, domain, and API logic in the desktop app with crate imports — desktop reduced to a thin Tauri shell
• Add cross-language test vectors (tests/vectors/) with CI parity gate ensuring Rust and TypeScript produce identical crypto output
• Configure Release Please for all 5 Rust crates with workspace-level version tracking
• Move Windows WinFsp operations to crates/fuse/src/platform/windows/ (gap closure)
• Delete ~5,900 lines of orphaned/duplicated desktop code
• Security hardening: enable zeroize feature on ed25519-dalek, wrap keypair generation in Zeroizing<Vec<u8>>

Crate Architecture

cipherbox-crypto  ← AES-GCM, AES-CTR, ECIES, HKDF, Ed25519
cipherbox-core    ← folder/file/bin metadata, vault blob v2, IPNS records
cipherbox-api-client ← typed HTTP client for CipherBox API
cipherbox-fuse    ← FUSE filesystem (macOS/Linux/Windows platform modules)
cipherbox-sdk     ← sync daemon, upload queue, state management

Requirements Completed

RSDK-01 through RSDK-10 (all 10 Rust SDK Extraction requirements)

Test plan

• cargo check across all 5 crates (macOS FUSE feature)
• cargo test -p cipherbox-crypto — 5 cross-language parity tests pass
• Zero crate::fuse:: references remain in crate-side Windows files
• Desktop compiles against workspace crates (no duplicated logic)
• CI: workspace builds on macOS, Linux, Windows
• CI: cross-language parity gate (scripts/check-vector-parity.sh)

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Multi-crate Rust SDK released (crypto, core/domain, typed API client, FUSE, SDK) with cross-language test vectors and parity checks.

• Chores

  • Desktop rewired into a thin Tauri shell delegating crypto, sync, registry, API, and filesystem logic to new libraries.
  • CI switched to workspace-level Rust builds, added a vector-parity CI job and workspace caching, and added release automation for new crates.
  • VCS now ignores workspace build artifacts (target/).

• Documentation

  • Added Phase‑23 planning, validation, verification, and security review materials.

[coderabbitai]

Actionable comments posted: 13

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

crates/api-client/src/client.rs (1)

58-69: ⚠️ Potential issue | 🟠 Major

Drop the token read lock before awaiting the request.

Each helper (authenticated_get, authenticated_post, authenticated_multipart_post) holds the RwLockReadGuard across .send().await, blocking concurrent set_access_token/clear_access_token calls for the entire request duration. Clone the token before the await and drop the guard immediately.

♻️ Suggested fix

-        let token = self.access_token.read().await;
+        let token = self.access_token.read().await.clone();
@@
-        if let Some(ref t) = *token {
-            builder = builder.bearer_auth(t);
+        if let Some(t) = token.as_deref() {
+            builder = builder.bearer_auth(t);
         }

Apply to authenticated_post (lines 79–91) and authenticated_multipart_post (lines 125–137).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/api-client/src/client.rs` around lines 58 - 69, The helpers
authenticated_get, authenticated_post, and authenticated_multipart_post
currently hold the RwLockReadGuard (self.access_token.read().await) across
builder.send().await which blocks set_access_token/clear_access_token; change
each to clone the token out of the guard (e.g., let token_opt = (*token).clone()
or token.clone()), then drop the guard immediately (allow it to go out of scope)
before building/sending the request so the await happens without holding the
read lock and concurrent writers can proceed.

🧹 Nitpick comments (3)

.planning/security/REVIEW-2026-03-24-phase23.md (1)

10-10: Resolve internal contradiction in the report’s key-material handling claims.

The executive summary says key material is wrapped in Zeroizing<Vec<u8>> throughout, while HIGH-2 asserts a non-zeroizing private key return. Keep one consistent position based on the current implementation.

Also applies to: 69-89

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.planning/security/REVIEW-2026-03-24-phase23.md at line 10, The report
contains a contradiction between the executive summary claiming key material is
wrapped in Zeroizing<Vec<u8>> throughout and HIGH-2 claiming a non-zeroizing
private key return; inspect the actual implementation to confirm which is true,
then make the text consistent: either (A) if the code returns a non-zeroizing
private key, update the executive summary and any mentions of "throughout" to
qualify where Zeroizing is used and document the specific function/path that
leaks (refer to HIGH-2 and occurrences of "Zeroizing<Vec<u8>>"), or (B) if the
code already zeroizes everywhere, revise HIGH-2 to remove the false positive and
note the correct locations using Zeroizing; update all other instances in the
detailed findings (the section currently around the HIGH-2 discussion and the
executive summary) so both places say the same thing.

crates/crypto/src/ipns_name.rs (1)

13-25: Consider validating or constraining the public key length.

The function is pub and accepts &[u8], but line 22 casts len() to u8, which would silently truncate lengths > 255. While derive_ipns_name correctly constrains to 32 bytes via &[u8; 32], direct callers of this public helper could produce malformed protobuf.

🛡️ Suggested defensive fix

 pub fn encode_libp2p_public_key(ed25519_public_key: &[u8]) -> Vec<u8> {
+    debug_assert!(
+        ed25519_public_key.len() <= 255,
+        "Public key too long for single-byte length encoding"
+    );
     let mut buf = Vec::new();
     // Field 1 (Type): varint, field_number=1, wire_type=0 => tag = 0x08
     buf.push(0x08);

Alternatively, change the signature to &[u8; 32] to match Ed25519 key size.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/crypto/src/ipns_name.rs` around lines 13 - 25, The function
encode_libp2p_public_key currently casts ed25519_public_key.len() to u8 which
can truncate inputs >255; fix by enforcing Ed25519 key length: either change the
signature to accept &[u8; 32] or validate at the start of
encode_libp2p_public_key that ed25519_public_key.len() == 32 and return a
Result<Vec<u8>, Error> (or panic) on mismatch; perform the length check before
pushing the length byte and only cast to u8 after the check to avoid silent
truncation.

crates/core/src/decrypt.rs (1)

10-50: Keep the new core boundary typed; don’t return String errors.

These helpers are public cipherbox-core APIs, but they collapse JSON/base64/length/crypto failures into free-form Strings. That makes downstream handling ad hoc and hardens an unstructured error contract right as the crate is being extracted. Please map these cases into CoreError variants instead.

Also applies to: 54-89

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/core/src/decrypt.rs` around lines 10 - 50, Change the function
signature decrypt_metadata_from_ipfs_public (and the other helper in the 54-89
range) to return Result<FolderMetadata, CoreError> instead of Result<...,
String>, and map every failure path (serde_json::from_slice, hex::decode, IV
length check, base64 decode, folder_key try_into, and
crate::folder::decrypt_folder_metadata) into specific CoreError variants (e.g.,
ParseError, InvalidHex/InvalidIv, Base64Error, InvalidKeyLength, CryptoError)
instead of formatting free-form Strings; update error mapping calls to construct
the appropriate CoreError (preserving underlying error details where possible)
so callers receive structured CoreError variants rather than plain strings.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/ci.yml:
- Around line 669-674: The vector-parity job currently lists test in its needs,
which causes the job to be skipped when test is skipped; remove 'test' from the
needs array for the vector-parity job (the symbol to edit is the vector-parity
job's needs: entry) so it no longer depends on the test job, and if you want to
ensure the job still runs even when other jobs fail/are cancelled replace the
current if condition starts-with '!failure() && !cancelled()' with an always()
wrapper combined with your existing vector-change checks (e.g., if: always() &&
(needs.changes.outputs.desktop == 'true' || needs.changes.outputs.src ==
'true')).

In `@apps/desktop/src-tauri/src/fuse/mod.rs`:
- Around line 254-257: In the test module (mod tests) the import list includes
an unused symbol FolderEntry; remove FolderEntry from the use statement that
currently reads use cipherbox_core::folder::{FilePointer, FolderChild,
FolderEntry, FolderMetadata}; so the tests only import FilePointer, FolderChild,
and FolderMetadata to eliminate the unused import warning.

In `@crates/api-client/src/auth.rs`:
- Around line 58-67: The logout function currently uses the ? operator on
client.authenticated_post which lets transport errors bubble up; change logout
to await client.authenticated_post("/auth/logout", &()) into a Result (e.g., let
resp_result = client.authenticated_post(...).await) and handle both Err and Ok:
on Err log a warning (include the error) and continue to return Ok(()) so local
state can be cleared, and on Ok inspect resp.status() as before and warn on
non-success; reference the logout function and authenticated_post call when
making this change.

In `@crates/api-client/src/client.rs`:
- Around line 112-115: In get_bytes, currently any HTTP response is treated as
success; modify get_bytes to check resp.status().is_success() after awaiting
send() and before reading bytes, and if not successful return
ApiError::ApiResponse (include the response status and body/text for context)
instead of returning the raw bytes; reference the resp variable and the
get_bytes method so the change mirrors the pattern used in auth.rs, ipfs.rs, and
ipns.rs where non-success statuses are converted to ApiError::ApiResponse.

In `@crates/api-client/src/types.rs`:
- Around line 139-161: The IpnsPublishRequest currently derives Debug and may
leak sensitive fields `record` and `encrypted_ipns_private_key`; replace the
derived Debug on the struct with a manual impl or use the same redaction pattern
as the auth DTOs: remove `#[derive(Debug, Serialize)]` (or at least remove
Debug), implement Debug for `IpnsPublishRequest` to redact `record` and
`encrypted_ipns_private_key` (show placeholders like "<redacted>" or only
lengths), keep Serialize and serde attrs intact, and ensure `key_epoch`,
`expected_sequence_number`, `ipns_name`, and `metadata_cid` are represented
normally in the Debug output; update any imports or traits accordingly.

In `@crates/crypto/src/ecies.rs`:
- Around line 14-15: Update the ECIES constant and its doc comment: change the
doc comment describing the output format to "ephemeral_pubkey(65) || nonce(12)
|| tag(16) || ciphertext" (nonce is 12 bytes for AES-GCM), and change the
ECIES_MIN_CIPHERTEXT_SIZE constant calculation (symbol
ECIES_MIN_CIPHERTEXT_SIZE) to include the 12-byte nonce plus 16-byte auth tag by
using SECP256K1_PUBLIC_KEY_SIZE + 12 + 16 so the minimum ciphertext size for
empty plaintext is 93 bytes.

In `@crates/fuse/src/lib.rs`:
- Around line 617-642: The drain_refresh_completions() logic is performing
network I/O synchronously (using block_with_timeout and calling
cipherbox_api_client::ipns::resolve_ipns /
cipherbox_api_client::ipfs::fetch_content) while draining the refresh channel;
instead, enqueue each unresolved pointer returned by
self.inodes.get_unresolved_file_pointers() onto the existing background
worker/channel (the same path used by release() or the background resolver)
including ino, fp_ipns and the folder_key, then return immediately from
drain_refresh_completions(); have the background worker perform resolve_ipns and
fetch_content (using rt/api as before), decrypt with
cipherbox_core::decrypt_file_metadata_from_ipfs_public, and call
self.inodes.resolve_file_pointer(...) when each resolution completes so the FUSE
thread never blocks on network timeouts.
- Around line 235-243: The folder/IPNS key material is being copied into plain
Vec<u8> and passed into spawn_metadata_publish, leaving unsanitized heap copies;
change the types and flows to use zeroize::Zeroizing (e.g., Zeroizing<Vec<u8>>)
instead of plain Vec<u8> so keys are zeroized when dropped, update
build_folder_metadata to produce/return Zeroizing<Vec<u8>> for folder_key and
ipns_private_key (avoid intermediate plain Vec copies), change
spawn_metadata_publish signature to accept Zeroizing<Vec<u8>> for folder_key and
ipns_private_key and propagate those types through the background task, and fix
the other occurrences you noted (around the 491-503 area) to use Zeroizing as
well; also add the appropriate use/import for zeroize::Zeroizing.
- Around line 131-153: The resolve_sequence function currently returns Err when
cipherbox_api_client::ipns::resolve_ipns(...) returns an error and there is no
cached sequence, which prevents first-time publishes; change resolve_sequence so
that if resolve_ipns fails with a "not found"/missing-record error (or any error
indicating no IPNS record) and get_cached(ipns_name) is None, it treats the
sequence as 0: update_cache(ipns_name, 0) and return Ok(0) instead of Err; keep
the existing behavior of using cached value when present and logging the warning
as before.

In `@crates/fuse/src/operations.rs`:
- Around line 162-178: The per-file IPNS publish flow currently treats
PublishResult::Conflict as success by always calling
coordinator.record_publish(file_ipns_name, new_seq) and logging success;
instead, only record and log on cipherbox_api_client::PublishResult::Success.
Update the match over cipherbox_api_client::ipns::publish_ipns(...) so that
coordinator.record_publish(...) and the "Per-file IPNS publish succeeded" log
are executed inside the Success arm, and in the Conflict { .. } arm do not
advance the local sequence cache—return or propagate an error (or handle it
explicitly) so callers know the publish failed; reference the
IpnsPublishRequest, publish_ipns, PublishResult::Success,
PublishResult::Conflict, coordinator.record_publish, file_ipns_name, and new_seq
to find the code to change.

In `@crates/fuse/src/platform/linux.rs`:
- Around line 12-17: The temp directory cleanup currently happens before unmount
and can remove in-use files; move the remove_dir_all(&temp_dir) block so it runs
only after a successful unmount operation. Locate the variable temp_dir and the
existing unmount call (the function or code that performs the filesystem
unmount) and transfer the logic that checks temp_dir.exists() and calls
std::fs::remove_dir_all(&temp_dir) into the cleanup path executed after unmount
succeeds, preserving the log::warn! on Err(e) to report cleanup failures. Ensure
no early return prevents running this post-unmount cleanup and that errors
during unmount are handled before attempting removal.
- Line 19: The code uses mount_path.to_str().unwrap() which can panic on
non-UTF-8 paths; replace this unsafe unwrap in the block that defines mount_str
by handling the Option properly — either use mount_path.to_string_lossy() to get
a safe String/Cow<str> or propagate/return an error when to_str() is None so
non-UTF-8 mounts are handled gracefully; update all uses of mount_str
accordingly (look for the let mount_str = mount_path.to_str().unwrap() binding
and callers that expect &str).

In `@crates/fuse/src/platform/macos.rs`:
- Around line 20-22: Replace uses of mount_path.to_str().unwrap() to avoid
panics on non-UTF-8 paths: pass the Path/PathBuf directly to Command.arg (e.g.
.arg(&mount_path) or .arg(mount_path.as_os_str())) in the macOS unmount calls
found in this file (the Command::new("umount") invocation and the other similar
invocation around lines 30-33). This removes the to_str().unwrap() panic risk
while preserving correct OS-string argument handling.

---

Outside diff comments:
In `@crates/api-client/src/client.rs`:
- Around line 58-69: The helpers authenticated_get, authenticated_post, and
authenticated_multipart_post currently hold the RwLockReadGuard
(self.access_token.read().await) across builder.send().await which blocks
set_access_token/clear_access_token; change each to clone the token out of the
guard (e.g., let token_opt = (*token).clone() or token.clone()), then drop the
guard immediately (allow it to go out of scope) before building/sending the
request so the await happens without holding the read lock and concurrent
writers can proceed.

---

Nitpick comments:
In @.planning/security/REVIEW-2026-03-24-phase23.md:
- Line 10: The report contains a contradiction between the executive summary
claiming key material is wrapped in Zeroizing<Vec<u8>> throughout and HIGH-2
claiming a non-zeroizing private key return; inspect the actual implementation
to confirm which is true, then make the text consistent: either (A) if the code
returns a non-zeroizing private key, update the executive summary and any
mentions of "throughout" to qualify where Zeroizing is used and document the
specific function/path that leaks (refer to HIGH-2 and occurrences of
"Zeroizing<Vec<u8>>"), or (B) if the code already zeroizes everywhere, revise
HIGH-2 to remove the false positive and note the correct locations using
Zeroizing; update all other instances in the detailed findings (the section
currently around the HIGH-2 discussion and the executive summary) so both places
say the same thing.

In `@crates/core/src/decrypt.rs`:
- Around line 10-50: Change the function signature
decrypt_metadata_from_ipfs_public (and the other helper in the 54-89 range) to
return Result<FolderMetadata, CoreError> instead of Result<..., String>, and map
every failure path (serde_json::from_slice, hex::decode, IV length check, base64
decode, folder_key try_into, and crate::folder::decrypt_folder_metadata) into
specific CoreError variants (e.g., ParseError, InvalidHex/InvalidIv,
Base64Error, InvalidKeyLength, CryptoError) instead of formatting free-form
Strings; update error mapping calls to construct the appropriate CoreError
(preserving underlying error details where possible) so callers receive
structured CoreError variants rather than plain strings.

In `@crates/crypto/src/ipns_name.rs`:
- Around line 13-25: The function encode_libp2p_public_key currently casts
ed25519_public_key.len() to u8 which can truncate inputs >255; fix by enforcing
Ed25519 key length: either change the signature to accept &[u8; 32] or validate
at the start of encode_libp2p_public_key that ed25519_public_key.len() == 32 and
return a Result<Vec<u8>, Error> (or panic) on mismatch; perform the length check
before pushing the length byte and only cast to u8 after the check to avoid
silent truncation.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 286a5979-8784-453e-8f15-dafa308750ab

📥 Commits

Reviewing files that changed from the base of the PR and between ffa8d25 and 9a85aad.

⛔ Files ignored due to path filters (2)

• Cargo.lock is excluded by !**/*.lock
• packages/api-client/CHANGELOG.md is excluded by !packages/api-client/**

📒 Files selected for processing (128)

• .github/workflows/ci.yml
• .github/workflows/desktop-e2e.yml
• .gitignore
• .planning/REQUIREMENTS.md
• .planning/ROADMAP.md
• .planning/STATE.md
• .planning/phases/23-rust-sdk-extraction/23-01-PLAN.md
• .planning/phases/23-rust-sdk-extraction/23-01-SUMMARY.md
• .planning/phases/23-rust-sdk-extraction/23-02-PLAN.md
• .planning/phases/23-rust-sdk-extraction/23-02-SUMMARY.md
• .planning/phases/23-rust-sdk-extraction/23-03-PLAN.md
• .planning/phases/23-rust-sdk-extraction/23-03-SUMMARY.md
• .planning/phases/23-rust-sdk-extraction/23-04-PLAN.md
• .planning/phases/23-rust-sdk-extraction/23-04-SUMMARY.md
• .planning/phases/23-rust-sdk-extraction/23-05-PLAN.md
• .planning/phases/23-rust-sdk-extraction/23-05-SUMMARY.md
• .planning/phases/23-rust-sdk-extraction/23-06-PLAN.md
• .planning/phases/23-rust-sdk-extraction/23-06-SUMMARY.md
• .planning/phases/23-rust-sdk-extraction/23-07-PLAN.md
• .planning/phases/23-rust-sdk-extraction/23-07-SUMMARY.md
• .planning/phases/23-rust-sdk-extraction/23-08-PLAN.md
• .planning/phases/23-rust-sdk-extraction/23-08-SUMMARY.md
• .planning/phases/23-rust-sdk-extraction/23-CONTEXT.md
• .planning/phases/23-rust-sdk-extraction/23-RESEARCH.md
• .planning/phases/23-rust-sdk-extraction/23-VALIDATION.md
• .planning/phases/23-rust-sdk-extraction/23-VERIFICATION.md
• .planning/security/REVIEW-2026-03-24-phase23.md
• .release-please-manifest.json
• CHANGELOG.md
• Cargo.toml
• apps/desktop/src-tauri/Cargo.toml
• apps/desktop/src-tauri/src/api/ipns.rs
• apps/desktop/src-tauri/src/api/mod.rs
• apps/desktop/src-tauri/src/commands/auth.rs
• apps/desktop/src-tauri/src/commands/sync.rs
• apps/desktop/src-tauri/src/commands/vault.rs
• apps/desktop/src-tauri/src/crypto/aes.rs
• apps/desktop/src-tauri/src/crypto/bin.rs
• apps/desktop/src-tauri/src/crypto/ecies.rs
• apps/desktop/src-tauri/src/crypto/ed25519.rs
• apps/desktop/src-tauri/src/crypto/mod.rs
• apps/desktop/src-tauri/src/crypto/tests.rs
• apps/desktop/src-tauri/src/fuse/decrypt.rs
• apps/desktop/src-tauri/src/fuse/mod.rs
• apps/desktop/src-tauri/src/fuse/operations.rs
• apps/desktop/src-tauri/src/fuse/windows/mod.rs
• apps/desktop/src-tauri/src/keychain.rs
• apps/desktop/src-tauri/src/main.rs
• apps/desktop/src-tauri/src/registry/mod.rs
• apps/desktop/src-tauri/src/registry/types.rs
• apps/desktop/src-tauri/src/state.rs
• apps/desktop/src-tauri/src/sync/mod.rs
• apps/desktop/src-tauri/src/sync/tests.rs
• apps/desktop/src-tauri/src/tray/mod.rs
• apps/desktop/src-tauri/tauri.conf.json
• apps/desktop/src-tauri/vendor/fuser/build.rs
• crates/api-client/Cargo.toml
• crates/api-client/src/auth.rs
• crates/api-client/src/client.rs
• crates/api-client/src/error.rs
• crates/api-client/src/ipfs.rs
• crates/api-client/src/ipns.rs
• crates/api-client/src/lib.rs
• crates/api-client/src/types.rs
• crates/core/Cargo.toml
• crates/core/src/bin.rs
• crates/core/src/decrypt.rs
• crates/core/src/error.rs
• crates/core/src/file.rs
• crates/core/src/folder.rs
• crates/core/src/ipns.rs
• crates/core/src/lib.rs
• crates/core/src/registry.rs
• crates/core/src/vault_blob.rs
• crates/crypto/Cargo.toml
• crates/crypto/src/aes.rs
• crates/crypto/src/aes_ctr.rs
• crates/crypto/src/ecies.rs
• crates/crypto/src/ed25519.rs
• crates/crypto/src/error.rs
• crates/crypto/src/hkdf.rs
• crates/crypto/src/ipns_name.rs
• crates/crypto/src/lib.rs
• crates/crypto/src/utils.rs
• crates/crypto/tests/cross_language.rs
• crates/fuse/Cargo.toml
• crates/fuse/src/cache.rs
• crates/fuse/src/constants.rs
• crates/fuse/src/dir_ops.rs
• crates/fuse/src/error.rs
• crates/fuse/src/file_handle.rs
• crates/fuse/src/helpers.rs
• crates/fuse/src/inode.rs
• crates/fuse/src/lib.rs
• crates/fuse/src/operations.rs
• crates/fuse/src/platform/linux.rs
• crates/fuse/src/platform/macos.rs
• crates/fuse/src/platform/mod.rs
• crates/fuse/src/platform/windows/dir_ops.rs
• crates/fuse/src/platform/windows/mod.rs
• crates/fuse/src/platform/windows/operations.rs
• crates/fuse/src/platform/windows/read_ops.rs
• crates/fuse/src/platform/windows/write_ops.rs
• crates/fuse/src/read_ops.rs
• crates/fuse/src/write_ops.rs
• crates/sdk/Cargo.toml
• crates/sdk/src/client.rs
• crates/sdk/src/error.rs
• crates/sdk/src/lib.rs
• crates/sdk/src/queue.rs
• crates/sdk/src/registry.rs
• crates/sdk/src/state.rs
• crates/sdk/src/sync.rs
• packages/core/CHANGELOG.md
• packages/crypto/CHANGELOG.md
• packages/sdk-core/CHANGELOG.md
• packages/sdk/CHANGELOG.md
• release-please-config.json
• scripts/check-vector-parity.sh
• tests/vectors/core/bin-metadata.json
• tests/vectors/core/folder-metadata.json
• tests/vectors/core/ipns-record.json
• tests/vectors/core/vault-blob.json
• tests/vectors/crypto/aes-gcm.json
• tests/vectors/crypto/ecies.json
• tests/vectors/crypto/ed25519.json
• tests/vectors/crypto/hkdf.json
• tests/vectors/crypto/ipns-name.json

💤 Files with no reviewable changes (12)

• apps/desktop/src-tauri/src/crypto/ed25519.rs
• apps/desktop/src-tauri/src/api/mod.rs
• apps/desktop/src-tauri/src/crypto/bin.rs
• apps/desktop/src-tauri/src/registry/types.rs
• apps/desktop/src-tauri/src/api/ipns.rs
• apps/desktop/src-tauri/src/crypto/ecies.rs
• apps/desktop/src-tauri/src/crypto/mod.rs
• apps/desktop/src-tauri/src/crypto/aes.rs
• apps/desktop/src-tauri/src/fuse/decrypt.rs
• apps/desktop/src-tauri/src/sync/tests.rs
• apps/desktop/src-tauri/src/crypto/tests.rs
• apps/desktop/src-tauri/src/fuse/operations.rs

[Copilot]

Pull request overview

Copilot reviewed 98 out of 130 changed files in this pull request and generated 6 comments.

[coderabbitai]

🧹 Nitpick comments (2)

crates/api-client/src/types.rs (1)

4-4: Broaden the module doc wording to match current scope.

The comment currently says only auth DTOs use manual redaction, but this file now includes redacted Debug for IPNS publish payloads too.

✏️ Suggested wording tweak

-//! Auth DTOs use manual Debug impls to redact sensitive fields.
+//! DTOs that may carry sensitive fields use manual Debug impls to redact them.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/api-client/src/types.rs` at line 4, Update the module doc comment in
types.rs to reflect that manual Debug implementations are used to redact
sensitive fields beyond just auth DTOs—specifically mention that IPNS publish
payloads (and any other sensitive DTOs in this file) also use redacted Debug
impls; locate the module-level doc comment near the top of types.rs and change
the wording to cover both auth DTOs and IPNS publish payloads (and similar
types) so it accurately describes the scope of the redacted Debug
implementations.

apps/desktop/src-tauri/src/fuse/mod.rs (1)

127-142: Consider extracting FilePointer resolution into a helper.

The resolution logic here (lines 127-142) is nearly identical to lines 161-174. A small helper function would reduce duplication and make future maintenance easier:

async fn resolve_file_pointers(
    inodes: &mut InodeTable,
    api: &ApiClient,
    folder_key: &[u8; 32],
) { /* ... */ }

This is a minor code-quality improvement that could be addressed in a follow-up.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/desktop/src-tauri/src/fuse/mod.rs` around lines 127 - 142, Extract the
duplicated FilePointer resolution block into a single async helper (e.g., async
fn resolve_file_pointers(inodes: &mut InodeTable, api: &ApiClient,
root_folder_key: &[u8;32]) ) and replace both occurrences with calls to it; the
helper should call inodes.get_unresolved_file_pointers(), loop over (fp_ino,
fp_ipns), use cipherbox_api_client::ipns::resolve_ipns and
cipherbox_api_client::ipfs::fetch_content to obtain enc_bytes, decrypt with
cipherbox_core::decrypt_file_metadata_from_ipfs_public using the provided folder
key, then call inodes.resolve_file_pointer(...) with the decrypted metadata,
handling errors by skipping unresolved entries as the current code does.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@apps/desktop/src-tauri/src/fuse/mod.rs`:
- Around line 127-142: Extract the duplicated FilePointer resolution block into
a single async helper (e.g., async fn resolve_file_pointers(inodes: &mut
InodeTable, api: &ApiClient, root_folder_key: &[u8;32]) ) and replace both
occurrences with calls to it; the helper should call
inodes.get_unresolved_file_pointers(), loop over (fp_ino, fp_ipns), use
cipherbox_api_client::ipns::resolve_ipns and
cipherbox_api_client::ipfs::fetch_content to obtain enc_bytes, decrypt with
cipherbox_core::decrypt_file_metadata_from_ipfs_public using the provided folder
key, then call inodes.resolve_file_pointer(...) with the decrypted metadata,
handling errors by skipping unresolved entries as the current code does.

In `@crates/api-client/src/types.rs`:
- Line 4: Update the module doc comment in types.rs to reflect that manual Debug
implementations are used to redact sensitive fields beyond just auth
DTOs—specifically mention that IPNS publish payloads (and any other sensitive
DTOs in this file) also use redacted Debug impls; locate the module-level doc
comment near the top of types.rs and change the wording to cover both auth DTOs
and IPNS publish payloads (and similar types) so it accurately describes the
scope of the redacted Debug implementations.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: a3154fbb-ff87-476a-a812-3cde881811e8

📥 Commits

Reviewing files that changed from the base of the PR and between 50187b2 and 6ae9e78.

📒 Files selected for processing (6)

• apps/desktop/src-tauri/src/fuse/mod.rs
• crates/api-client/src/auth.rs
• crates/api-client/src/client.rs
• crates/api-client/src/types.rs
• crates/fuse/src/platform/linux.rs
• crates/fuse/src/platform/macos.rs

🚧 Files skipped from review as they are similar to previous changes (3)

• crates/fuse/src/platform/linux.rs
• crates/fuse/src/platform/macos.rs
• crates/api-client/src/auth.rs

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (2)

crates/core/src/registry.rs (1)

144-144: Remove dead branch in assertion.

The field is named status in the struct, and with camelCase renaming it remains "status" in JSON (no underscore to convert). The "authStatus" branch will never match and is dead code.

🧹 Proposed fix

-        assert!(json.contains("\"authStatus\"") || json.contains("\"status\""));
+        assert!(json.contains("\"status\""));
+        assert!(!json.contains("\"authStatus\""));

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/core/src/registry.rs` at line 144, The assertion at the end of the
test currently checks for either "\"authStatus\"" or "\"status\"" but
"authStatus" is impossible due to the struct field being named `status` (and
serde camelCase keeps it as "status"), so remove the dead branch and change the
assertion to only verify that the serialized JSON contains "\"status\"" (update
the assert! that currently references both variants in the file containing the
test/assertion).

crates/core/src/ipns.rs (1)

18-20: Clarify the legacy path in the re-export comment

The comment on Line 19 references crate::crypto::ipns::derive_ipns_name, which may mislead if the active public path is now crate::ipns::derive_ipns_name. Please update the comment to the exact current path(s).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/core/src/ipns.rs` around lines 18 - 20, Update the comment above the
re-export of derive_ipns_name to reference the correct current public path(s):
mention that derive_ipns_name is re-exported for backward compatibility so
code/tests referencing the old path (crate::crypto::ipns::derive_ipns_name) and
the current path (crate::ipns::derive_ipns_name) both continue to work; adjust
the comment to explicitly list these exact paths and keep the note about
backward compatibility next to the pub use of
cipherbox_crypto::ipns_name::derive_ipns_name.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/core/src/ipns.rs`:
- Around line 398-410: The test different_sequences_produce_different_output is
flaky because create_ipns_record uses SystemTime::now(), so make the test
deterministic by controlling the timestamp: modify the test to call a
deterministic variant of create_ipns_record (or add/use an overload that accepts
an explicit timestamp) and pass the same fixed timestamp for both sequence 0 and
100, then assert record0.data != record100.data and signatures differ; reference
create_ipns_record in the fix and add or use a parameter like timestamp or
create_ipns_record_with_time to ensure only the sequence changes between the two
records.

---

Nitpick comments:
In `@crates/core/src/ipns.rs`:
- Around line 18-20: Update the comment above the re-export of derive_ipns_name
to reference the correct current public path(s): mention that derive_ipns_name
is re-exported for backward compatibility so code/tests referencing the old path
(crate::crypto::ipns::derive_ipns_name) and the current path
(crate::ipns::derive_ipns_name) both continue to work; adjust the comment to
explicitly list these exact paths and keep the note about backward compatibility
next to the pub use of cipherbox_crypto::ipns_name::derive_ipns_name.

In `@crates/core/src/registry.rs`:
- Line 144: The assertion at the end of the test currently checks for either
"\"authStatus\"" or "\"status\"" but "authStatus" is impossible due to the
struct field being named `status` (and serde camelCase keeps it as "status"), so
remove the dead branch and change the assertion to only verify that the
serialized JSON contains "\"status\"" (update the assert! that currently
references both variants in the file containing the test/assertion).

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 04e60c3f-8b14-46b7-ac86-9d847abe02a1

📥 Commits

Reviewing files that changed from the base of the PR and between 6ae9e78 and 617db07.

📒 Files selected for processing (6)

• .github/workflows/ci.yml
• apps/desktop/src-tauri/Cargo.toml
• crates/core/src/bin.rs
• crates/core/src/ipns.rs
• crates/core/src/registry.rs
• crates/crypto/src/ipns_name.rs

🚧 Files skipped from review as they are similar to previous changes (3)

• .github/workflows/ci.yml
• crates/crypto/src/ipns_name.rs
• crates/core/src/bin.rs

[Copilot]

Pull request overview

Copilot reviewed 85 out of 134 changed files in this pull request and generated 3 comments.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/desktop/src-tauri/src/fuse/mod.rs`:
- Around line 254-292: Add comprehensive tests for merge_folder_children in the
fuse crate by expanding the existing test module (the module that already
defines make_file, metadata, child_name and tests merge_both_empty,
merge_disjoint_children_union, merge_identical_uses_local). Specifically, add
tests that: verify local preference on conflicts with different ordering and
multiple conflicting entries (use merge_identical_uses_local pattern but with
several files), ensure union semantics preserve order and completeness for
disjoint sets (similar to merge_disjoint_children_union but with interleaved
inputs), stress-test with a large number of children to detect performance or
truncation issues, and cover orphaned-local and orphaned-remote cases where one
side has extra items; use the same FolderChild/FilePointer construction helpers
and assert on merged.children length and child_name() contents to locate
regressions.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 50968ea1-6908-480f-af60-069e39035bcf

📥 Commits

Reviewing files that changed from the base of the PR and between 617db07 and cd8c98b.

📒 Files selected for processing (15)

• .github/workflows/ci.yml
• .learnings/2026-03-25-windows-build-debug-on-platform.md
• .planning/phases/23-rust-sdk-extraction/WINDOWS-BUILD-DEBUG.md
• Cargo.toml
• apps/desktop/src-tauri/Cargo.toml
• apps/desktop/src-tauri/src/fuse/mod.rs
• apps/desktop/src-tauri/src/fuse/windows/mod.rs
• apps/desktop/src-tauri/vendor/fuser/build.rs
• apps/desktop/src-tauri/vendor/fuser/src/lib.rs
• apps/desktop/src-tauri/vendor/fuser/src/lib_impl.rs
• crates/fuse/Cargo.toml
• crates/fuse/src/platform/windows/dir_ops.rs
• crates/fuse/src/platform/windows/operations.rs
• crates/fuse/src/platform/windows/read_ops.rs
• crates/fuse/src/platform/windows/write_ops.rs

✅ Files skipped from review due to trivial changes (2)

• .learnings/2026-03-25-windows-build-debug-on-platform.md
• crates/fuse/Cargo.toml

🚧 Files skipped from review as they are similar to previous changes (2)

• Cargo.toml
• apps/desktop/src-tauri/src/fuse/windows/mod.rs