3
26
Fork
You've already forked mere
1

Verify signatures for file:// repos declared in config.kdl #90

Merged
jhuntwork merged 1 commit from verify-local-repo-signature into main 2026年07月03日 16:44:21 +02:00

syncLocal() was a no-op: sync() on a local (file://) repo never
verified anything. Auto-discovered dev repos under /mere/dev/repo/
are safe because repo_sources.zig verifies before ever constructing a
RepoCache, but a file:// repo declared directly in config.kdl reached
this path with its own trusted_fingerprints configured and unchecked -
a repo.db signed by any key, or no key at all, would be trusted.

syncLocal now verifies the in-place repo.db/repo.db.sig against
trusted_fingerprints using the same verifyWithTrustedFingerprints path
remote sync already uses.

Two existing multi-repo tests (install.zig) had been signing a
differently-named db file (e.g. repo1.db) than the one Repository.init
actually reads from (the fixed repo.db/repo.db.sig filenames) - a
latent inconsistency invisible while local sync verified nothing.
Fixed both to sign the file that's actually read. Added a regression
test proving a local repo signed with an untrusted key is rejected;
verified it fails without the fix.

syncLocal() was a no-op: sync() on a local (file://) repo never verified anything. Auto-discovered dev repos under /mere/dev/repo/ are safe because repo_sources.zig verifies before ever constructing a RepoCache, but a file:// repo declared directly in config.kdl reached this path with its own trusted_fingerprints configured and unchecked - a repo.db signed by any key, or no key at all, would be trusted. syncLocal now verifies the in-place repo.db/repo.db.sig against trusted_fingerprints using the same verifyWithTrustedFingerprints path remote sync already uses. Two existing multi-repo tests (install.zig) had been signing a differently-named db file (e.g. repo1.db) than the one Repository.init actually reads from (the fixed repo.db/repo.db.sig filenames) - a latent inconsistency invisible while local sync verified nothing. Fixed both to sign the file that's actually read. Added a regression test proving a local repo signed with an untrusted key is rejected; verified it fails without the fix.
Verify signatures for file:// repos declared in config.kdl
All checks were successful
/ test (pull_request) Successful in 6m35s
0c29606496
syncLocal() was a no-op: sync() on a local (file://) repo never
verified anything. Auto-discovered dev repos under /mere/dev/repo/
are safe because repo_sources.zig verifies before ever constructing a
RepoCache, but a file:// repo declared directly in config.kdl reached
this path with its own trusted_fingerprints configured and unchecked -
a repo.db signed by any key, or no key at all, would be trusted.
syncLocal now verifies the in-place repo.db/repo.db.sig against
trusted_fingerprints using the same verifyWithTrustedFingerprints path
remote sync already uses.
Two existing multi-repo tests (install.zig) had been signing a
differently-named db file (e.g. repo1.db) than the one Repository.init
actually reads from (the fixed repo.db/repo.db.sig filenames) - a
latent inconsistency invisible while local sync verified nothing.
Fixed both to sign the file that's actually read. Added a regression
test proving a local repo signed with an untrusted key is rejected;
verified it fails without the fix.
jhuntwork deleted branch verify-local-repo-signature 2026年07月03日 16:44:22 +02:00
Sign in to join this conversation.
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
merelinux/mere!90
Reference in a new issue
merelinux/mere
No description provided.
Delete branch "verify-local-repo-signature"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?