36 Commits

Include renames

Author	SHA1	Message	Date
beardthelion	86c544a577	fix(core): reject small-order Ed25519 keys at DID resolution and before X25519 (#314) ... * fix(core): reject small-order Ed25519 keys at DID resolution and before X25519 A did:key can encode a small-order (weak) Ed25519 point. VerifyingKey::from_bytes only decompresses, so such a key resolved cleanly, and x25519_public converted it to the all-zero Montgomery u. X25519 against u = 0 is the all-zero shared secret for every scalar, so the per-recipient wrap in seal_blob could be rebuilt with no secret at all. Since one content key is wrapped per recipient, a single weak recipient exposed the blob for every recipient. Reject in Did::to_verifying_key, which is the choke point every consumer that resolves a DID shares, so a weak key becomes unresolvable and the existing fail-closed recipient handling catches it without a new code path. Guard x25519_public as well so the primitive is safe for a caller that obtained the key some other way. The attacker test performs the real attack rather than asserting an absence: with either guard removed it recovers the plaintext and fails printing it. * fix(attest): mirror the small-order key rejection in its own did:key parser gitlawb-attest parses did:key itself in verifying_key_from_did_key and never routes through gitlawb-core's Did. It cannot: gitlawb-core is a dev-dependency here, so the choke-point rejection is structurally unreachable from this crate and has to be mirrored rather than inherited. Signature verification is already strict, so this is defense in depth against a future consumer of this parser that does not verify strictly, not the closing of an exploitable path. One consequence worth naming: verify_rejects_weak_key_signature now observes Error::Did rather than Error::Signature, because the weak signer is refused at resolution before verify_strict is reached. That test is retargeted accordingly. It no longer exercises verify_strict, which remains the second layer for malleability that does not involve a weak public key (a small-order R under an honest key); this fixture cannot construct that case. * test(node): pin that a weak recipient DID falls into the existing fail-closed arm Because a small-order did:key no longer resolves, it lands in the unresolved set and plan_seal returns the #47 SkipUnresolvable arm that already refuses to seal to a partial recipient set. Nothing is sealed for the blob and the existing bounded operator warning fires. No new branch, no new SealPlan variant, no new log site. The must-not-over-reject control asserts an all-legitimate set still seals. * fix(gl): stop telling a did:key that did:key is unsupported did_resolve reported every resolution failure as "only did:key is supported without a resolver". That is right for a method with no local resolver and misleading for a did:key that parsed fine and failed for its own reason, which now includes a small-order key. Split the message on whether the DID is a did:key and surface the underlying error when it is. Extracted as a pure helper so both branches are unit-testable without an MCP client harness. * fix(review): restore verify_strict coverage the parser guard displaced Refusing a small-order key at DID resolution means a weak signer can no longer reach attestation.rs's verify_strict through verify_signature, which left that line with no test at all: downgrading it to the non-strict verify kept the whole attest suite green. Split the signature check into verify_sig_with_key so a test can drive it directly with a weak key. Check order in verify_signature is unchanged; only the seam is new. Also from review: - auth/mod.rs sent a did:key that failed on its own key material away with "only did:key is supported in alpha", the same misleading hint the gl MCP tool was just fixed for. Made it conditional on is_did_key so the two parallel surfaces say the same thing. - The guard comments claimed a small-order point converts to the all-zero Montgomery u. That holds for order 1 and 2 only; order 4 and 8 are annihilated by the scalar clamping instead. is_weak covers the whole torsion set, and mixed-order points are correctly still accepted. - did.rs doc comment now states the new rejection. - encrypt.rs: extracted the repeated weak-key fixture into a test helper and switched to the file's existing Err(anyhow!(..)) rejection idiom. - gl tests derive the did:key discriminator from a real parsed Did instead of hardcoding the bool, so inverting it at the call site now fails. * fix(attest): cap the did:key method-id before decoding, mirroring core The parser here mirrors gitlawb-core's small-order rejection because it cannot call into it (gitlawb-core is a dev-dependency of this crate). It was mirroring only one of the two guards that sit three lines apart in the function being copied: core also caps the method-id at 64 bytes BEFORE the multibase decode, because base58 decoding is quadratic in its input. signer comes off an attacker-supplied attestation and verify_signature reaches this parser after computing the JCS bytes, so an oversized method-id bought a large decode for a short request. An ed25519 did:key method-id is a fixed 48 characters, so the bound is slack rather than a behavior change. The test asserts the length error specifically rather than any error: a multibase error there would mean the cap ran after the decode and bought nothing. * fix(node): surface stored envelopes sealed to a now-unresolvable recipient plan_seal short-circuited on a matching stored tag before resolving the recipient set, so a blob sealed to a small-order did:key before the choke-point guard landed kept its old CID and was silently treated as unchanged. Resolve the set on the match and surface a now-unresolvable reader as SkipUnresolvableStored so the operator sees the exposure. * fix(attest): anchor VerifiedAttestation.signer to the key that verified Registry::verify discarded the VerifyingKey returned by verify_signature and copied the artifact's signer string into the result. The parser is canonical so the strings agree for honest artifacts and a mismatched field already fails verification, but the consumer-facing value now provably comes from the key that verified rather than a raw artifact field. * fix(node): bound the echoed DID in the unresolvable-did error and pin the hint branches The keyid is unauthenticated request input and was reflected into the response message at full length. Bound the echo to 96 chars and extract the two-branch hint selection into a testable helper with both branches pinned. * test(gl): build the weak did:key fixture from its identity-point bytes The hardcoded WEAK_DID_KEY constant trips secret scanners, which cannot tell a public DID from an API key. Deriving the DID from the compressed identity point states why the fixture is weak and matches the house pattern used in the core, attest, and node crates. ed25519-dalek is added as a dev-dependency (it was already a workspace dependency). * fix(core): skip a low-order ephemeral on the envelope open side open_blob built the X25519 box from the header-supplied eph with no small-order check, so a crafted entry forced the all-zero shared secret and unwrapped for any reader. Skip entries whose eph decompresses to a small-order point; honest entries in the same envelope still open. * fix(core): test the exchange result, not the ephemeral's encoding The open-side guard decompressed the ephemeral to Edwards and asked is_small_order, treating a failure to decompress as safe. That reports safe for any low-order input that is not a valid Edwards encoding. Measured across the seven standard low-order encodings: six caught, u = p-1 missed. Its exchange with any reader is still the all-zero shared secret, so an entry built on it unwraps for everyone and the attacker controls the plaintext. Check the result instead: an ephemeral is rejected when the exchange with this reader's own scalar is all-zero. That is the property the guard exists to enforce, and it holds for every low-order input regardless of encoding. The new must-not test needed two attempts. The first passed with the guard, without it, and with the original pre-fix guard alike, because a blanket `use chacha20poly1305::aead::Aead` in the test resolved the wrap's encrypt through a different aead version than open_blob decrypts with, building a ciphertext that could never open for any reason. Every call in it now names its trait. * docs(core): anchor open-side guard comments to exchange-result invariant The seal-side comment still named is_low_order_montgomery and the low-order vector test doc claimed a decode-path filter that does not exist. Both now describe yields_all_zero_shared_secret. * test(core): use generated keys in poisoned-envelope fixtures Replace hard-coded test scalars that CodeQL flags as cryptographic material. The all-zero shared-secret attack does not depend on which scalar builds the attacker box. * test(core): use Default::default() for zero-point fixtures flagged by CodeQL CodeQL flags [0u8; 32] literals that flow to a cryptographic key argument, even in test fixtures where the value is the all-zero Montgomery point (a public low-order test vector, not a secret). Default::default() produces the same bytes without a literal, clearing the alert without changing behavior. * test(core): generate body nonces with OsRng in poisoned-envelope fixtures CodeQL flags hard-coded byte arrays used as nonces, even in test fixtures where the value is a fixed test vector. Generate with OsRng instead, matching the production seal path. * chore: sync Cargo.lock after merging main (ed25519-dalek edge for gl)	2026-11-05 01:49:28 +00:00
beardthelionandKevin Codex	c301a68161	fix(node): persist the libp2p identity instead of deriving it from the node DID (#324) ... * feat(node): add a persistent libp2p identity key file Add p2p_key_path (--p2p-key-path / GITLAWB_P2P_KEY, default ~/.gitlawb/p2p.key) with a resolver mirroring resolved_key_path, and load_or_create_p2p_keypair, which generates an Ed25519 keypair on first start, persists it 0600, and loads it thereafter. Mirrors the existing load_or_create_keypair idiom for the node identity PEM. A corrupt or unreadable key file is a hard error naming the path rather than a silent regeneration, so a disk problem cannot quietly rotate the node's network identity. Not yet wired into p2p::start; that follows. * fix(node): load the libp2p identity from the persistent key file p2p::start now takes the Ed25519 keypair loaded by load_or_create_p2p_keypair instead of computing one from the node DID, so a node's network identity is generated once from the OS RNG and kept on disk rather than recomputed from a public value on every start. The node DID parameter is gone from start; the call site loads the key first and continues without p2p if the key file cannot be read, matching how a swarm-start failure is already handled. The gossipsub message_id_fn is untouched and keeps its own hasher. * fix(node): create the p2p key with 0600 at creation and reject a loose one Open the key file with create_new and the mode set at creation, then fsync, instead of writing it and narrowing the mode afterwards. The secret is never on disk under a wider mode, an interrupted start cannot leave it readable, and the exclusive open also refuses a pre-existing entry at the path and makes a concurrent start take the key that landed rather than clobber it. Refuse to load a key file whose mode grants group or other access, and name the observed mode so the operator can fix it. Report an empty key file as empty rather than surfacing a protobuf decode error that blames a missing rsa feature. Pin GITLAWB_P2P_KEY onto the mounted volume in the Docker and fly configs and document it, so the key does not depend on home-directory resolution to land on persistent storage. * fix(node): publish the p2p key atomically and pin its directory Write the key to a scratch file in the same directory and hard-link it onto the final path. The bytes are durable before any name points at them, so a crash cannot leave a partial key that fails to load on the next start and takes the node off the network until someone reads the logs. A concurrent reader can no longer observe a half-written file either, since the final name appears complete or not at all. hard_link rather than rename: rename replaces its destination silently, so refusing to clobber an existing key would depend on a check followed by a separate rename, and a concurrent start can land in that gap. hard_link is atomic and refuses an occupied path, including a symlink, which it does not follow. Create the key directory 0700 and tighten it when an existing one grants group or other access. A 0600 key under a writable directory can still be replaced or unlinked. Tightening rather than refusing to start, because existing installs already have 0755 there and refusing would take p2p down on all of them through a path that only warns. Formatting on the branch is swept up here; it was already failing cargo fmt --check before this change. * style(node): comma instead of a dash in the key-load warning House style avoids em dashes in text we write. The swarm-failure warning beside it predates this branch and is left alone. * fix(node): require the p2p key path to name a directory A bare filename in GITLAWB_P2P_KEY put the key in whatever directory the process started from, and the directory guard was skipped entirely on that path: Path::parent returns Some("") for a bare filename, which the caller filtered out before ever reaching ensure_key_dir. The key file was created 0600 inside a directory that kept whatever mode it already had. Config::validate now rejects a p2p key path that names no directory, so the node says so at boot instead of starting with a key it cannot protect. That placement is the point: an error raised in the p2p start path is logged and stepped over, leaving the node running without p2p and reporting healthy. The check is lexical on the tilde-resolved path. canonicalize would fail on a parent that does not exist yet, which is the shipped ~/.gitlawb default and every container's first boot, and comparing against the working directory would reject /data/p2p.key under the image's WORKDIR, an absolute directory the operator did name. Three sites answered the parent question differently, which is how the gap arose: one filtered the empty case out, one already normalized it, and one opened "" and silently skipped its fsync. They now share key_parent, and Config::validate calls it rather than adding a fourth answer. load_or_create_p2p_keypair also refuses a path naming no directory. That is a backstop behind the config gate, not the gate, so a later caller that skips validation cannot quietly restore the old behaviour. * test(node): run the key-permission probe in its own process The probe zeroes the umask so the assertion means something: under a restrictive ambient umask the bits are masked to 0600 regardless of whether the code pins the mode, and the check passes either way. Zeroing it in the shared test process is the problem. umask is process-global and cargo runs these tests on threads, so any test creating a file in that window inherits 000. Measured before this change: an unrelated concurrent test's file was created 0666. The probe now runs in a child process, where the zeroed umask cannot reach a sibling and dies with the child. The parent is an ordinary test that runs concurrently with everything else. Double-gated with #[ignore] plus an env check so a bare --ignored sweep does not zero the umask in the shared process after all. The parent asserts the child ran exactly one test and that it passed, not just that it exited 0. A libtest filter matching nothing runs zero tests and still exits 0, so without that assertion a renamed fixture would read as a green permission check while asserting nothing. Verified by pointing the filter at a name that does not exist and watching the parent fail. * docs(node): scope the p2p key permission claim and note the rotation The old wording said the key file is "created with owner-only permissions" without qualification, which is only true on Unix: every permission path in p2p/mod.rs is cfg(unix), so on other platforms the file inherits whatever the directory gives it and nothing is enforced. Say what is actually enforced and where. Also document what operators now have to do rather than leaving them to discover it: - GITLAWB_P2P_KEY must name a directory, since a bare filename is refused at startup. - The PeerId rotates once on the first start after upgrading, so a GITLAWB_P2P_BOOTSTRAP multiaddr pinning a peer's old id with a /p2p/<PeerId> suffix needs updating or dropping. Suffix-less addresses and the HTTP seed list are unaffected. - If the node reports tightening a loose key directory, the key that was in it should be treated as possibly exposed and deleted so a fresh one is generated. * fix(review): close a `..` escape from the p2p key-path check Two reviewers found the same hole independently: the check rejected a path naming no directory, but a relative parent that walks back out through `..` named one and still landed in the working directory. `a/../p2p.key` and `./keys/../p2p.key` resolve to the cwd itself and `../p2p.key` resolves above it, so all three put the key exactly where the check exists to keep it out of, and had ensure_key_dir chmod that directory to 0700 on the way. Verified by running the paths through the predicate and printing where each parent lands. The rule is now that a relative key path must name a directory and must not walk back out: at least one Normal component, no ParentDir. `..` inside an absolute path stays accepted, since it cannot depend on where the process started. The predicate moves into names_no_usable_directory next to key_parent, and the config gate and the load_or_create_p2p_keypair backstop both call it, so they cannot drift apart. Also fixes two smaller gaps found in the same pass: - The permission fixture could report "1 passed" while asserting nothing. Its env gate returns early, and an early return is a passing test, so a renamed variable would look green. It now prints a sentinel after its assertions and the parent requires it. Confirmed by pointing the child at a different variable and watching the parent fail. - A GITLAWB_P2P_KEY starting with `~/` is refused when no home directory resolves, instead of creating a literal `~` directory relative to wherever the node happened to start. The backstop had no test, so it has one now, along with a both-directions test for the predicate. That test cleans up after itself: with the guard removed it really does write a key next to the source, which broke a later run once. * fix(review): reject `..` in an absolute p2p key path too The previous commit closed this for relative paths and exempted absolute ones, reasoning that an absolute path cannot depend on the working directory. That is true and it is not the hazard. `key_parent` hands `ensure_key_dir` the lexical parent, so `/data/keys/../p2p.key` chmods `/data` rather than the `keys` directory the path appears to name, and `/data/../p2p.key` run as root would try to tighten `/` to 0700. The exemption also had a test asserting the first of those was fine, so the gap was written down as intended behaviour. `..` is now rejected wherever it appears. An absolute path's root counts as naming a directory, so `/p2p.key` still validates and `/data/keys/p2p.key` is unaffected. Found by a second-model review pass after the in-process reviewers had cleared the relative half. * fix(node): scrub the serialized p2p private key from memory Two buffers held the private key in its protobuf form and dropped without scrubbing: the encoding produced when a new identity is generated, and the file contents read back on every subsequent start. Both are now Zeroizing, matching what gitlawb-core already does for its own key material. Scope worth being honest about: this scrubs our copies of the serialized form, not the libp2p Keypair itself, which owns the secret for the process lifetime and exposes no way to zeroize it. The gain is that the encoded bytes do not outlive the write and the read. zeroize was already in the tree through gitlawb-core, so this promotes it to a direct dependency of gitlawb-node and adds no packages; the lockfile change is the one line recording that. * fix(node): validate the p2p key path before securing its parent Reject filesystem-root parents, directory-valued paths, and symlinks before any directory is created or chmodded. Create missing ancestors at the ambient mode and pin only the nominated key directory to 0700. Refuse symlink reads with O_NOFOLLOW, propagate directory durability sync failures, and document the loose-key rejection path for operators. * fix(node): satisfy clippy single-element-loop on p2p path test * fix(node): tighten the p2p key storage contract before mutation Anchor parent-directory checks on symlink_metadata, reject ~/ escapes and non-regular existing keys with a bounded read, treat directory AlreadyExists as a first-boot race, and skip key-path validation when P2P is disabled. * fix(node): refuse foreign-owned p2p key paths and cap reads on all platforms Check directory and key ownership before chmod or load, walk ancestors for foreign control, bound non-Unix reads to MAX_P2P_KEY_BYTES, and gate unix-only fixture tests without panicking on other targets. * fix(node): hold the p2p key directory open across its trust checks Resolve the key path once, then do every check and mutation through an O_DIRECTORY|O_NOFOLLOW handle on the parent (openat/fstat/fchmod/linkat), so nothing can be swapped between the ownership check, the tighten, and the key open. Key reads go through one bounded, non-blocking loader on every platform; new keys are generated in an unlinked scratch file and published atomically, with concurrent first boots converging on the winner's identity. The storage contract is indexed by two matrix tests: filesystem shapes in p2p (each refusal proven side-effect free against a recursive snapshot) and path spellings plus the p2p-disabled guarantee in config. * fix(node): walk the p2p key ancestor chain descriptor-anchored Replace the path-following metadata walk (foreign_ancestor_error) and the post-walk create_dir_all gap with a single descriptor-anchored walk that verifies and creates the chain together. Missing components are created at 0700 relative to the verified parent and re-verified; AlreadyExists is a race the winner must pass. Non-unix builds keep create_dir_all. * fix(node): refuse group-writable and non-directory p2p key ancestors The ancestor walk now refuses any component with group or world write bits unless sticky, and any intermediate component that is a symlink or another object type. Tests drive the walk through real boots: 0770/0775 ancestors refused before any key IO, 0755 and 1777-sticky ancestors accepted with stable reload, and an intermediate symlink refused with its target untouched. Both guards proven load-bearing by neuter revert-checks. * fix(node): verify the cwd anchor for relative p2p key paths A bare-relative key path is now walked from a verified working directory: the cwd is opened as '.' with O_NOFOLLOW|O_DIRECTORY, fstat-verified for ownership and write bits before any relative component is touched, and a writable or foreign-owned cwd is refused before anything is created. The refusal names the working directory path. Child-process fixtures prove both directions without mutating the shared process cwd. * test(node): stop rendering uids in p2p assert-message strings CodeQL flags the uid-interpolating assert messages as cleartext logging to a console sink. Every assert message in the p2p test module now avoids interpolating uid values or the uid-bearing error text, while the substantive assertions (the refusal names both uids, the ownership check fires before the chmod) stay intact and are verified by the same assertions. * test(node): add walk rows to the p2p key-storage contract matrix The matrix now proves the ancestor-walk refusals table-driven: a group-writable (0775) ancestor, a world-writable non-sticky (0777) ancestor, and an intermediate symlink component are each refused with the no-mutation snapshot discipline, while the existing boot rows still reload to a stable PeerId. The fchmod-on-create path pins newly created ancestors to 0700 regardless of the ambient umask. * docs(node): note the verified working directory for relative p2p key paths README, .env.example, and the clap help for GITLAWB_P2P_KEY now state that a relative key path is anchored at a verified working directory, and that an unsafe cwd or ancestor is refused with p2p off while HTTP stays up. Also normalizes two pre-existing em dashes in the README settings table. * fix(node): pin and verify the mode of every key object this process creates POSIX applies the process umask to every requested creation mode, so the 0700 passed to mkdirat and the 0600 passed to openat were requests rather than results. Under a mask that strips owner bits the created directory landed 0000 and the no-follow reopen failed EACCES before the repairing fchmod was reached, so that half failed loudly. The scratch key was worse: it was published unreadable, the boot that created it succeeded on its already-open descriptor, and only the next boot lost p2p, behind a health check that still reported healthy. Every object this process creates now goes through one rule: create, pin the mode on the object just created, reopen, and verify the achieved mode by fstat. The directory pin is issued by name off the verified parent before the reopen, because a directory that landed 0000 cannot be opened at all, so a pin that waits for the reopen is unreachable in exactly the case it exists for. A race winner is verified as-is and never chmodded, which is the rule the ancestor walk already applied. Pinned's field is private to the pin module and no constructor is exported, so a descriptor that skipped the pin cannot be turned into a key-directory handle or reach publication. That is what keeps the rule from depending on review. Two adjacent corrections the same defect exposed. The leaf mode predicate was supersets-only: mode & 0o077 != 0 asks whether anything is granted beyond the owner, so 0000, 0100 and 0400 all passed it while being unusable, and an inherited setgid bit was judged on the wrong bit width. A loose directory is still tightened; an over-closed one is now refused with its remedy rather than widened, matching how an over-closed key file is already handled. And an unreadable key or key directory now names its own cause: every open failure previously reported a refused symlink, which is what an operator saw for a key masked at creation. The matrix runs first boot and fresh-process reload across umask 0000, 0022 and 0777, crossed with missing and existing ancestors and leaf, with concurrent creators and an injected write failure. It runs in child processes because umask is process global, and it requires at least one successful concurrent creator so a row where every creator fails cannot pass. All 21 rows were RED under umask 0777 before this change. * fix(node): create and publish the node identity key through the pinned path The node identity PEM had its own storage flow: create_dir_all with no mode, then write, then set_permissions. That is the exists-then-write-then- chmod sequence INV-23 prohibits, and it sits in the same ~/.gitlawb the p2p key uses, so the umask defect the previous commit fixed for one key was still live for the other. Measured on the current code, as a non-root uid, all three RED: umask 0000 directory landed 0777, world-writable, holding the key umask 0022 directory landed 0755, world-traversable umask 0777 directory landed 0000 and the write failed with EACCES The third is the one that mattered most: load_or_create_keypair runs before the listener binds, so the node exited there and no p2p code was reached at all. The umask-independence guarantee could not be demonstrated on the shipped default while this stood. The directory is now created through the same pin helper, at a verified 0700, and the PEM is published through the same scratch-then-link path at a verified 0600. An existing directory that grants access beyond the owner is tightened, which closes the other half of the same gap: a 0600 key inside a 0755 directory is still replaceable by anyone who can write that directory. An existing key is loaded untouched and never chmodded. Deliberately not the full ensure_key_dir. That carries the ancestor trust walk, and importing its refusals onto a path that never had them would turn an unsafe but currently booting deployment into a boot failure on upgrade. Only the immediate parent goes through the pin helper, which verifies the grandparent it is about to chmod a child of; ancestors above that keep the existing create_dir_all behavior. The one new refusal is a group or world writable non-sticky grandparent, which is the case where another local user can replace the node's identity outright. * fix(node): split p2p key config validation from live storage validation The key-path validator answered two different questions and its callers disagreed about what to do with the answer. Bare names, `..`, a trailing separator and the filesystem root are properties of the configured value, and Config::validate refuses them before the listener binds. The same function also stat'd the key path and its parent, so a symlinked parent, a non-directory parent or an unreadable parent exited the node as invalid configuration, while the identical class of fault found one layer later in load_or_create_p2p_keypair only logged and left HTTP serving. That split was invisible from the outside and the docs described only one half of it. Measured against the binary before this change: a symlinked parent, a regular-file parent and an unreadable parent all exited 1 before bind, which is the opposite of what README and .env.example promise. Validation is now lexical only, behind a P2pKeyConfigError so the two domains cannot be confused at a call site. Every live storage fact is left to the load path, which already re-establishes each one on a descriptor it opened rather than a pathname it stat'd: O_NOFOLLOW on the key open, a regular-file check by fstat, and ELOOP or ENOTDIR at the leaf. The verdicts are unchanged; what changes is that one policy now decides all of them. Two supporting changes. The whole p2p port gate moves ahead of the database connect, both arms together, because connect_db_with_retry retries forever and left the disabled arm unreachable without a database; only p2p::start still needs the pool. And a failed key load is now logged at error with a stable event name and mirrored into a gauge, because the policy this commit settles on is to keep serving HTTP with a green health check while the node is off the p2p network, and that is only defensible if the outage is visible to something other than a human reading startup logs. A new integration test drives the real binary with no database and proves both domains at the process boundary: nine lexical spellings exit before binding, ten storage faults serve HTTP with the failure logged, and GITLAWB_P2P_PORT=0 reaches its disabled log without touching the key tree. Every row asserts a before/after snapshot, because a refusal that mutates storage on its way out is its own defect and a returned error cannot show it. Three of those rows were RED before this change. A symlinked key directory also reports as a symlink again. Linux returns ENOTDIR rather than ELOOP when O_NOFOLLOW meets O_DIRECTORY, so the errno alone cannot separate a symlink from a regular file and the message had regressed to naming the wrong cause. * docs(node): state the two-domain key-path policy and how to see a degrade README and .env.example promised that p2p stays off while HTTP keeps serving when the key cannot be loaded, including for an unsafe ancestor or working directory. Measured against the binary, that was false for a symlinked parent, a non-directory parent and an unreadable parent, each of which exited before binding. The preceding commit made the code match the promise; this makes the promise precise. All three operator surfaces now name the split the same way. A value that cannot name a securable key file is refused before the node binds. Anything wrong with the storage itself degrades, and the sentence says how to notice: the node logs p2p_identity_key_load_failed at error and sets the matching metric, /health stays green in that state, and fixing the storage and restarting restores the same PeerId. A node quietly off the network is the cost this policy accepts, so the docs point at the signal rather than leaving an operator to find it in startup logs. Two corrections while here. The key directory is tightened only when it grants access beyond its owner; one closed too far is refused with a chmod 700 remedy rather than widened, so the sentence no longer implies the node will open up a directory an operator locked down. And the existing advice to delete a key after a tightening warning is now scoped to the loosening case it was written for: an over-closed directory is refused, not tightened, and nothing in it was ever exposed, so following that advice would have meant deleting a safe key and taking a second PeerId rotation that breaks every pinned bootstrap multiaddr. * test(node): pin the degrade signal and wait for both startup lines Two gaps in the boundary test, both found by extending the mutation spec to cover this commit's own guards. The degrade rows asserted only the prose message, so renaming the event field or dropping the level would have passed while every alert built on the operator docs broke and the node still looked healthy. The rows now pin the error level and the p2p_identity_key_load_failed name the docs tell operators to watch. The rows also waited on a single log line, which is a race: the degraded server logs "ready" from a spawned task while the p2p gate logs its verdict from the main task, so whichever the reader stopped at first left the other uncaptured. It passed when the test binary ran directly and when the row ran alone, and failed only once other work shifted the scheduling. Reads now wait for every needle before returning. The fix stays on the test side on purpose. Logging the p2p verdict before the degraded server is spawned would also make the order deterministic, but that is production sequencing changed for a test's convenience. * fix(node): keep key publication transactional and path-policy split Bare GITLAWB_KEY filenames publish into the working directory without chmodding it. A directory this process created is removed if pin or verify fails. Ancestor walks use search descriptors so a safe 0111 component is traversable. Scratch unlink is part of publish success and is fsynced. Rotation advice is limited to writable or readable exposure, not ordinary 0755 tightening. * fix(node): refuse a writable cwd for a bare identity key Publishing identity.pem into cwd must not chmod cwd, but a 0600 key is still replaceable if that directory is group or world writable. Apply the same trusted-parent check used for nominated key directories before the handle is returned. * fix(node): load identity without following pathnames Create already published through a directory handle. Load still used exists-then-read, which followed a symlink at the key and opened the grandparent by pathname. Open both no-follow, treat /identity.pem like a cwd publish so it reaches the filesystem, and open a search-only grandparent with the walk flags. * fix(node): parse key paths, leave identity parents, repair special modes A terminal `.` in GITLAWB_P2P_KEY was accepted then retargeted by Path onto the parent directory. Identity creation imported p2p's 0700 pin onto any existing named parent. A setgid-only 2700 key directory skipped repair and disabled P2P. Darwin ancestor walks still required directory-list permission. * fix(node): type-check the non-unix p2p scratch writer The shared scratch-then-link path names pin::Pinned on every target, but the pin module was unix-only, so gitlawb-node did not compile off Unix. * fix(node): refuse identity path spellings that Path would retarget GITLAWB_KEY had the same terminal-dot hole as GITLAWB_P2P_KEY, and its tilde expansion did not refuse a suffix that escaped home. Bare filenames stay legal. * fix(node): create every missing identity parent on one pinned walk The identity key path split one creation transition across two policies. `create_dir_all` built every ancestor above the immediate parent at the ambient umask, then `create_dir_pinned_at` ran `verify_trusted_parent` on the last of those and refused it. Under umask 0002 that ancestor lands 0775, so the phase that made it handed it to the phase that rejects it: the node exits before binding and the failed boot leaves the directory behind at 0775, so the next attempt starts from state the first one made. Replace the split with one descriptor-anchored walk. Pass 1 walks up from the key's parent until a component opens; that descriptor is the anchor, and it is the same fd the next step creates into. Pass 2 walks back down calling `create_dir_pinned_at` per component, each one pinned 0700 and verified at its achieved mode before it becomes the parent of the next, so from the anchor down no pathname is resolved twice. Pre-existing ancestors are adopted as-is and never chmodded, since GITLAWB_KEY is a file path rather than a dedicated-directory setting; write-authority is still required on the directory each component is created in. A boot that fails past the walk now removes exactly what it created, deepest first, through unlinkat with AT_REMOVEDIR against the descriptor each entry was made in. A race-adopted directory is never in that list, and AT_REMOVEDIR refuses a non-empty directory, so a leaf another boot has published into survives. The accumulator is an out-parameter so a mid-walk failure and a post-walk failure reach the same single rollback arm. Two consequences worth naming. A symlink at the deepest existing ancestor is refused when the missing suffix reaches it, where `create_dir_all` followed it. Ancestors ABOVE that anchor are still resolved by pathname and their symlinks still followed, unchanged from before this walk, because O_NOFOLLOW binds only the final component of a path-based open; closing that would mean an openat chain from the root and the full ancestor policy that GITLAWB_KEY paths deliberately do not get. The doc comment now says so rather than claiming more than the code does. And a losing concurrent first boot can remove an intermediate another boot adopted but has not yet written into, turning that boot's start into an ENOENT failure; both still fail closed. Also replace the root-adjacent test. It proved a pathname property by running the full mutating path against the real filesystem root and assuming the runner lacks permission. Under euid 0, common in build containers, `/` is accepted (root-owned, 0755, no group or other write bit), the production path returns Ok, the test's panic arm fires before its cleanup assertion, and a real private key is left at /identity.pem, after which the leading exists() check makes every later run a silent skip. The routing is now asserted lexically through a named predicate, with no filesystem access and no dependence on euid. The matrix covers one, two and three missing levels under umasks 0000, 0002, 0022 and 0777, a pre-existing 0755 ancestor that must stay 0755, a relative multi-level path, a symlinked deepest ancestor, refusal without partial mutation, and a populated leaf whose removal must be refused and reported. Created-directory modes are asserted by exact equality, and each success row reloads in a fresh process and requires the same DID. * test(node): race real concurrent first boots of the identity key The rollback added with the pinned walk can remove an intermediate that a concurrent boot has already adopted, and until now that was reasoned about rather than executed. Nothing in the suite started two real first boots against the same key path. Add a `concurrent-first-boot` layout to the self-exec fixture and a driver that races several children through `load_or_create_keypair_at` on one missing multi-level path. A two-phase file rendezvous puts every child inside a spin loop before any of them is released, so the spread across the racing call is one loop iteration rather than process-startup jitter. Three arms: unaided boots, one injected write failure against one unaided boot, and four injected failures against one, which is what actually opens the window. The assertions are properties of every legal outcome, never one interleaving, so the test is deterministic even though the race is not. A boot that claims success has a parseable 0600 key on disk, all successes agree on the DID, surviving directories are exactly 0700 with no scratch residue, and if no key was published then nothing claimed success and a retry must still work. Observation counters are printed, not asserted, so a run that never hits the window says so rather than passing as proof. Two things the race showed that reading could not. The documented window is real: a boot was refused with "No such file or directory" on its publish after a loser rolled back the leaf it had adopted. But the more common shape is one hop earlier, the loser removing an adopted intermediate so the ENOENT lands on the next component's creation instead. And under enough concurrent rollbacks every boot can fail, not merely the losers, so several nodes starting against a shared first-boot path can all need a restart. Two-child racing never opened the window at all in 500 iterations. * fix(node): resolve identity key path components one at a time `O_NOFOLLOW` binds only the final component of a path-based `open(2)`, which is all the kernel offers for a multi-component pathname. Three sites resolved a whole configured path in one open and so guarded only the last position: the load path, the existing-named-parent fast path, and the walk that creates missing parents. Every interior symlink was followed, and `verify_trusted_parent` then attested the directory that was reached rather than the path taken to it. That is enough to substitute the node's whole identity, not merely misplace its key. Load and create resolve the configured pathname identically, so repointing one interior link redirects both. Point it at a directory holding another PEM and the node boots as that DID while its real key sits untouched on disk and nothing is logged as wrong. Point it at an empty directory and the node mints a fresh identity and reports a first boot. Neither needs the attacker to read anything: ownership and mode checks still pass, because they run on the object at the end of the path. Resolve each component with `openat` and `O_NOFOLLOW` against the descriptor of the one before it, from `/` for an absolute path or the working directory for a relative one, so a symlink is refused at every position. Interior components open search-only and the final component keeps the caller's flags, so a legitimate 0111 ancestor still resolves and the leaf descriptor is still the one that gets fsynced and chmodded. Components are adopted with no ownership or mode judgment. The only new refusal is a symlink on the key path: a shared 0775 volume, a foreign-owned ancestor and `/etc` all keep working, because `GITLAWB_KEY` is a file path rather than a dedicated-directory setting. `verify_trusted_parent` stays exactly where it was, on the descriptor a child is created in. The p2p key path is untouched; it already walked component by component. This is pre-existing rather than a regression: the same probe against the branch point produces the same result. It is fixed here because closing it replaces the walk this branch just added, so splitting it would mean reviewing that code twice. Covered by rows for an interior symlink with the next level present, an absolute target escaping the base, a two-link chain, the fast path, a relative configured path, and both load-path variants asserting on the DID the node ends up presenting rather than on a mode or an error string. The cases that were already refused are pinned too, including a symlink at the immediate parent and a dangling link, neither of which had a test before. --------- Co-authored-by: Kevin Codex <[email protected]>	2026-11-04 17:02:15 +00:00
JATMNandClaude Opus 5.5	623b600835	fix(deps): bump libp2p to pick up hickory 0.26 and serde_with 3.22 (#518) ... hickory-proto/hickory-resolver 0.25.2 were pulled in only by libp2p-dns 0.44. libp2p-dns 0.45 moves to hickory 0.26 but needs libp2p-core 0.44 and libp2p-identity 0.3, so the node's direct libp2p crates move to the matching release line (core 0.44, gossipsub 0.50.1, identify 0.48, identity 0.3, kad 0.49, quic 0.14, swarm 0.48, dns 0.45). multiaddr goes to 0.19 to match libp2p-core and avoid compiling two copies. No source changes were needed. Lockfile: hickory-proto/resolver 0.25.2 -> 0.26.3 (GHSA-q2qq-hmj6-3wpp / RUSTSEC-2026-0119, GHSA-6f2x-v7q7-m7m5), serde_with 3.18.0 -> 3.22.0 (GHSA-7gcf-g7xr-8hxj). With the fix in, drop the RUSTSEC-2026-0118/0119 ignores from .cargo/audit.toml as #76 requires. Closes #76 Co-authored-by: Claude Opus 5.5 <[email protected]>	2026-11-04 16:37:21 +00:00
JATMNandClaude Opus 5.5	151d688387	fix(deps): bump aws-smithy-json to 0.62.7 (GHSA-8ffr-xgwf-xj56) (#516) ... Cargo.lock resolved aws-smithy-json 0.61.9 (via aws-sdk-s3 1.119.0) and 0.62.5 (via aws-config and the sso/ssooidc/sts clients). Both are in the range affected by GHSA-8ffr-xgwf-xj56 / CVE-2026-18140 (<= 0.62.6): uncontrolled recursion when skipping unknown keys in deeply nested JSON. 0.62.7 requires aws-smithy-runtime-api ^1.12.3, so the AWS SDK moves as a set to the newest releases that still build on our 1.91 MSRV (they declare rust-version 1.91.1; later releases need 1.94.1): aws-config 1.8.18, aws-sdk-s3 1.137.0 (which itself requires aws-smithy-json ^0.62.7), aws-sdk-sso 1.102.0, aws-sdk-ssooidc 1.104.0, aws-sdk-sts 1.107.0, aws-sigv4 1.4.5, and matching aws-smithy-* crates. aws-sigv4 1.4.5 moves to p256 0.13, which drops crypto-bigint 0.4.9 from the lockfile. Update the RUSTSEC-2026-0387 note in .cargo/audit.toml to match; the ignore is still needed for crypto-bigint 0.5.5. Lockfile and audit-config comment only; no manifest or source changes. Co-authored-by: Claude Opus 5.5 <[email protected]>	2026-11-04 15:14:11 +00:00
JATMNandClaude Opus 5.5	4d024e01bc	fix(deps): resolve cargo audit failures on main (#514) ... * fix(deps): resolve cargo audit failures on main Update quinn-proto 0.11.19, rustls 0.23.46, rustls-webpki 0.103.16, webpki-roots 1.0.11, zstd 0.13.4, zstd-safe 7.4.0 and zstd-sys 2.1.2 in Cargo.lock to clear RUSTSEC-2026-0338..0342, 0346..0349, 0381, 0382, 0391, 0398, 0403 and 0410. Ignore RUSTSEC-2026-0387 (crypto-bigint): the fix is only in 0.7.x, and no dependent compatible with our tree uses it. alloy-signer (through 2.5.0) pins elliptic-curve 0.13, and aws-sigv4 >=1.5 requires Rust 1.94.1, above the 1.91 MSRV. Co-Authored-By: Claude Opus 5.5 <[email protected]> * docs(audit): document RUSTSEC-2026-0387 reachability and graph-based removal Correct the aws-sigv4 boundary (1.6.4 is the first release on crypto-bigint 0.7; 1.5.x-1.6.3 still need ^0.5.4), mark the ignore as reachable through the k256 PrivateKeySigner and SigV4a signing paths, and tie removal to Cargo.lock having no crypto-bigint below 0.7.6. Co-Authored-By: Claude Opus 5.5 <[email protected]> --------- Co-authored-by: Claude Opus 5.5 <[email protected]>	2026-11-04 12:26:02 +08:00
beardthelion	6588590813	chore: update rustls 0.23.37 → 0.23.45 to resolve RUSTSEC-2026-0285 (#455)	2026-11-04 01:23:10 +00:00
Kevin Codex	21c74c65d9	Merge pull request #223 from Gravirei/fix/issue-220-whoami-registered-false-trust-lookup ... fix(gl): only report registered: false on 404 in whoami (#220)	2026-08-25 22:04:56 +08:00
Gravirei	861cced8f8	chore: update h2 0.4.13 → 0.4.18 to resolve RUSTSEC-2026-0258	2026-08-24 15:10:32 +06:00
beardthelion	ba44a018ec	fix(core): share the origin-scoped redirect rule with the git helper ... The previous commit stopped the CLI carrying request signatures to a host the node redirected it to, and left the other signing client alone. That one is the git remote helper, which is what actually runs on clone, fetch and push, and it had no redirect policy at all. A push signs from its first request, so a node answering 302 handed out a working credential, and on a 307 or 308 the pack body went with it. The rule now lives in core and both clients use it, so the two cannot drift apart again. Three guards were not holding what they claimed. Bounding the retry wait by the remaining deadline could be deleted with every test still green, which the timing shows was four real seconds of overshoot past the bound the docs advertise; the assertion was loose enough to pass either way and is now tight enough to fail. The refusing-gateway warning was asserted through a test-only mirror rather than the write the user sees, so deleting the write kept the test green. And both no-hint exceptions, the definitive not-found and the wrapped scan, were only ever reached without a token in hand, which is the one state where they do nothing. A response whose body failed partway through the read still replayed the held token for every remaining attempt, spending the whole ladder on one position and then reporting that the object might lie further on. A body cut by the read cap was already terminal for that reason; a body cut by a broken connection is the same unreadable state and is terminal now too. A successful fetch no longer buffers the whole object before writing a byte of it, so a node cannot make the client hold an arbitrary amount of memory inside a time limit that was never a memory limit. The remaining silent skips in the recovery loops now say what went wrong, including the manifest fetch and the body reads, so a failure there is reported rather than looking like an absent blob. Also: the redirect chain bound is off by one against reqwest's own, has a test, and its comment no longer claims to prevent something the request timeout already prevents.	2026-08-13 17:34:14 -05:00
beardthelion	a53c151879	chore: sync Cargo.lock after rebase onto main	2026-08-09 22:39:31 -05:00
beardthelion	659ee00d7d	test(git-remote): tear down the fetch tree with a Job Object on Windows (#192) ... run_bounded's clean-exit descendant reap was Unix-only: on Windows a git fetch leader that exits cleanly leaves the git-remote-gitlawb helper blocked in its ~300s HTTP request holding the inherited pipes, and taskkill /T can't reach a descendant once the leader is gone, so the reader joins blew past the promised bound. The child is now assigned to a Job Object at spawn (the analog of the Unix process_group(0)), and the job is terminated on both the timeout and clean-exit paths, which kills the whole tree regardless of leader liveness. KILL_ON_JOB_CLOSE is the safety net. The clean-exit regression is now cross-platform so it exercises this on a future Windows CI lane (#228). Unix tests unchanged and green; the Windows path is compile-verified for x86_64-pc-windows-msvc (runtime coverage lands with #228's CI lane).	2026-08-09 22:39:31 -05:00
beardthelion	4201ce4d58	test(git-remote): reap the whole fetch process group and make the withheld guard load-bearing (#192) ... Address jatmn's two P2 review findings on real_git_fetch.rs. F1 (INV-22): run_bounded killed only the top-level `git fetch` on the timeout path, so the git-remote-gitlawb helper descendant kept the inherited stdout/stderr pipe write-ends open and the reader joins blocked on the helper's ~300s HTTP timeout instead of the 30s deadline. Spawn the child with process_group(0) and, on timeout, tear the whole group down (SIGTERM, ESRCH poll, SIGKILL escalation, bounded cap, then reap) before joining, mirroring gitlawb-node/src/git/smart_http.rs. libc is added as a cfg(unix) dev-dep; non-unix keeps the child.kill() fallback so the always-on test still compiles. New regression run_bounded_reaps_descendants_holding_the_pipe: a backgrounded sleep inherits the pipe and outlives a 1s-deadline leader; reverting to a leader-only kill turns it RED (elapsed ~10s). F2 (INV-21): the non-success branch of real_git_withheld_shaped_first_post accepted any `git fetch` failure and only printed the POST count, so a failure before the first POST (broken advertisement, helper lookup, connection) passed as the expected withheld rejection. Assert posts >= 1 before accepting the nonzero exit. Forcing a pre-POST failure (0 POSTs) turns the assertion RED.	2026-08-09 22:21:00 -05:00
github-actions[bot]	5f445152a8	chore: sync Cargo.lock with the release version bump	2026-08-03 02:44:15 +00:00
euxaristia	ee9bc93198	chore(deps): bump ruint to 1.20.0 for RUSTSEC-2026-0220 ... cargo audit fails on ruint 1.17.2 (incorrect overflow flags / truncated shift amounts). Upgrade the lockfile to the patched 1.20.0 release.	2026-08-01 05:47:26 -04:00
t	f2f99c6684	chore: regenerate Cargo.lock for the 0.7.0 manifests after rebase ... The branch forked before v0.7.0 merged, so the rebase left main's 0.7.0 manifests against workspace lock records still at 0.6.0. That state fails the gate this PR adds: `cargo metadata --locked` exits 101 with "cannot update the lock file because --locked was passed". Regenerated with `cargo update --workspace`, the same command the new sync-release-lock job runs. Only the 5 workspace crates move 0.6.0 -> 0.7.0; all 252 external dependencies are unchanged, so this is a version resync and not a dependency bump. `cargo metadata --locked` now exits 0.	2026-07-27 18:28:00 -05:00
t	b8eff30fc2	chore: sync Cargo.lock with the 0.6.0 manifests	2026-07-27 18:26:45 -05:00
beardthelionandt	c7427e943d	test(icaptcha): assert obtain_proof consumes the mocked service (#184) ... * test(icaptcha): assert obtain_proof consumes the mocked service Add an integration test that runs obtain_proof against a mockito server and asserts both /v1/challenge and /v1/answer were consumed, so the flow is proven to call the service rather than short-circuit or make a live call. Adds mockito as a dev-dependency. * test(icaptcha): block non-mock egress so the no-live-call guard is real (#184) The mock-consumed assertions only prove the two mock endpoints were hit; they cannot see a request that also leaks the DID, answer, or API key to DEFAULT_URL or any other origin, so the test's stated "no live call" guarantee was untested. Blackhole every non-loopback destination for the flow: NO_PROXY lets the loopback mock through while ALL_PROXY routes any other host to a closed port, so the client contacting anything but the injected mock fails the request. Verified load-bearing: pointing cfg.url at DEFAULT_URL makes obtain_proof fail with a proxy tunnel error (RED), and the loopback-mock path still passes (GREEN). * test(icaptcha): blackhole scheme-specific proxy vars so the no-live-call guard covers https The mock-consumed guard blackholed non-loopback egress with ALL_PROXY only, but reqwest honors HTTPS_PROXY/https_proxy (and the http equivalents) OVER ALL_PROXY for https URLs. On a runner whose environment has a working HTTPS_PROXY, a regression could still leak the DID/answer/API key to the https DEFAULT_URL while both loopback mock calls are consumed and the test stayed green. Override the scheme-specific proxy vars (both cases) to the closed port too; NO_PROXY keeps the loopback mock direct. Single #[test] per process, so the override needs no restore. Verified: a throwaway repro showed reqwest routing an https request to HTTPS_PROXY past the ALL_PROXY blackhole (the gap); with the fix the override sends that egress to the closed port even when a working HTTPS_PROXY is pre-set; the guard still goes RED when cfg.url points off-loopback. --------- Co-authored-by: t <t@t>	2026-07-22 08:25:53 +08:00
beardthelionandt	ee8d7c03b2	fix(node): gate /hooks and sibling read surfaces leaking private repo metadata (#94) (#113) ... * fix(node): owner-gate list_webhooks to stop leaking webhook URLs (#94) list_webhooks sat on the optional_signature read group with no auth or ownership check, so any unauthenticated caller who knew a repo's owner/name could enumerate its webhooks (target URL, created_by_did, events; only the secret was redacted). Gate it read-visibility-then-owner, mirroring create_webhook/delete_webhook: headerless -> 401, non-reader of a private repo -> 404 (existence hidden, uniform with the sibling read surfaces), non-owner of a public repo -> 403. Add a list_webhooks row to the authz_guard drift table so the gate can't silently regress. * fix(node): read-visibility-gate list_replicas for private repos (#94) list_replicas sat on optional_signature with no visibility check, so a private repo's replica URLs were enumerable by anyone who knew owner/name. Replica lists are a documented public mirror-discovery surface, so gate on read visibility (authorize_repo_read) rather than owner-only: a public repo stays anonymously listable, a private repo returns 404 to anyone who cannot read it. register_replica registers non-owner DIDs, and a replica operator is not a visibility reader, so a non-owner replica operator of a private repo gets 404 — the intended contract, pinned by the new test. Add the authz_guard row. * fix(node): read-visibility-gate list_protected_branches (#94) list_protected_branches sat on optional_signature with no visibility check, leaking a private repo's branch names to any unauthenticated caller. Gate on read visibility (authorize_repo_read at the root, INV-2 root-listing exception): public repos stay anonymously listable, private repos 404 to a non-reader. Add the authz_guard row. * fix(node): gate list_repo_events for local private repos, keep gossip-only (#94) list_repo_events served a private repo's ref certificates and gossip ref metadata (ref names, SHAs) to any unauthenticated caller. The handler also tolerates a repo it knows only via gossip (no local row) and legitimately serves its events, so a blanket get_repo->authorize_repo_read swap would have 404'd that federation path. Gate only the locally-hosted branch: when get_repo returns a record, run visibility_check on it at the root and 404 on deny before fetching either the cert or gossip events. A gossip-only repo (no local row) keeps its existing public federation-feed behavior; the global /api/v1/events/ref-updates feed remains a separately tracked deferral. Add the authz_guard row (visibility_check marker, since the gate is direct to avoid a second get_repo). * fix(gl): sign the webhook list request now that GET /hooks is owner-gated (#94) `gl webhook list` built its NodeClient with no keypair, so the GET went out anonymously. With the node now owner-gating GET /hooks, that request returns 401. Thread a --dir through the List subcommand and load the keypair, matching `gl webhook create`/`delete`, so the listing is signed as the owner. (Replica and protected-branch listings stay anonymous for public repos under read-visibility gating, so their gl clients need no change.) * fix(review): sign the webhook list GET (get_signed), not plain get (#94) Code review caught that NodeClient::get() never attaches the RFC 9421 signature even when a keypair is loaded — only get_signed/post/put/delete sign. The earlier gl webhook-list fix loaded the keypair but still called get(), so `gl webhook list` (and the MCP webhook_list tool) 401'd against the now-owner-gated endpoint. Switch both to get_signed. Harden the two cmd_list tests to require a Signature/Signature-Input header on the mock (verified: they fail against plain get(), pass with get_signed) — the missing assertion that let the bug through. Add the untested owner-of-private- repo webhooks path (200 + redaction). Fix the stale module doc and the authz_guard bucket comment for list_webhooks. * fix(gl): sign read-visibility GETs so private-repo owners can read their own repos (#94) The #94 server change read-visibility-gates GET /replicas and /branches/protected: public repos stay anonymous, private repos require the owner/reader to authenticate. Four gl read commands sent unsigned GETs and so broke (404) or silently degraded (empty output) for a private repo's owner: gl protect list, gl repo owner (silent empty protected list), gl repo info (silent missing replica count), gl repo replicas (and it had no --dir flag). Add NodeClient::get_maybe_signed — signs when an identity is present, stays anonymous otherwise (mirrors the conditional signing of post/put/delete) — and route the four call sites through it. Add --dir to `gl repo replicas`. Harden the protect-list tests to assert the request is signed (verified: they fail on plain get()). Public-repo anonymous reads are unchanged. * fix(review): sign the primary repo fetch in gl repo info/owner too (#94) Round-2 review caught that cmd_info and cmd_owner loaded a keypair and signed their replica/protected-branch sub-fetch but left the PRIMARY GET /api/v1/repos/{owner}/{name} on plain get(). get_repo is read-visibility-gated, so for a private repo that primary fetch 404'd first and the command bailed before reaching the signed sub-fetch — the half-fix never actually let an owner inspect their own private repo. Route both primary fetches through get_maybe_signed. Add the missing signing guards: harden test_cmd_owner_is_owner to require a signature on both mocks, and add tests for cmd_replicas and cmd_info (both were untested) asserting the request is signed when an identity is present. Out of scope (pre-existing, gated before #94, untouched here): gl repo commits, gl pr list/view/diff, and the MCP repo_get/repo_commits/pr_* tools call other already-gated read endpoints unsigned and are broken for private repos independently of this change. * test(review): execute the previously-reasoned-only paths (#94) Close the vetting gaps from the review: - node: a listed reader (non-owner) passes the read gate but is still refused the webhook list (403), and headerless on an existing-private vs an absent repo both 401 — proving the 401 fires before any lookup, so it is not an existence oracle. - node: the read-visibility surfaces (replicas, protected branches) admit a listed reader who is not the owner (the allow-list branch of visibility_check), while a non-reader stranger still 404s. - gl: get_maybe_signed's anonymous fallback (no identity -> unsigned GET) is now exercised, RED-proven by flipping it to get_signed (which signs and fails the no-signature-header assertion). * test(review): execute the MCP dispatch and gl->node signature seams (#94) Close the last two reasoned-only paths by execution: - MCP webhook_list: a call_tool("webhook_list", ...) dispatch test against a mock node asserts the /hooks request carries a signature (get_signed). RED-proven: flipping the arm back to get() fails the header assertion. - gl->node end-to-end: a real RFC-9421 signature produced exactly as the gl client's get_signed does (gitlawb_core::http_sig::sign_request over GET + empty body) is run through the node's actual optional_signature middleware, which verifies it and authorizes the owner (200 + webhook body). RED-proven: signing over POST while sending GET makes the node reject it. This stitches the gl signing side and the node verifying side in one test rather than mocking one end. * fix(review): fail closed when the repo lookup errors in list_repo_events (#94) `get_repo(...).await.ok().flatten()` collapsed a lookup Err into None, so a transient DB failure skipped the read-visibility gate and the handler served a private repo's gossip ref-update events. Propagate with `?` instead: an error now maps to AppError::Internal (500) and fails closed, while a genuine Ok(None) (repo not hosted locally) stays the intentional ungated pass-through. Add a regression test that forces a get_repo error (drop the column its SELECT reads) and asserts 500 with no secret in the body. The injection is self-verifying: it asserts the lookup succeeds pre-drop and errors post-drop, so the test can't pass vacuously if get_repo's projection changes later. * fix(node,gl): close residual gaps in repo-read gating (#113) Address jatmn's review feedback on the read-surface gate: - gl webhook: resolve owner from the signing identity, not the node DID. cmd_create/list/delete all routed through the local resolve_owner helper, which only ever returned the node root DID, so for a repo owned by the local identity the owner-gated /hooks route returned 404/403. Drop that helper and reuse repo::resolve_owner_repo_pair (accepts owner/repo, else derives from --dir/keypair). Fixed across all three subcommands so create-writes and list/delete-reads stay on the same owner. - gl webhook list: check the HTTP status before reading `webhooks`. A 401/403/404 body has no webhooks field and previously printed "No webhooks" and exited 0, hiding the rejection; now bails with the server message like cmd_create. - visibility::is_owner: delegate to api::did_matches so the read gate and require_repo_owner share one normalization. Fixes the under-match (bare owner stored, full did:key caller, as mirror rows) that denied the owner with the opaque 404, and the cross-method over-match. - authz_guard: pin both halves of list_webhooks (authorize_repo_read and require_repo_owner) so removing the existence-hiding gate fails the drift test. cargo fmt/clippy clean; 644 workspace tests pass. * test(node)+fix(gl): close events reader-coverage gap, align label-list signing Self-review follow-ups on the read-gate work: - list_repo_events: add list_repo_events_admits_listed_reader, pinning the allow-list branch of the events gate (a listed non-owner reader gets 200 with the cert; a non-reader stranger 404s with no leak). Mirrors the read_visibility_admits_listed_reader coverage the sibling replica and protected-branch surfaces already had; the events handler was the only gated read surface missing it. - gl repo: cmd_label_list now loads an identity and uses get_maybe_signed instead of a bare anonymous get(), matching cmd_replicas/cmd_info. Public repos stay anonymously listable; a private-repo owner can read their own labels once /labels is read-visibility-gated, with no silent client drift. fmt/clippy clean; 645 workspace tests pass. * fix(review): pin the label-list signing and the events 404 sha-no-leak Final-review hardening of the prior two follow-ups: - gl repo label-list tests: require the signature/signature-input headers on the signed-branch mocks, and add an anonymous (no-identity) test asserting the header is absent. Without the header assertion the tests passed even with a bare get(), so the signing change was not actually pinned (RED-verified: reverting to get() now fails both signed-branch tests). - list_repo_events_admits_listed_reader: also assert the cert sha (not just the ref name) is absent from the stranger's 404 body, matching the list_repo_events_is_read_visibility_gated leak-check convention. fmt/clippy clean; 646 workspace tests pass. * fix(gl): error on 2xx webhook-list body missing the webhooks array (#113) A 2xx /hooks response without a `webhooks` array could hide a node/API contract regression. cmd_list now errors with context instead of mapping it to "No webhooks". An empty-but-present array stays a valid no-webhooks result. Adds a test for the missing-array case. * fix(gl,node): scope MCP webhook_list owner to keypair, gate list_labels on read visibility (#113) - MCP webhook_list: default owner to the signing keypair's short DID (explicit owner arg still overrides) instead of the node root DID, so the signed, owner-gated /hooks request resolves to the caller's own repo. Mirrors the gl webhook list fix. resolve_owner and webhook_create/delete left untouched. - list_labels: gate on authorize_repo_read so a private repo's label names 404 for non-readers (public repos stay anonymously listable), matching the sibling read surfaces and making the existing client comment true. Added the authz_guard marker and a read-visibility integration test. - gl label list: check HTTP status before reading the body so the now-gated 404 surfaces as an error instead of printing "No labels" and exiting 0, matching the sibling list clients (replicas, protected branches). * fix(gl): surface denied repo info reads instead of fabricating a repo (#113) cmd_info parsed the GET /api/v1/repos/{owner}/{name} body without checking the HTTP status, so a private-repo JSON 404 was rendered as a fake repo summary (owner / ? / public / main) and exited 0. Capture the status and bail on non-2xx, matching the sibling list commands. Also assert the anonymous 404 label-list body does not leak the label name, closing the last unread-body branch in the read-visibility gate test. * test(node): drop #113-gated handlers from KNOWN_UNGATED; sync lockfile to 0.4.0 The repo-scoped egress guard's allowlist (added in #122, merged after this branch was opened) still listed the read surfaces this branch gates. Now that list_labels, list_repo_events, list_webhooks, list_replicas, and list_protected_branches are read-visibility gated, the staleness assert requires removing them from the allowlist. The #120 surfaces (certs, issues, bounties, stars) stay listed; git_info_refs stays until #119 lands. Lockfile versions follow the 0.4.0 release the rebase landed on. * fix(gl): fail the MCP webhook_list tool on non-2xx node responses The MCP webhook_list path deserialized the response body and returned it as a successful tool result without checking the HTTP status, so a 401/403/404 JSON error (missing identity, wrong owner, private or deleted repo) was reported as success with the error body as the result. Check status().is_success() before deserializing and surface the node's message as a tool error, matching the `gl webhook list` path. Covered by a non-2xx test (RED without the check). * fix(gl): read the protected_branches key in repo owner gl repo owner parsed the protected-branch response as a bare array or a "branches" key, but the node returns {"protected_branches":[...],"count":N}, so it always printed "Protected: (none)" even when branches were protected. Extract the parse into parse_protected_branches matching the gl protect list shape, and update the owner tests to mock the real schema instead of bare arrays (which is why the bug went uncaught). * test(gl): cover the deny/negative arms reconciled by the merge The merge changed three gl branches that no existing test executed (they were only reasoned): resolve_owner_did with no local identity, cmd_info on an authenticated-but-denied 403, and get_maybe_signed with no keypair. Add a test per branch asserting the must-not case (error/unsigned, never a fabricated repo card). Verified load-bearing by mutation: disabling the cmd_info status gate turns the 403 test red. --------- Co-authored-by: t <t@t>	2026-07-22 08:24:09 +08:00
beardthelionandt	d00d89ae5b	fix(node): gate POST /api/v1/sync/trigger and rate-limit the peer-sync routes (#82) (#161) ... * feat(node): add per-client-IP limiters + knobs for the peer-sync routes (#82) Plumb two dedicated per-IP RateLimiters into config/state so the peer-sync enqueue routes can be braked independently: sync_trigger_rate_limiter (tight, GITLAWB_SYNC_TRIGGER_RATE_LIMIT, default 60/hr) and peer_write_rate_limiter (generous, GITLAWB_PEER_WRITE_RATE_LIMIT, default 600/hr). Both are bounded and swept by the periodic cleanup loop, keyed via the node-wide push_limiter_trust. No route is wired to them yet; that lands next. * fix(node): require a signature on /sync/trigger and rate-limit the peer-sync routes (#82) /api/v1/sync/trigger was reachable unauthenticated in the default config and drove an O(peers) outbound fan-out + per-repo sync_queue enqueue — an anonymous amplification/DoS. The same enqueue_sink is reachable via /sync/notify, which also accepts unsigned known-peer requests and had no rate limit. - Move /sync/trigger into its own always-signed route group (add_auth_layers), independent of require_signed_peer_writes, and give it a tight per-IP brake. - Add a separate, generous per-IP brake to the peer-write group (/peers/announce, /sync/notify); notify's signature behavior is unchanged (rolling-upgrade compat), it only gains the brake. Separate buckets so an unsigned notify flood can't drain the signed trigger caller's quota. - Per-IP (not per-DID): a did:key farm self-registers, so a signature/per-DID gate does not cap cost (INV-10); the brake keys on the client IP before auth. Adds an adversarial test matrix (unsigned->401 both modes, IP flood->429, DID-agnostic brake, forged X-Forwarded-For can't bypass, notify flood->429, distinct-IP not throttled, cross-route non-exhaustion, 0-disables-but-sig-holds, announce still accepts unsigned). * fix(gl): surface node denial on sync trigger and sanitize the error body (#82) Now that the node gates /api/v1/sync/trigger behind a signature and rate limit, 'gl sync trigger' must not render a 401/429 as a fabricated '✓ sync triggered / 0 peers' success. Check resp.status() before parsing; on a non-2xx, extract the node's message and bail. Strip C0/C1 control bytes from the node-supplied string before printing (INV-6) — a hostile node could embed ANSI/OSC escapes in the body. Adds mockito tests: 401/429 surface as errors (RED without the status check), control bytes are stripped, and the 200 path is unchanged. * fix(review): bound gl error-body read, strip bidi controls, genericize 429 message (#82) Code-review follow-ups on the #82 change: - gl sync trigger: read the node error body with a capped reader (read_body_capped) instead of resp.text(), so a hostile/broken node can't force an unbounded allocation to surface a denial (INV-6, read half). - sanitize_node_msg: also strip Unicode bidi/format controls (U+202A-202E, U+2066-2069, LRM/RLM/ALM) — is_control() only covers the Cc category, but a right-to-left override can reorder the displayed error line. - too_many_requests(): the shared per-IP 429 middleware now serves the peer-sync routes too, so drop the push-specific wording ('rate limit exceeded'); the push-specific 429 in the receive-pack handler is unchanged. Adds tests for the bidi/length sanitize and the oversized-body path. * test(#82): close reasoned-not-run gaps with load-bearing tests Executes the branches that were previously only reasoned: - read_body_capped byte-cap test (RED against resp.text() — 2MB body -> ≤cap): vets the bounded-read fix, not just the display cap. - sync-route 429 body asserts 'rate limit exceeded' and NOT 'push' (RED before the message was genericized); also finishes genericizing the warn log, which the response-body change had missed. - real RFC 9421 signature through the full router reaches the handler (200) in both config modes — the positive path through the actual gate, not a direct-mount with an injected DID. - /peers/announce flood -> 429 (the peer_write brake covers announce, not just notify). - trigger_counts extraction unit test (happy + malformed -> 0,0), closing the count-formatting gap in the 200 path. No production behavior change beyond the warn-log wording. * fix(#82): require an identity for sync trigger and fix the rollout docs Address review feedback on the always-signed /sync/trigger route. - gl sync trigger now requires a local identity via load_keypair_from_dir and fails locally with "identity not found" before issuing a request, instead of .ok() silently sending an unsigned request that can only 401 remotely. Add a test proving it fails before dialing the node. - Split /sync/trigger out of the staged unsigned peer-write rollout in the README and the OSS-readiness audit; only /peers/announce and /sync/notify keep the rolling-upgrade unsigned behavior. - Reorder the two peer-sync rate-limit vars in .env.example for dotenv-linter. - Bump crossbeam-epoch to 0.9.20 (RUSTSEC-2026-0204), matching main, so cargo audit passes. --------- Co-authored-by: t <t@t>	2026-07-08 08:44:55 +08:00
beardthelionandt	67ad2b876c	fix(deps): bump crossbeam-epoch to 0.9.20 for RUSTSEC-2026-0204 (#162) (#163) ... RUSTSEC-2026-0204 (invalid pointer dereference in crossbeam-epoch's fmt::Pointer impl for Atomic/Shared) hard-fails cargo audit on every branch, since the advisory's addition to the RustSec db. crossbeam-epoch is a fully transitive dependency (moka -> hickory-resolver -> libp2p-dns), and the advisory's prescribed fix is >= 0.9.20; moka 0.12.15 accepts >=0.9.18,<0.10.0 so the bump resolves with no other graph changes. Lockfile-only, single crate. Verified: cargo audit exits 0 and the workspace builds clean with 0.9.20. Closes #162. Co-authored-by: t <t@t>	2026-07-07 22:46:44 +08:00
Kevin CodexandClaude Opus 4.8	06388ec26a	feat(gl): sanctioned iCaptcha client flow + secure git lifecycle (#138) ... * feat(gl): sanctioned iCaptcha client flow + secure git lifecycle Builds the client side of the iCaptcha gate so a legitimate agent passes the challenge transparently, with no manual headers and no GITLAWB_ICAPTCHA_PROOF env var. Server enforcement is unchanged. New crate `icaptcha-client` (blocking, shared by gl + the git helper): - deterministic solvers for the computational challenge types (arithmetic, algebra, sequence) matching the iCaptcha generators; anagram/logic/LLM fall back to a solver hook / interactive prompt. - obtain_proof(): POST /v1/challenge (requesterId = caller DID), solve, POST /v1/answer, handle escalation, return the signed proof. Optional bearer auth via GITLAWB_ICAPTCHA_API_KEY. gl (crates/gl): - http.rs: unify post/put/delete through one signed sender that, on a 403 iCaptcha challenge (detected via x-icaptcha-url / x-icaptcha-level headers), solves it and retries the same signed request with the x-icaptcha-proof header (bounded retry absorbs the ~5 min proof TTL). Removes the env hack. Emits an actionable hint on 401 not_an_agent (old-CLI / unregistered). - repo.rs: `repo info` checks status and returns a real 404 instead of a stub card with `?` fields; `repo info`/`clone` resolve the owner from the local identity or an explicit owner/name — never the node's own DID. - doctor.rs: warn on gl-vs-node version drift; add an iCaptcha reachability check. git-remote-gitlawb: same shared client — push stays signed (RFC 9421); on a 403 iCaptcha (safety net; push is signed-only, not gated) it solves and retries. Clone/fetch unsigned; missing repo keeps its clear 404. gitlawb-node: the 403 icaptcha_proof_required response now advertises the service url + required level as JSON fields and x-icaptcha-url / x-icaptcha-level headers (mirroring the human_detected pattern) so clients discover them instead of scraping the message. The sub == authenticated-DID and expiry/level checks are unchanged — enforcement is not weakened. README: documents the full lifecycle (identity -> register -> repo create with auto-iCaptcha -> push -> clone), the requesterId == DID rule, and proof TTL. Tested: solver unit tests; full workspace green against Postgres (node still rejects missing/expired/wrong-subject proofs). * fix(icaptcha-client,gl): address PR #138 review feedback Rebased onto main (resolving the git-remote-gitlawb/main.rs conflict from #119) and addressed the review findings: - [beardthelion P2 / jatmn P2 / CodeRabbit] Removed the dead iCaptcha retry loop from the push path. git_receive_pack never calls verify_request (only create/fork/register are iCaptcha-gated), so a push 403 never carries x-icaptcha-* headers and the loop could never solve. Taking main's push path (via #119) deletes it, which also resolves the pack-clone (retries no longer copy the whole pack) and the interactive-prompt-over-git-stream threads, and restores the sanitized info/refs error path. git-remote-gitlawb no longer depends on icaptcha-client. - [beardthelion P1] Sanitize and length-bound iCaptcha error bodies before they reach the terminal. The origin is only as trusted as the node that advertised it, so its non-2xx bodies (and Failed{reason}) are attacker-influenceable; they went raw into bail! (CWE-150, the #137 class). Now bounded-read + C0/C1-stripped + capped, same shape as #137. - [beardthelion P2] Do not trust or hand credentials to a node-chosen iCaptcha URL. x-icaptcha-url was used as the base with no scheme/host check and the API key was sent to it on the first hop (SSRF + key exfiltration). resolve_solver_url now honors an advertised URL only when https + host-allowlisted (public default or the operator's GITLAWB_ICAPTCHA_URL), else falls back to the trusted origin; the API key is attached only to the operator's own configured origin. - [jatmn P2 / CodeRabbit] gl repo clone with a bare name now derives the short owner key via resolve_owner_did, matching the other commands' gitlawb://z.../name URL shape instead of the colon-bearing full DID. Skipped (with reason): jatmn P3 (doctor GITLAWB_ICAPTCHA_URL) is resolved by the P2 change — that env var is now read by the write path, so the doctor's probe is accurate. CodeRabbit User-Agent-version nit lived in the push code reverted to main. README push wording kept ("signed-only, no per-push challenge") — now accurate since the retry path is gone; the API-key bullet was updated for the new trust model. Tests: added sanitize + resolve_solver_url unit tests; full workspace green. Co-Authored-By: Claude Opus 4.8 <[email protected]> --------- Co-authored-by: Claude Opus 4.8 <[email protected]>	2026-07-05 19:47:06 +08:00
beardthelionandt	6f36fc07b8	fix(node,git-remote): gate receive-pack advertisement, sign client fetch/push (#119) ... * fix(node,git-remote): gate receive-pack advertisement, sign client fetch/push The info/refs ref advertisement was gated only for service=git-upload-pack (the visibility check sat inside `if service == "git-upload-pack"`), so an anonymous GET /{owner}/{repo}.git/info/refs?service=git-receive-pack returned a private repo's branch names and commit tips, bypassing the read gate. Run the visibility "/" check for both services. Now that the advertisement is gated for both services, git-remote-gitlawb has to authenticate its own requests, or a private repo's owner can neither fetch nor push it. Sign the Phase-1 advertisement GET and the Phase-2 pack POST for both services over path_and_query when an identity keypair is present; public repos stay anonymous. This also repairs a pre-existing break where an owner could not fetch their own private repo, because the upload-pack POST was sent unsigned. Tests: node-side gate (anon denied, owner-signed cleared, both services); a real-signature seam proving the client's own signature verifies under the node's verification primitives; real served-content withholding against an on-disk repo (the owner gets the ref bytes, a denied caller's 404 omits them); and mockito coverage that the client attaches and omits signatures correctly. * docs(node,git-remote): correct auth-contract comments on receive-pack gating (#119) receive-pack POST is signature-required and separately owner-gated, not visibility_check-gated; push implies read, not read-subset-of-push. * test(node): assert unsigned receive-pack POST is rejected (#119) No test covered the signature-required half of the receive-pack auth contract. Wire the POST route behind require_signature as production does and assert an unsigned POST returns 401 before reaching the handler; 401 (not the handler's 404/500) proves require_signature rejected it pre-handler. * test(node): RAII-clean the served-refs test's temp dirs on panic (#119) advertisement_serves_real_refs_only_to_authorized_callers created /tmp/<slug>/<name>.git and /tmp/gl-seam-src-<short> and only removed them after the final assertion, leaking those dirs on the runner when an earlier assertion failed. Wrap each known path in a DirGuard whose Drop calls remove_dir_all, bound right after creation, so cleanup runs on success or panic. tempfile::TempDir does not fit here because repo_store::for_testing fixes the path layout. * test(node): drop git_info_refs from KNOWN_UNGATED now that #119 gates it The repo-scoped egress guard's allowlist (added in #122, merged to main after this branch was opened) still listed git_info_refs as ungated. This branch makes the info/refs visibility gate unconditional for both git-upload-pack and git-receive-pack, so the handler is now gated and the staleness assert requires removing it from the allowlist. * style(node,git-remote): tidy #119 review nits (em dashes, dead binding, test header) Post-rebase ce-code-review pass on #119. No behavior change: - replace em dashes in the added comments with commas/colons/parentheses - drop the dead `let _ = COVERED_COMPONENTS;` binding (and its import); the `missing_components().is_empty()` assert already covers the intent - add a section header above the new git-info-refs test block to match the module's sectioning convention * test(node): recurse nested api modules in the egress-gate guard The completeness scan in every_repo_scoped_handler_is_gated used a flat read_dir over src/api, so a future api/<module>/mod.rs could add a repo-scoped handler the scrape never inspects. Walk the api tree recursively via a new collect_rs_files helper (covered by its own unit test), skipping only the top-level mod.rs so nested module files are checked too. * fix(git-remote): keep public fetches anonymous, sign only on a 404 retry (#119) git-remote-gitlawb signed every git-upload-pack request whenever an identity existed, disclosing the caller's DID to any node it fetched a public repo from, even though public repos need no auth. Fetch now sends the advertisement GET anonymously and escalates to a single signed retry only when the node denies it with 404 (how it withholds a private repo from an unauthenticated reader); if the retry was needed, the upload-pack POST is signed too. Push (git-receive-pack) is unchanged and signs from the first request, since a push can never be anonymous. Verified against the node by execution: an unsigned private fetch returns 404, not 401, and a signed retry clears the read gate for the owner and for a granted non-owner reader, while a signed non-reader stays 404. Tests drive handle_connect end to end (recording mock): public fetch stays anonymous for GET and POST, private fetch retries signed once and signs the POST, a keyless fetch does not retry, a still-denied signed retry surfaces 404 once, and push signs from the first request. * fix(node): scan nested api sources by relative path in the egress guard (#119) The egress-gate completeness scan skipped already-covered files by basename (listed.contains(fname)), so a nested api/<module>/repos.rs would be skipped because the top-level repos.rs is listed, letting a future nested module add an ungated repo-scoped handler the scrape never inspects. Extract the skip logic into unlisted_source_files and match on the path relative to api_root, so only the exact top-level files already covered are skipped and a nested file with a colliding basename is still scanned. Completes CodeRabbit's outstanding request. --------- Co-authored-by: t <t@t>	2026-07-05 17:08:44 +08:00
GravireiandGravirei	6c95592d18	fix(node): prefer canonical repo row over mirror row in get_repo (#124) (#141) ... * fix(node): prefer canonical repo row over mirror row in get_repo (#124) get_repo matched both mirror rows (bare short-DID, is_public=true, no visibility rules) and canonical rows (full did🔑 DID, correct rules), returning one nondeterministically. When the mirror row won, the visibility gate saw is_public=true + empty rules, allowing unauthenticated read of private/withheld content. Add ORDER BY to prefer canonical rows (UUID id, no slash) over mirror rows (slash-form id), matching the ranking logic already used by DEDUP_CTE and dedupe_canonical_repos. Test seeds mirror FIRST so an unordered fetch_optional returns the mirror row — proving the test locks in the fix. * fix(test): date canonical row after mirror to guard CASE term in get_repo fix (#124) * fix(node): tighten get_repo owner matching to did:key only, not any DID method (#124 P2) * fix(node): refactor owner DID normalization to a dedicated function in create_repo * fix(node): align clone URL and slug construction with tightened did:key matching - Make normalize_owner_key pub(crate) and reuse it in api/repos, api/events, api/peers, and visibility modules. - Add read-gate authorize_repo_read and to_response clone_url slug tests. * fix(node): hoist owner-key CASE into shared const + address #124 review feedback - Hoist 7 verbatim SQL CASE copies into OWNER_KEY_CASE_SQL const (dedup_cte(), get_repo, count_repos_deduped), keeping one literal copy in the v7 migration with a cross-reference comment. - Add 9 unit tests for normalize_owner_key over the full boundary set. - Add LIMIT 1 to get_repo query for single-row intent. - Add non_key_owner_bare_short_does_not_match is_owner regression test. - Update is_owner doc to reflect did:key-only rule. - Document non-key clone_url disk-path constraint in to_response. * test(node): add SQL round-trip test for normalize_owner_key vs OWNER_KEY_CASE_SQL Verifies every boundary value produces identical results from the Rust function and the SQL CASE expression, preventing silent drift. --------- Co-authored-by: Gravirei <[email protected]>	2026-07-03 08:12:27 +08:00
Kevin CodexandClaude Opus 4.8	adc20f9eff	feat(node): iCaptcha proof-of-intelligence gate on create_repo + register (#108) ... * feat(node): iCaptcha proof-of-intelligence gate on create_repo + register Add an optional gate that requires callers to present an iCaptcha proof (an Ed25519-signed token from icaptcha.gitlawb.com, earned by solving an escalating challenge) on the two spam-prone endpoints. Proofs are verified OFFLINE with ed25519-dalek against the published public key, and bound to the authenticated agent DID so they cannot be shared. Backward-compatible by default: ICAPTCHA_MODE is `off` unless set, so deploying changes nothing. `shadow` verifies and logs would-be rejections but always allows; `enforce` rejects requests lacking a valid, strong-enough proof. If the public key cannot be loaded at startup the gate stays inert (fail safe) so an iCaptcha outage can never break repo creation or registration. - New src/icaptcha.rs: env-driven verifier (OnceLock), /v1/pubkey fetch at startup or ICAPTCHA_PUBKEY override, proof parse + signature + expiry + level + DID-binding checks; mode-aware decide() split out for testing. - Wired into create_repo and register (X-ICaptcha-Proof header). git push (receive-pack) is intentionally NOT gated. - 11 unit tests incl. verification of a real captured proof (JS-signed, Rust-verified), tamper/expiry/wrong-DID/level/missing-header rejections, and the off/shadow/enforce/fail-safe mode matrix. Author: Kevin Codex <[email protected]> * fix(node): address review on icaptcha gate (validate config, bound key fetch) Addresses CodeRabbit and @jatmn review feedback on #108: - parse_mode now returns Option and rejects unrecognized ICAPTCHA_MODE values; init() warns and falls back to off instead of silently disabling the gate on a typo like "enforced". [P2] - ICAPTCHA_REQUIRED_LEVEL: warn on a non-empty unparseable value instead of silently lowering the threshold to the default. [P2] - fetch_key uses a reqwest client with a 5s timeout so a hung /v1/pubkey can never block node startup; still fails inert on timeout/error. [P2] - .env.example: reorder ICAPTCHA_* keys (MODE, PUBKEY, REQUIRED_LEVEL, URL) to satisfy dotenv-linter. [P3] - add parse_mode unit test (rejects junk, accepts documented values). cargo test -p gitlawb-node icaptcha: 12 passed. clippy + fmt clean. Author: Kevin Codex <[email protected]> * fix(node): consume iCaptcha proof jti so a proof can't be replayed Addresses @jatmn P2 on #108: the verifier checked exp/level/sub but never consumed the proof's jti, so one solved challenge was a reusable bearer proof for that DID until expiry, covering every gated create_repo/register in the window. Now, in enforce mode, each verified proof's jti is recorded once and replays are rejected. - db: migration v7 adds icaptcha_consumed_proofs(jti PK, expires_at); new consume_proof_jti (INSERT ON CONFLICT DO NOTHING -> bool) and sweep_expired_proofs. DB-backed so it holds across restarts and instances. - icaptcha: ProofClaims carries jti; verify returns the claims; decide() stays pure and returns Allow | Reject | Consume{jti,exp}; check() is now async and spends the jti via the DB, rejecting replays (enforce only; shadow observes without consuming). - handlers: create_repo/register await check(&state.db, ...). - main: periodic sweep of expired proof rows alongside rate-limit cleanup. - tests: 12 pass incl. decide() yields Consume with the proof's jti. Author: Kevin Codex <[email protected]> * fix(node): consume iCaptcha proof only after request passes validation Addresses CodeRabbit (Major) on #108: check() spent the jti as soon as the proof verified, but create_repo/register ran it before name/DID/existence checks, so a rejected request (bad name, already-exists, wrong DID) permanently burned a valid proof without the action succeeding. Split verification from consumption: - icaptcha: replace check() with verify_request() -> ProofGuard (verifies and rejects invalid/missing proofs early; off/shadow/inert yield a no-op guard) plus ProofGuard::consume(db) which spends the jti right before the write and rejects replays. Guard is #[must_use]. - create_repo/register: verify_request() up front, then consume() immediately before the first write, after cheap validation passes. Replay protection unchanged (consume-before-write). 12 tests pass; clippy clean. Author: Kevin Codex <[email protected]> * fix(node): give iCaptcha rejections a dedicated error code Addresses CodeRabbit on #108: iCaptcha failure paths returned AppError::Unauthorized, which maps to the "not_an_agent" API code and conflates a valid-but-unproven agent with a failed signature. Add a dedicated AppError::IcaptchaProofRequired variant mapped to the "icaptcha_proof_required" code (HTTP 401), and use it for both the missing/invalid-proof and replay paths so clients can distinguish "solve a challenge" from "your signature is invalid". 12 tests pass; clippy + fmt clean. Author: Kevin Codex <[email protected]> * fix(node): gate fork_repo with iCaptcha and cover the proof ledger Address remaining PR #108 review comments: - fork_repo was the third repo-creation entrypoint and bypassed the iCaptcha gate. Verify the proof up front (fail fast on missing/invalid) and consume it only just before the git clone, so cheap rejections (bad name, conflict, withheld subtree) never burn a valid proof — matching create_repo's verify/consume split. - Add #[sqlx::test] coverage for the single-use ledger that the gate's anti-replay value depends on: consume_proof_jti (first-use vs replay vs distinct jti) and sweep_expired_proofs (only expired rows removed, unexpired spent proofs still block replays). - Return 403 Forbidden (was 401) for IcaptchaProofRequired: the caller is authenticated but forbidden without a valid proof. The distinct icaptcha_proof_required code is unchanged. - Recommend pinning ICAPTCHA_PUBKEY in production in .env.example to avoid the startup fetch dependency. The two shadow-mode review comments were already resolved by the earlier verify/consume refactor (decide/verify are IO-free; check_proof_jti gone). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>	2026-06-30 10:58:08 +08:00
beardthelion	828dd279a2	fix(node): gate repo-listing and stats surfaces on visibility (#97, #99, #101, #104) (#111) ... * fix(node): NFC-normalize visibility matcher to close NFC/NFD under-withholding (#101) A deny rule authored in NFC byte-compared unequal to a path committed in NFD (or vice versa), so blob_paths/withheld_blob_oids failed to classify the blob and it shipped in cleartext on the replication/pack path. Normalize both the glob prefix and the candidate path to NFC at the single matcher seam (glob_matches + specificity); NFC not NFKC so compatibility forms are not folded into distinct paths. Live serve is unaffected (git resolves byte-exact; the gate only becomes more restrictive). Adds a matcher unit test and a replication-path integration test with the variant byte inside the rule-covered directory name. * fix(node): fail closed on the full-scan pin path to stop dangling-blob leak (#99) The withheld set is computed over reachable objects (rev-list --all + HEAD), but the full-scan pin fallback (cat-file --batch-all-objects) includes dangling objects the reachable walk never classified. Subtracting the reachable-only withheld set therefore could not catch a private blob orphaned by a force-push/amend, which pinned to IPFS/Pinata in cleartext. Invert the default for blobs on the full-scan path: a candidate replicates only if it is a non-blob (commits/trees are structural) or a reachable, visibility-allowed blob; anything else (a dangling blob, or a withheld one) is dropped. The delta path keeps the cheaper reachable-only subtraction since delta candidates are always reachable, so no extra walk on the hot path. Adds list_all_objects_with_type/all_blob_oids (typed enumeration), replicable_blob_set + replicable_objects_fail_closed, and threads a full_scan flag through resolve_candidates_for_push. Pin functions now take a pre-filtered object list. Regression tests: dangling blob excluded end-to-end, fail-closed unit semantics, and the all-blob universe includes dangling + excludes non-blobs. * fix(node): gate repo-listing surfaces on visibility to stop private-repo enumeration (#97) list_repos, list_federated_repos, and the GraphQL repos query returned every repo row with no visibility check, so an unauthenticated caller could enumerate private repos' name, owner, description, and clone URL — and X-Total-Count leaked the private-repo count even when rows were filtered. Each surface now keeps a row only when visibility_check at "/" allows the caller, the same decision the per-repo content endpoints make — not a bare is_public filter, which would diverge for is_public=false-with-root-reader and is_public=true-with-root-deny. The "/" decision depends on owner short/full-DID matching and JSON reader-DID membership, so it is applied in Rust over an over-fetched set rather than pushed into SQL; the paged path derives X-Total-Count from the filtered set (dropping the SQL window count) and paginates after filtering, so neither the page nor the count leaks. Adds a batch root-rule query (list_visibility_rules_for_repos) to avoid N+1, and converts list_all_repos_paged into list_all_repos_deduped (mirror dedup preserved, pagination moved to Rust). Tests: anonymous hides private repo + count, owner sees own private repo, authorized root-reader sees an is_public=false repo (proving the visibility_check path, not is_public), and federated listing hides private from anonymous. * fix(review): share the listing visibility seam, extract fail-closed pin helper, add listing tests Code-review follow-up on the VIS-subtree fixes (no behavior change to the three shipped fixes; all confirmed sound by review): - DRY the '/' listing gate into one shared visibility::listable_at_root used by list_repos, list_federated_repos, and the GraphQL repos query, so the three surfaces enforce one rule instead of three drifting copies (enforce-shared-rule-on-every-reader-path). - Extract the full-scan fail-closed pin block into fail_closed_full_scan_objects, mirroring replication_withheld_set's degraded-path shape; drop the duplicated comment and the per-site no_rules sentinel (use &[]). - Add the three listing tests the review flagged as missing: anonymous GraphQL repos hides a private repo, the paged X-Total-Count path excludes the private count (the KTD2 exploit shape), and an is_public=true repo under a root deny is not listed (proves the gate is visibility_check, not a bare is_public filter). * fix(review): route the last inline root-visibility check through listable_at_root Round-2 review follow-up. replication_withheld_set still made the announce decision with an inline visibility_check(.., "/") == Allow — the fourth copy of the listing gate the seam refactor was meant to collapse. Route it through crate::visibility::listable_at_root (caller is always None, the anonymous replication audience), so every reader of the '/' decision now shares one seam. Also drop an em dash from the fail_closed_full_scan_objects doc comment. * fix(node): gate the /api/v1/stats repos count through visibility to close the count oracle (#104) The stats endpoint returned count_repos_deduped(): an unfiltered, unauthenticated count of every logical repo including is_public=false and mode-A hide-existence repos. A polling observer could detect that a hidden repo was created (N to N+1), the exact existence signal mode-A suppresses everywhere else. Count only the repos an anonymous caller could list: over-fetch the deduped set, batch-load visibility rules, and keep rows that pass listable_at_root(.., None), mirroring the listing seam in api/repos.rs. The caller is always None (meta_routes carries no auth layer). Fail closed: any DB error collapses the count to 0, since an under-count cannot leak existence. count_repos_deduped is retained as the tested reference for the DEDUP_CTE dedup count (its tests pin the CASE the live list paths share); it has no production caller after this change and is allowed dead outside tests. Tests: bare-private (no-rule branch), hide-existence mode-A with both repos is_public=true (the Some(rule) branch), public-under-root-deny, list-parity, sibling-fields-preserved, and empty-DB. * test(review): add listing visibility regression guards (#97) Three gaps the review flagged as uncovered: - owner-filtered listing (?owner=) still hides a private repo and its count from anonymous (a distinct SQL bind branch from the unfiltered path). - offset past the visible set returns an empty page while X-Total-Count stays the full visible total (guards against deriving the total from the cut page). - a logical repo present as both a canonical row (with a root-deny rule) and a gossip mirror row stays hidden: pins that the DEDUP_CTE picks the canonical survivor so the batch rule lookup finds the deny. If dedup ever picked the mirror (slash-form id, no rule) the gate would fall back to is_public and leak. * fix(review): address CodeRabbit feedback on #111 - visibility_pack NFC/NFD test: accept a SHA-1 or SHA-256 object id (40 | 64) instead of hardcoding 40, matching the fixture guard later in the file, so the test is not SHA-1-only. - federated listing test: also assert the response `count` reflects only the visible repos, guarding against a regression to the pre-filter total. - add an authenticated-caller GraphQL test: an owner sees their own private repo via `repos`, covering the resolver's caller-DID path that the anonymous-only test did not exercise. - stats: count via the no-stars `list_all_repos_deduped()` (same DEDUP_CTE) instead of the stars-joined variant, since the count never needs stars. * fix(review): match owner filter to did_matches for bare-owner mirror rows (#111) Addresses jatmn's P2. The shared listing CTE filtered owners with `owner_did = $1 OR owner_did LIKE '%:' || $1`, so a full `did:key:z...` query did not match a mirror-only row stored with the bare owner `z...`. #97 routed the no-limit owner-filtered path (used by `gl repo list`) through this SQL predicate, regressing the full-DID-against-bare-mirror direction that `crate::api::did_matches` handled in the old Rust path. Normalize the bound owner to its did:key short form and compare it against the row's owner key using the same CASE the dedup grouping already applies, so full and short forms match symmetrically and a non-key DID still matches only exactly. The no-arg `list_all_repos_deduped()` binds NULL and is unaffected. Regression test: a bare-owner mirror-only row is returned when queried by both the full `did🔑` form and the bare short form. Confirmed RED (test fails) before the fix.	2026-06-30 08:30:32 +08:00
beardthelion	636d3abe17	chore(deps): bump tar to 0.4.46 and rand to 0.9.3 to clear advisories (#105) ... tar 0.4.45 had a PAX header desynchronization issue (GHSA-3pv8-6f4r-ffg2, fixed in 0.4.46); rand 0.9.2 was unsound with a custom logger using rand::rng() (GHSA-cq8v-f236-94qc, fixed in 0.9.3). Both resolve as lockfile-only bumps with no manifest change. Build and cargo audit pass. lru 0.12.5 (GHSA-rhfx-m35p-ff5j) stays pinned by aws-sdk-s3 (lru ^0.12.2) and the hickory advisories remain accepted risk per .cargo/audit.toml (#76).	2026-06-26 10:32:09 +08:00
beardthelion	2d4105e479	chore(deps): bump quinn-proto 0.11.14 -> 0.11.15 (RUSTSEC-2026-0185) (#83) ... quinn-proto 0.11.14 (pulled transitively via libp2p's QUIC transport) is flagged by RUSTSEC-2026-0185. 0.11.15 is a semver-compatible patch that clears it; cargo audit passes clean after the bump. Lockfile-only, no manifest or code change, so it carries no ignore entry. Repo-wide: unblocks cargo audit on main and every open branch.	2026-06-23 11:39:18 +08:00
beardthelion	803d83efdb	fix(node): reap leaked git child processes (#53) (#61) ... * fix(docker): reap orphan processes via tini + init, cap pids The node runs as PID 1 in the container and never reaps reparented orphans, so git grandchildren (e.g. pack-objects left behind when a served clone disconnects) accumulate as zombies until fork() fails with EAGAIN. Run under tini and set compose init: true so reparented orphans are reaped, and add pids_limit as a blast-radius cap. Refs #53 * fix(node): reap leaked git child processes (#53) Serving git over smart-HTTP could leak zombie processes that, over weeks, exhaust the PID table until fork() fails with EAGAIN and all git operations break until restart. The serve path (run_git_service) now runs git in its own process group and SIGKILLs that group when the request future is dropped (client disconnect) or returns early, so git and its pack-objects child are torn down together instead of orphaning the grandchild to PID 1 as a zombie. A drop guard, disarmed once the request completes cleanly, owns this teardown. create_issue and build_filtered_pack spawned a std Child and dropped it unwaited if the stdin write failed (and build_filtered_pack could panic on a missing stdin handle). Both now always wait the child before surfacing any error, so the failure path cannot leak. Adds libc for the group-kill syscall and three regression tests covering direct-child kill, grandchild reaping via the group, and the disarmed no-kill path. Refs #53 * fix(review): reap-then-disarm on serve-path errors; tini/comment nits Address code-review findings on the #53 fix: - run_git_service no longer early-returns on a stdin-write error. It captures the write result, always reaps the child, then disarms the group guard before surfacing the error. Previously a write/wait error path could drop the still-armed guard after the child was already reaped, so the group SIGKILL could in theory land on a reused pgid. (correctness, reliability, adversarial all flagged this region.) - Drop tini's -g flag: the node manages its own children and graceful shutdown, so group-wide signalling would only disturb in-flight git helpers on shutdown. - Correct the SAFETY comment (kill(2) is not relevant to async-signal-safety here) and the alive() test-helper comment (EPERM does not read as alive). * fix(node): SIGTERM (not SIGKILL) the served-git group on disconnect SIGKILL gave git no chance to run its signal cleanup, so an aborted receive-pack could leave a stale .git/*.lock that blocks the next push. SIGTERM lets git remove its lock files before exiting. Signalling the whole process group still reaches pack-objects directly, so the grandchild is terminated rather than orphaned, and a single immediate signal avoids any delayed-kill pid-reuse window. Refs #53 * docs(node): correct stale SIGKILL comments to SIGTERM in served-git teardown	2026-06-23 10:10:17 +08:00
beardthelion	7533b74f79	ci: harden PR pipeline (audit, MSRV, beta matrix, release + docker smoke) (#57) ... * ci: harden PR pipeline (audit, MSRV, release build, beta matrix, docker smoke) Restructure the single stable-only fmt+clippy+test job into separate jobs: fmt+clippy (stable), a test matrix on stable+beta (beta non-blocking), build --release, cargo audit, an MSRV check pinned to Rust 1.91, and a Docker build smoke test mirroring the release workflow. Add concurrency cancellation for superseded PR runs and per-job timeouts. Declare rust-version = "1.91" in [workspace.package] and inherit it in every member crate so the stated MSRV is a real, CI-enforced contract. * ci: disable credential persistence on checkout steps Set persist-credentials: false on all six actions/checkout steps. These jobs run untrusted PR code via cargo and docker build, and checkout's default leaves the GITHUB_TOKEN in the local git config where that code could read it. None of the jobs push or otherwise need git credentials. * fix(deps): bump rustls-webpki to 0.103.13 Clears three advisories flagged by the new cargo audit job: a reachable panic in CRL parsing and two name-constraint bypasses (wildcard and URI). Semver-compatible patch, lockfile only, no manifest or code change. cargo also corrects a stale lockfile reference while rewriting Cargo.lock: data-encoding-macro-internal 0.1.17 (a build-time macro crate) requires syn 1.x, and its dependency entry is re-pinned from syn 2.0.117 to the 1.0.109 it actually resolves to. Unrelated to the bump, unavoidable when cargo touches the lock, and the more-correct state. * ci(audit): suppress no-fix advisories with justification and a re-check The cargo audit job stays hard-fail. The remaining three advisories have no available upstream fix, so they are suppressed in .cargo/audit.toml (the location cargo-audit actually reads; a repo-root audit.toml is not read), each with an inline rationale and removal condition: - RUSTSEC-2026-0118/0119 (hickory-proto 0.25.2, via libp2p-dns 0.44): reachable, since the node wraps QUIC in the system DNS resolver. No fix until libp2p-dns ships hickory 0.26. Accepted, reachable risk. - RUSTSEC-2023-0071 (rsa Marvin): in the lockfile via sqlx's unconditional sqlx-mysql, but not linked (sqlx is postgres-only), so no RSA oracle exists; no upstream fix regardless. Two controls keep the suppression honest. The PR audit job echoes the active ignore list to the job summary, so a green check is not read as advisory-clean. A weekly scheduled job re-runs cargo audit without the ignores for visibility and hard-fails if hickory-proto moves off 0.25.x while the ignores remain, so the suppression cannot silently outlive the upstream fix. * ci(audit): reference tracking issue #76 in the hickory ignores * ci(audit): treat hickory-proto removal as drift too The scheduled drift guard only failed when hickory-proto was present and off 0.25.x, so removing it from Cargo.lock entirely left the RUSTSEC-2026-0118 /0119 ignores in place with the guard still passing. Treat an absent version as drift as well, so dead ignore entries are caught whether the dependency is bumped past 0.25.x or removed.	2026-06-22 19:02:38 +08:00
beardthelionandCommandCodeBot	5ff7af84fa	feat: encrypted replication for private subtrees (B1/B2/B3) for #18 (#36) ... * feat(core): ed25519 to x25519 key conversion for envelope crypto * feat(core): seal/open per-blob encryption envelopes * feat(node): resolve per-blob encryption recipients (least-privilege) * feat(node): encrypted_blobs table and recipient-scoped queries * feat(node): encrypt-then-pin withheld blobs at push (IPFS) At the push chokepoint, after pinning withheld objects, resolve each withheld blob's recipient DIDs and seal it to their Ed25519 keys with seal_blob, pinning the ciphertext to IPFS and recording it in encrypted_blobs. Best-effort per blob: failures are logged and skipped, never pinned in plaintext. Pinata replication is unchanged; B1 encrypts to IPFS only. Adds ed25519-dalek as a direct dependency of gitlawb-node (it was only declared in the workspace Cargo.toml). * feat(node): authenticated discovery and fetch for encrypted blobs * feat(gl): transparent recovery of authorized encrypted blobs on clone * style: cargo fmt * fix(node): re-seal encrypted blob when recipient set changes Skip re-pinning only when an existing envelope already covers exactly the current recipients. A reader added to a rule after the first pin now gets a re-seal on the next push instead of being permanently locked out. Reader removal stays non-retroactive (the old envelope is already public). * feat(node): unscoped encrypted-blob listing for replication * feat(node): encrypted-blobs/replicate endpoint for peer mirrors * feat(node): route encrypted-blobs/replicate under git_read_routes * feat(node): peer mirrors replicate encrypted withheld blobs (Option B2) * feat(node): anchor_encrypted_manifest for Option B3 Arweave manifests * feat(node): encrypt_and_pin returns the per-push sealed delta * feat(node): anchor encrypted-blob manifest on push (Option B3) * feat(gl): Arweave/IPFS gateway recovery for encrypted blobs (Option B3) * feat(gl): transparent Arweave fallback recovery on clone (Option B3) * style: cargo fmt * fix(gl): bound Arweave recovery gateway requests with a 30s timeout * test(gl): read-path recovery tests for Arweave fallback; quiet promisor present-check Add two hermetic integration tests for recover_from_arweave that drive the full read path over mocked Arweave GraphQL + IPFS gateways: discover the manifest, fetch it, fetch the envelope, decrypt, and install the withheld blob. One covers an authorized recipient (blob installed), the other a non-recipient (nothing recovered). Both simulate origin death by removing the promisor remote and enable uploadpack.allowFilter so the blob is truly withheld over file://. Also harden the local presence check in recover_from_arweave with GIT_NO_LAZY_FETCH=1 and .output() so the expected 'missing object' case does not trigger a wasted promisor fetch or leak git stderr to the user. * fix: surface corrupt recipients JSON and silent recovery I/O failures db: parse_recipients now propagates a descriptive error instead of defaulting corrupt recipients JSON to an empty list, which would have denied authorized readers and handed peers incomplete metadata. gl: clone recovery now warns when the sparse-checkout file cannot be read or written, or when the post-recovery checkout fails, instead of silently discarding those errors and claiming files were recovered. * feat(core): blind recipient identities in withheld-blob envelopes Envelope v2 drops the cleartext recipient public key (kid) from each wrapped-key header entry, so a party holding the public IPFS/Arweave copy can no longer enumerate who is authorized to decrypt a withheld blob. The version is bumped to 2 and v1 envelopes are rejected. open_blob now selects the reader's entry by trial decryption (the AEAD tag authenticates exactly one entry) instead of matching on the public key. Recipient count is still visible; identity is not. Scope is envelope-only, the node DB recipients column and peer replication metadata are unchanged. Co-authored-by: CommandCodeBot <[email protected]> * fix(core): reject malformed envelope nonces instead of panicking open_blob fed attacker-controlled envelopes to GenericArray::from_slice and XNonce::from_slice, which panic on a wrong-length input. Validate both the per-recipient box nonce and the body nonce to 24 bytes before use: skip a recipient entry whose nonce is malformed, and return an error for a malformed body nonce, so the public recovery path surfaces an error rather than panicking. * feat(node): blind recipient identities on the B2 replication surface The encrypted-blobs/replicate endpoint shipped every blob's full recipient DID list to mirrors, which persisted it, so any mirroring peer learned the reader set. The v2 envelope blinding already removed recipient public keys from the pinned envelopes, so the comment justifying this (DIDs are already public) was no longer true. /replicate now returns {oid, cid} only. Mirrors detect a re-seal by the CID changing (the OID is stable across re-seals) instead of comparing recipient sets, and store no recipient identities. Origin-side authz and the at-rest recipients column are unchanged; this blinds only the peer-facing surface. * feat(node): stop anchoring recipient identities to Arweave The B3 encrypted-blob manifest anchored {oid, cid, recipients} to Arweave, a permanent public record of every blob's reader set. The v2 envelope blinding already removed recipient keys from the pinned envelopes, so the comment justifying this (recipient DIDs are already public) was no longer true. The manifest now anchors {oid, cid} only. The gl reader already ignores the recipients field (it recovers by trial decryption), so no reader changes. --------- Co-authored-by: CommandCodeBot <[email protected]>	2026-06-19 22:48:33 +08:00
Kevin CodexandClaude Fable 5	c7df6cad20	Fix/backport prod fixes (#39) ... * fix: backport production fixes from monorepo Three fixes that landed on the production node but never made it here: - trigger_sync: 30s timeout with the body read inside it (was 5s covering headers only — large unpaginated repo lists from canonical nodes and transpacific peers aborted mid-body), plus distinct logging for non-2xx vs timeout - announce: reject self-announcements by public URL or own DID; complements the existing boot-time prune_self_peers so self-loop rows never enter the peers table in the first place - list_all_repos_paged: report MAX(updated_at) across each logical repo group instead of the canonical row's own value — gossip pushes touch only the mirror row, so canonical timestamps go stale Monorepo refs: 8c2fe1b, c1dc33e, ef21c75. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(p2p): dual-stack QUIC listen + DNS multiaddr dialing for Fly 6PN Backports the monorepo TCP-era p2p fixes (9f875b6, 267d371) adapted to the QUIC transport: - listen on /ip6/:: as well as /ip4/0.0.0.0 — Fly's 6PN inter-app network is IPv6-only (<app>.internal resolves to AAAA records), so without an IPv6 socket peers on the private network can't reach us - wrap the QUIC transport in libp2p-dns so bootstrap multiaddrs can use /dns6/<app>.internal — dialing peers through the public anycast edge breaks the handshake when the proxy closes the connection mid-stream Co-Authored-By: Claude Fable 5 <[email protected]> * fix(sync): HTTP notify records received_ref_updates like the gossip path A push propagated via the /api/v1/sync/notify HTTP fallback replicated the repo but left no trace in received_ref_updates — only the libp2p gossip path recorded it, so /api/v1/events/ref-updates went blind whenever the mesh wasn't delivering. Insert the same record from the notify handler, with optional provenance fields (pusher_did, old_sha, timestamp, cert_id) that new senders already include. Monorepo ref: 087eeac. Co-Authored-By: Claude Fable 5 <[email protected]> --------- Co-authored-by: Claude Fable 5 <[email protected]>	2026-06-18 21:36:11 +08:00
Vasanth TandClaude Opus 4.8	2ce4da9cc5	feat(node): graceful shutdown + Prometheus metrics endpoint (#22) ... * feat(db): versioned schema migrations with idempotent backfill Replace the inline &str SQL array that re-runs on every node startup with a versioned migration system. Each migration is recorded in a new schema_migrations table and applied at most once per node, inside a single transaction. For nodes upgrading from a pre-migration-versioning build, the canonical `repos` table is used as a signal to mark v1 as already applied without re-running its ~140 statements — so existing operators see zero behavior change on first restart after this commit. Closes the gap called out in docs/OSS-READINESS-AUDIT.md:78. - Adds Db::migration_status() returning applied (version, name, applied_at) - Adds 6 unit tests validating the static migration catalogue (versions strictly increasing, names distinct, bodies non-empty, v1 name locked to initial_schema) - cargo fmt + clippy -D warnings + cargo test --workspace all clean * fix(db): make legacy migration backfill safe and lock-guarded Address two robustness gaps in the v1 migration runner on the live network: - Remove the "repos table present => v1 complete" backfill short-circuit. It assumed every existing node already had the full current schema; a node that was behind would be marked v1-applied while still missing newer tables or columns. Every v1 statement is idempotent (CREATE TABLE/INDEX IF NOT EXISTS, ADD COLUMN IF NOT EXISTS), so legacy installs now simply run v1 once: existing objects are no-ops, missing ones get created. - Guard the whole runner with a Postgres advisory lock so two instances against the same database (blue/green or rolling deploy) can't race to apply the same migration and trip the schema_migrations primary key. The lock is released explicitly, and automatically if the connection drops. Also document that per-migration transactions preclude CREATE INDEX CONCURRENTLY in future migrations. Co-Authored-By: Claude Opus 4.8 <[email protected]> * feat(node): graceful shutdown + Prometheus metrics endpoint Two operational-safety changes that the live network needs: 1) Graceful shutdown. A process-wide tokio::sync::watch::Sender<bool> in AppState is flipped on SIGINT (all platforms) or SIGTERM (Unix). Every long-lived loop now selects on the shutdown arm: * axum server (with_graceful_shutdown — drains in-flight) * libp2p swarm (drops Swarm, closes connections) * gossip task (exits between peer announces) * sync worker (exits between batches) * operator heartbeat loop * rate-limit cleanup loop * peer-count metrics poller * the deferred DID-record publish task New GITLAWB_SHUTDOWN_GRACE_SECS (default 30s) controls how long axum waits for in-flight requests before returning. 2) Prometheus /metrics endpoint. New metrics module exposes: * gitlawb_info{version, did} (constant gauge = 1) * gitlawb_pushes_total{repo} (counter) * gitlawb_fetches_total{repo} (counter) * gitlawb_auth_successes_total{route} (counter, helper) * gitlawb_auth_failures_total{route,reason} (counter, helper) * gitlawb_sync_queue_processed_total{status} (counter) * gitlawb_webhook_deliveries_total{result} (counter) * gitlawb_pack_size_bytes (histogram) * gitlawb_peers_connected (gauge) Opt-in via GITLAWB_METRICS_ADDR (e.g. 127.0.0.1:9091). The endpoint is on a separate listener so the public port stays unexposed; bind to localhost or a private interface. 3) Metric instrumentation hooks in api/repos.rs (push/fetch), webhooks.rs (delivery outcomes), and sync.rs (per-item status). The auth helpers are defined but not yet wired — that's a focused follow-up. Tests: * 3 new metrics::tests::* — encode returns valid prometheus text, record_* helpers are no-ops before init(), encode() errors if init() was never called. * cargo fmt + clippy -D warnings + cargo test --workspace all clean. Closes the metrics and graceful-shutdown gaps in docs/OSS-READINESS-AUDIT.md:131 and docs/MAINTAINER-ROADMAP.md:35. --------- Co-authored-by: Claude Opus 4.8 <[email protected]>	2026-06-02 08:58:05 +08:00
Achille Wasque	924bccd8e5	feat(gitlawb-attest): External Attestation v1 for ref-update certs (#20) ... Adds an optional `attestations` field on ref-update certs plus a small crate to sign and verify them. An envelope with no attestations serializes to identical bytes as a bare cert, so nothing on the wire changes for nodes that don't opt in. Each attestation carries a `type` discriminator (`covenant/exec/v1`, `slsa/v1.0`, `sigstore/dsse/v1`, ...), an opaque payload, a `cert_hash` that binds it to one specific cert, a `did:key` signer, and a base64url ed25519 signature over a domain-separated JCS-encoded input. ## Wire shape cert_hash = SHA-256(JCS(cert_body \ {signatures, attestations})) encoded as lowercase hex. signing_input = b"gitlawb-attest-sig/v1\n" || JCS({type, payload, cert_hash}) sig = base64url-no-pad(Ed25519(signing_input)) The cert hash is reproducible across implementations because JCS pins key order, number formatting, and string escaping (RFC 8785). Lowercase hex is required on the wire: the JCS signing input includes `cert_hash` verbatim, so accepting mixed case would force every signer and verifier to normalize before computing the signing bytes — an easy spec rule to miss across language ports. The domain tag lives in the byte stream, not in the canonical JSON, so an attestation cannot be confused with a same-shape JCS document signed for a different protocol that uses the same Ed25519 key. Signers are `did:key` over Ed25519 with the multibase base58btc (`z`) prefix. Non-base58btc encodings of the same public key are rejected on verify so allowlists and signer-pinning policies stay consistent across peers. ## Verification `Registry` maps type to verifier. `Policy::AcceptKnown` (default) lets unknown types pass without trust so adoption stays incremental. `Policy::RequireAll` enforces a per-repo allowlist but stays lenient on unknown types in the batch — anyone can attach an attestation, so short-circuiting on an unrelated `attacker/spam/v1` would be a DoS vector. `Policy::RejectUnknown` is strict. `AttestedRefUpdateCert::verify_attestations(&Registry)` is the one-call convenience over `registry.verify_all(&env.attestations, env.cert_hash()?)`. ## Canonical test vectors Ed25519, JCS, and SHA-256 are all deterministic, so a fixed seed plus a fixed cert body produce exactly the same `cert_hash`, `signer` DID, and `sig` across implementations. `tests/canonical_vectors.rs` pins these values so a port to Go, JS, Python, or any other language has a concrete oracle to check against without reading Rust. If a vector drifts, that is a wire-protocol break. ## Tests 42 pass: 33 unit + 4 cross-crate integration against the real `gitlawb_core::cert::RefUpdateCert` + 4 canonical vector pins + 1 rustdoc quick-start doctest. `cargo fmt --all -- --check` clean. `cargo clippy --workspace --all-targets -- -D warnings` clean. `cargo test --workspace` green; the new crate breaks no existing suite. ## Not in this PR - Node integration: storage, GraphQL, register flow. - UI surfacing. - Trust-score weighting policy for typed attestations. - Rollout ordering: old nodes silently drop the new `attestations` field (`RefUpdateBody` does not set `deny_unknown_fields`); signers and verifiers roll out independently. - wasm / no_std: not targeted; ed25519-dalek and serde_json are std-only. ## Reference implementation End-to-end demo at open-covenant/covenant@64ec780, `agent-os/examples/gitlawb-attest-demo/` (`covenant/exec/v1`). Closes #7.	2026-05-31 10:05:28 +08:00
Vasanth T	0b056f3ad0	[codex] fix Dependabot Rust alerts (#15) ... * fix(deps): resolve dependabot rust alerts * docs: clarify dependabot validation	2026-05-28 16:44:05 +08:00
Kevin CodexandClaude Opus 4.7	14a1cdd656	chore: bump v0.3.9, fix all clippy warnings, enforce strict CI lint (#12) ... * chore: bump v0.3.9, fix all clippy warnings, enforce strict CI lint - Bump workspace version 0.3.8 → 0.3.9 - Fix 22 clippy warnings across 17 files: - Replace .last() with .next_back() on DoubleEndedIterators (8 instances) - Remove useless .into() conversions on anyhow::Error (3) - Remove needless borrows in gl init (3) - Replace map_or with is_some_and/is_none_or (3) - Collapse consecutive str::replace into char array pattern (2) - Change &PathBuf to &Path in function signatures (2) - Remove dead code: unused init_bare_repo function - Collapse if-let into outer match arm - Replace vec![...] with array literal - Introduce RecordAnchorInput struct (10 params → 1 struct) - Fix always-true boolean condition in gossip task guard - Promote clippy from advisory to strict (-D warnings) in CI Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * style: cargo fmt Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>	2026-05-27 10:28:14 +08:00
Kevin CodexandOpenClaude	6b9c5278d4	chore: initial public release ... Open-source release of the gitlawb node, CLI, and git remote helper. - gitlawb-node: Axum HTTP server with git smart-HTTP and DID auth - gl: command-line client (identity, repos, PRs, MCP server) - git-remote-gitlawb: git remote helper for gitlawb:// URLs - gitlawb-core: shared crypto primitives (DID, CID, HTTP sigs, UCAN) Dual licensed under MIT or Apache-2.0. Co-Authored-By: OpenClaude <[email protected]>	2026-04-29 16:34:27 +08:00