| 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 |
| Access |
Grants and parked profile about texts (profile_about_backfill) of deleted accounts and organizations, and deploy keys of deleted repositories, left by deletes before #306, are removed on upgrade and the "schema migrated" log line gives the counts. One whose id a later row had already taken is no longer an orphan and stays with that row; on gitbay.org the orphans found (two grants, one deploy key) name ids no later row had taken |
low |
| 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 |
| Availability |
Pushes have no concurrency limit; max_pack_bytes bounds each one, not how many run at once |
medium |
| Availability |
repo download (SSH, API) runs git archive outside the pack limit; only its two-minute deadline and 512 MiB cap bound it |
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 |