.gitbay/wiki/Architecture/10-Known-Gaps.org

 1#+title: Known gaps
 2
 3Open weaknesses. Issues on krz/gitbay are public; this page gives the
 4title and the consequence, not a reproduction. The current list is the
 5open issues labelled =security=:
 6https://gitbay.org/krz/gitbay/issues?label=security. The table below is
 7what the 2026-09-27 review found; remove a row when its issue closes.
 8
 9* Filed
10
11| Issue | Area             | Gap                                                                   | Severity |
12|-------+------------------+-----------------------------------------------------------------------+----------|
13| #259  | Recovery         | No restore has been exercised; the drill is written (Admin wiki) and not yet run | high |
14| #260  | CI network       | Builds share the runner's source address; no egress policy            | medium   |
15| #261  | Various          | Migration foreign-key check after commit; three web writes bypass dispatch; documentation drift | medium |
16| #297  | Credentials      | A browser session can mint tokens and keys that outlive it            | low      |
17| #298  | SSRF             | =repo import --from= fetches without an address check                 | medium   |
18
19* Not filed
20
21| Area  | Gap                                                                                                         | Severity |
22|-------+-------------------------------------------------------------------------------------------------------------+----------|
23| Audit | The hash chain is unkeyed, so whoever can write the database can edit a row and recompute every later hash; removing the newest audit rows, or writing new rows under their freed ids, needs no recomputing at all. Neither is detectable from the database; only comparing =gitbayd admin audit verify='s last id and hash with the daemon's journal shows it. Rows written by =gitbayd shell= (=ssh.mode = "system"=) and host admin commands have no journal copy, and the refusal caps are per process, so under that mode each connection counts separately | low |
24| Availability | Under =ssh.mode = "system"= each SSH session is a separate =gitbayd shell= process, so the pack-generation limit (=internal/packlimit=, #262) cannot count SSH clones across sessions; only HTTP and git:// share a budget there | low |
25| Availability | Pushes have no concurrency limit; =max_pack_bytes= bounds each one, not how many run at once | medium |
26| Availability | =repo download= (SSH, API) runs =git archive= outside the pack limit; only its two-minute deadline and 512 MiB cap bound it | low |
27| Availability | An HTTP or git:// client that disconnects while queued for a pack slot keeps its place until =pack_queue_wait= runs out; only SSH notices the disconnect | low |
28
29* Questions an auditor will ask that have no answer yet
30
31| Question                                                  | Status                                   |
32|-----------------------------------------------------------+------------------------------------------|
33| What is the measured recovery time?                       | unmeasured (#259)                        |
34| How many concurrent clones does the host sustain?         | unmeasured (#262)                        |
35| What can a build reach on the host's network?             | configuration inspected, reachability untested (#260) |
36| Have the collaboration features been used by independent users? | no; one human user, tests only     |