Parents and children of check-in [a41b410958]
|
2026-08-18
| ||
| 11:17 |
repo.list: filter, sort and page the listing
The front page rendered every repository unsorted and unbounded — the same shape that made the timeline unusable, and it is at 23 now. Adds a name filter, sort by name, recent activity or size, and a limit, with Total alongside Count so a page can say '5 of 23'. Sorting happens BEFORE the limit. The other order gives an arbitrary subset in the right sequence, which reads as correct and is not. Activity comes from the event table's index — one walk stopping at the first row — so the column that makes a forge listing worth reading costs nothing. Adds repo.get, so the settings page and the CLI stop scanning the whole listing to read one repository's settings. check-in: 4a3165db34 user: dmestas tags: trunk | |
| 11:06 |
repo: settings page, descriptions everywhere
repo.update replaces repo.visibility and applies a repository's settings whole — a settings form submits every field it manages, so partial-update semantics would only add a way for the two to disagree about what absent means. The CLI reads current settings before writing, so 'repo private' no longer blanks the description. A settings page at /r/{repo}/settings, admin-gated, and the description now appears on the repository itself rather than only in the listing: a reader arriving from a link otherwise sees nav and a file tree and no statement of what the project is. check-in: a41b410958 user: dmestas tags: trunk | |
| 10:54 |
repo: private repositories
Visibility on the registry, gated at every read path: pages, API, search, file reads and the sync endpoint all answer 404 for a repository the caller may not see. 404 and not 403 — a 403 confirms the repository exists, which is the one thing a private repository must not confirm. The listing filters by visibility too. A list that names a private repository has leaked it whatever the page then refuses to show. The gate lives in Deps.repoFor, where d.repo already resolved the store, so a new op cannot forget it. The API router now resolves identity for ANONYMOUS ops as well: a read op that never looks at credentials cannot tell a repository's own collaborators from strangers, and would lock them out of their own repository. Two faults found while verifying. Repositories named by --repo had no registry row, so taking one private updated nothing and reported success — a security control that claims to work while doing nothing. They are recorded now, and SetRepoVisibility refuses a name it does not hold. Second, the sync path was ungated: a private repository whose pages refuse anonymous readers while zit clone hands over every artifact is not private. Verified: anonymous and unprivileged accounts get 404 everywhere and a short list; a collaborator with read sees it; admins see everything. check-in: f88e97a9fd user: dmestas tags: trunk | |