#+title: Known gaps Open weaknesses. Issues on krz/gitbay are public; this page gives the title and the consequence, not a reproduction. The current list is the open issues labelled =security=: https://gitbay.org/krz/gitbay/issues?label=security. The table below is what the 2026-09-27 review found; remove a row when its issue closes. * Filed | Issue | Area | Gap | Severity | |-------+------------------+-----------------------------------------------------------------------+----------| * Not filed | Area | Gap | Severity | |-------+-------------------------------------------------------------------------------------------------------------+----------| | 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 | | Availability | Under =ssh.mode = "system"= each SSH session is a separate =gitbayd shell= process, so the pack and push limits (=internal/packlimit=, #262, #308) cannot count SSH clones or pushes across sessions; only HTTP and git:// share a budget there | low | | Availability | A push holds its slot for at most =push_receive_timeout= (15m) before its pre-receive starts, and, once its pack has begun, at most =push_idle= (60s) with nothing moving either way. A client that trickles its pack and reconnects when cut can hold a slot per principal for up to the receive deadline each time; deploy keys multiply the per-principal share, bounded by =push_concurrency= | low | | 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 | * Questions an auditor will ask that have no answer yet | Question | Status | |-----------------------------------------------------------+------------------------------------------| | What is the measured recovery time? | 8m43s from the offsite copy to a clone, laptop drill 2026-09-29, no host provisioning (Admin wiki) | | How many concurrent clones does the host sustain? | unmeasured (#262) | | Have the collaboration features been used by independent users? | no; one human user, tests only |