aboutsummaryrefslogtreecommitdiff
path: root/ssh_handle_receive_pack.go (follow)
Commit message (Collapse)AuthorAgeFilesLines
* *: Support subgroups via SQL recursionRunxi Yu7 days1-5/+3
|
* *: Replacing more := with varRunxi Yu9 days1-2/+1
|
* Add SPDX license headers to all Go filesRunxi Yu10 days1-0/+3
|
* ssh/recv: Check hooksPath before receiving packsRunxi Yu2025-02-201-0/+22
|
* hooks, ssh: Indicate URL of newly-created MRsRunxi Yu2025-02-201-1/+7
|
* ssh/recv, hooks: Create MRs on push, reject pushes to others' MRsRunxi Yu2025-02-191-2/+6
|
* ssh/recv, users, schema: Create pubkey_only usersRunxi Yu2025-02-191-2/+9
|
* ssh/recv: Rename access -> direct_accessRunxi Yu2025-02-191-8/+4
|
* ssh/recv, schema: Add repos.contrib_requirementsRunxi Yu2025-02-191-1/+22
|
* ssh/recv: Remove unused err_unauthorized_pushRunxi Yu2025-02-191-3/+0
|
* hooks: Use ssh stderr directly instead of going through hookRunxi Yu2025-02-191-2/+2
|
* *.go: Use lowercase error valuesRunxi Yu2025-02-191-1/+1
|
* *.go: Add some comments for docsRunxi Yu2025-02-181-7/+7
|
* hooks, etc.: Restructure concurrency and data flowRunxi Yu2025-02-171-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.
* ssh_handle_receive_pack.go: Move unauthorized rejectionRunxi Yu2025-02-171-4/+6
|
* ssh_handle_receive_pack.go: Allow pushes for nowRunxi Yu2025-02-171-1/+1
|
* ssh_handle_receive_pack.go: Rename c -> deployer_channelRunxi Yu2025-02-171-3/+3
|
* hooks, etc.: Authenticate hooks, and handle them in the spawning threadRunxi Yu2025-02-171-1/+36
|
* *_handle_*_pack.go: Pass env LINDENII_FORGE_HOOKS_SOCKET_PATHRunxi Yu2025-02-171-0/+2
|
* ssh_handle_receive_pack: Use system git-receive-packRunxi Yu2025-02-171-33/+18
|
* {ssh_*,acl}.go: Check ACL when receiving packsRunxi Yu2025-02-161-1/+8
|
* ssh_*: Pass pubkey to SSH handlersRunxi Yu2025-02-161-1/+1
|
* ssh_*: Use pure go-git SSH handling (receive and upload)Runxi Yu2025-02-161-0/+49