Unnamed repository; edit this file 'description' to name the repository. https://upleb.uk/npub1tkq8unhsd5jqx6ueex5lcpsgknrpquxuk44ftpjlpm3ulaake7xs76txrw/ngit-grasp-mirror/atom?h=master 2026-04-10T16:42:35+00:00 2026-04-10T16:42:35+00:00 DanConwayDev DanConwayDev@protonmail.com 2026-04-10T16:42:35+00:00 urn:sha1:dfd20a39a7ddaea07103cac45d4d79bc7e6ce0d7 NIP-01 places no restriction on d tag characters and NIP-34 only recommends kebab-case without mandating it. Rejecting identifiers with whitespace or other URL-unsafe characters was therefore overly strict. The correct approach (per NIP-34 PR #2312 and GRASP-01) is to store identifiers verbatim on disk and percent-encode them when constructing URLs. The previous commit already handled the incoming direction (percent-decoding URL paths before filesystem lookup); this commit handles the outgoing direction and removes the validation restriction. Changes: - validate_identifier: drop whitespace rejection; only reject chars that are unsafe as filesystem directory names (/, \, null, . / ..) - git/mod.rs: add percent_encode() alongside percent_decode() - landing.rs: percent-encode identifier in nostr:// clone URL and gitworkshop link (also fixes a pre-existing bug where the clone URL displayed literal '{npub}' / '{identifier}' instead of the values) 2026-04-09T15:24:17+00:00 DanConwayDev DanConwayDev@protonmail.com 2026-04-09T15:24:17+00:00 urn:sha1:2d74b9ca69b3a1e0b9a2359c12cc2d1979fc6130 Two bugs allowed a repository announcement with a space-containing identifier ('kuboslopp by Shakespeare') to enter purgatory and create a bare repo on disk, but then fail to serve git data over HTTP. Bug 1 (serving): parse_git_url and parse_repo_url did not percent-decode the URL path before resolving the filesystem path. A client requesting /npub.../kuboslopp%20by%20Shakespeare.git/info/refs had the identifier extracted as 'kuboslopp%20by%20Shakespeare' (literal %20), which did not match the on-disk directory 'kuboslopp by Shakespeare.git'. Fix: add percent_decode() in src/git/mod.rs and apply it to the repo component in both parse_git_url and parse_repo_url. Bug 2 (validation): validate_announcement did not check that the identifier is safe as a filesystem path component and URL segment. Identifiers containing whitespace, path separators, null bytes, or reserved names (. / ..) should be rejected at acceptance time. Fix: add validate_identifier() in src/nostr/events.rs and call it from validate_announcement before any other policy checks. 2026-02-26T15:42:09+00:00 DanConwayDev DanConwayDev@protonmail.com 2026-02-26T15:42:09+00:00 urn:sha1:9d86cf15f0275ffeee4519bd054e3b61dc8992ac Fix pre-existing clippy lints: - &PathBuf -> &Path in audit_cleanup.rs - too_many_arguments on process_newly_available_git_data, process_purgatory_announcements, and HttpService::new - clone_on_copy for PublicKey (Copy type) in purgatory cleanup loop 2026-02-26T12:19:31+00:00 DanConwayDev DanConwayDev@protonmail.com 2026-02-26T12:19:06+00:00 urn:sha1:b13c6d924f7de5ff34405254b8bb21adf33c78c0 Previously push auth failures returned HTTP 403 which git clients display as a generic transport error. Now they return HTTP 200 with an ERR pkt-line containing the rejection reason (e.g. 'authorisation failed: No state events in purgatory'), which git displays directly. Remove GitError::Unauthorized as it is no longer used. GitError variants now represent only transport/infrastructure failures; app-level rejections use ERR pkt-line responses. 2026-02-24T11:39:55+00:00 DanConwayDev DanConwayDev@protonmail.com 2026-02-24T11:39:55+00:00 urn:sha1:aa40780d6f1710a386dcaa2e73730ba50634eaed Both were pub functions with no callers. Clippy doesn't flag dead pub items because the compiler treats them as potentially used by external crates - only private items trigger the dead_code lint. 2026-02-24T11:36:39+00:00 DanConwayDev DanConwayDev@protonmail.com 2026-02-24T11:36:39+00:00 urn:sha1:c31a313ccf781e54fa15942bc882c1b113d3f590 The old name was ambiguous - it wasn't clear whether purgatory was included or not. The two variants are now explicitly named: - fetch_repository_data_excluding_purgatory: DB only - fetch_repository_data_with_purgatory: DB + purgatory overlay SyncContext trait method also renamed to fetch_repository_data_with_purgatory to match the free function it delegates to. 2026-02-24T10:20:55+00:00 DanConwayDev DanConwayDev@protonmail.com 2026-02-24T10:20:55+00:00 urn:sha1:5efdf431a1481f6fb7a17190b62588b81c5b1e65 2026-02-24T09:19:02+00:00 DanConwayDev DanConwayDev@protonmail.com 2026-02-24T09:19:02+00:00 urn:sha1:0b9861e14f23cc615d33ebd8845a36b40516a8a5 When git data is fetched into owner A's repo and a state event for owner B is released from purgatory (copying OIDs from A's repo to B's repo via process_state_with_git_data), owner B's purgatory announcement was never promoted. process_purgatory_announcements only promotes the announcement for the owner derived from source_repo_path (owner A), so owner B's announcement stayed in purgatory with its 30-minute expiry timer running. 30 minutes later the cleanup task would soft-expire owner B's entry, deleting the bare repository even though the announcement had been effectively satisfied. Fix: after a state event is successfully saved to the database, iterate over all announcements in db_repo_data and promote any purgatory announcement for owners whose repos received OIDs via the copy (i.e. repos other than source_repo_path). 2026-02-23T15:20:59+00:00 DanConwayDev DanConwayDev@protonmail.com 2026-02-23T15:20:59+00:00 urn:sha1:113928aa84894ea8f65c247d9987527e792b32a9 2026-02-23T12:54:57+00:00 DanConwayDev DanConwayDev@protonmail.com 2026-02-23T12:54:57+00:00 urn:sha1:c3dedb7a5b527c3a3deb1e781aba9d562c6eb294 Per design doc decision #4: when git auth finds a matching state event in purgatory that authorizes a push, extend the announcement's expiry. The repo is actively receiving git data so the announcement should not expire prematurely. Also triggers revival of soft-expired announcements.