aboutsummaryrefslogtreecommitdiff
path: root/ssh_handle_receive_pack.go (unfollow)
Commit message (Collapse)AuthorFilesLines
6 dayshooks, fedauth: Add basic federated authentication for git pushRunxi Yu1-18/+26
7 days*: Support subgroups via SQL recursionRunxi Yu1-5/+3
9 days*: Replacing more := with varRunxi Yu1-2/+1
10 daysAdd SPDX license headers to all Go filesRunxi Yu1-0/+3
2025-02-20ssh/recv: Check hooksPath before receiving packsRunxi Yu1-0/+22
2025-02-20hooks, ssh: Indicate URL of newly-created MRsRunxi Yu1-1/+7
2025-02-19ssh/recv, hooks: Create MRs on push, reject pushes to others' MRsRunxi Yu1-2/+6
2025-02-19ssh/recv, users, schema: Create pubkey_only usersRunxi Yu1-2/+9
2025-02-19ssh/recv: Rename access -> direct_accessRunxi Yu1-8/+4
2025-02-19ssh/recv, schema: Add repos.contrib_requirementsRunxi Yu1-1/+22
2025-02-19ssh/recv: Remove unused err_unauthorized_pushRunxi Yu1-3/+0
2025-02-19hooks: Use ssh stderr directly instead of going through hookRunxi Yu1-2/+2
2025-02-19*.go: Use lowercase error valuesRunxi Yu1-1/+1
2025-02-18*.go: Add some comments for docsRunxi Yu1-7/+7
2025-02-17hooks, etc.: Restructure concurrency and data flowRunxi Yu1-20/+13
Previously we accepted handler connections at hooks_handle and used a mess of channels and concurrent maps to let receive_pack handle the session. This doesn't work well because there are conditions where a push occurs but the hook is not called, e.g. when the destination branch is up to date. There is no reliable way of checking whether the subprocess is going to call the hook or not; it's technically possible to parse stderr but that interface is not guaranteed to be stable and IIRC has changed in the past). So receive_pack would be waiting on the channel to receive a hooks connection to handle but it'll never receive one, causing a deadlock. This entire thing was overengineered and was very prone to error. Here we let receive_pack put the cookie into the map, then start and wait for the subprocess to finish. When the hook actually runs and connects to its UNIX domain socket, the handler would check its cookie within the map. If the hook doesn't run, then nothing happens. The git-receive-pack subprocess blocks the execution of the SSH handler, and when git-receive-pack exists, the SSH handler (using a defer) deletes the cookie from the map. There may be caveats in signal handling or other cases that cause the cookie to be deleted from the map prematurely.
2025-02-17ssh_handle_receive_pack.go: Move unauthorized rejectionRunxi Yu1-4/+6
2025-02-17ssh_handle_receive_pack.go: Allow pushes for nowRunxi Yu1-1/+1
2025-02-17ssh_handle_receive_pack.go: Rename c -> deployer_channelRunxi Yu1-3/+3
2025-02-17hooks, etc.: Authenticate hooks, and handle them in the spawning threadRunxi Yu1-1/+36
2025-02-17*_handle_*_pack.go: Pass env LINDENII_FORGE_HOOKS_SOCKET_PATHRunxi Yu1-0/+2
2025-02-17ssh_handle_receive_pack: Use system git-receive-packRunxi Yu1-33/+18
2025-02-16{ssh_*,acl}.go: Check ACL when receiving packsRunxi Yu1-1/+8
2025-02-16ssh_*: Pass pubkey to SSH handlersRunxi Yu1-1/+1
2025-02-16ssh_*: Use pure go-git SSH handling (receive and upload)Runxi Yu1-0/+49