Rather than hard-code assumptions into gitwrapper and gotd binaries, allow for some values to be overriden at compile time. This should help portability.

Reads (git clone) are working but writes (git push) run into an error

This enables gotd -- for now, this is opt-in at compile-time, via: ./configure --enable-gotd

We recommend that gotsh users should not have direct filesystem access to repositories served by gotd. Which means admins will be setting things up as follows if public read-access should be denied: chown _gotd /git chmod 700 /git su -m _gotd -c 'gotadmin init /git/repo.git" However, gitwrapper would error out when repositories listed in gotd.conf were inaccessible to the user invoking gitwrapper: git-upload-pack: /etc/gotd.conf:2: realpath /git/repo.git: Permission denied Make gitwrapper ignore such errors as they are expected in this situation. While here, add a PROC_GITWRAPPER process ID for use as a global variable parse.y can check while special-casing any specific behaviour required by gitwrapper. (The worse alternative would have been adding a new global variable to parse.y just to control the behaviour on realpath errors.) ok op@

make it opaque since it's unused outside of gotd.c. While here, drop the unused `nhelpers' field. ok/tweak stsp@

ok op@

Move gotd_auth_parseuid() from auth.c to parse.y as gotd_parseuid(), and remove auth.c from the list of source files required by gitwrapper.

Move gotd_find_uid_connection_limit() from listen.c into parse.y and remove listen.c from the list of source files required by gitwrapper.

ok op@

gotd still requires the config file, of course, but gitwrapper must treat is as optional and remain silent if the file cannot be found.

ok op@, tracey@ earlier version

Allow clients to run "got send -d" against gotd. Clients will send a zero-id as new id for a reference and, in the special but more common case of just deleting and not updating, no pack file will be sent. ok and tweaks by stsp@

The session process takes over the old state definitions under a new name ("session state"). The parent only needs to keep track of whether a client has been granted access, so it only uses two states: NEW, and ACCCESS_GRANTED which is set as soon as the auth process has granted repository access and before the session and repo_read/repo_write children are started. Because 'gotctl info' can no longer observe the session state remove support code for printing it. ok op@

The gotd parent process has lost access to client capabilities. Take the easy way out and remove related code. If needed, client capabilities can still be found in the debug log with 'gotd -v'. ok op, jamsek

The new session process is able to manipulate files in the repository and keeps track of the read/write client session state. The parent process now restricts its view of the filesystem to the absolute path stored in argv[0], and combines this with unveil "x" on this path. As a result the parent process can only re-exec itself. small tweaks + ok op@

Repository access is now controlled by access rules in gotd.conf, and concurrent connections to the gotd socket by local users are limited by the listen process. We should keep refining our anti-DoS measures in the future, but at least we have something in place now. ok jamsek, op

Allow administrators to tweak the default authentication and request timeouts if needed, and to tweak the limit of concurrent connections for specific user accounts. with several tweaks from and ok op@

For now the limit is set at compile-time. It will become configurable via gotd.conf soon. ok op@

The listen process now communicates the client UID/GID to the parent, and the auth process verifies this on behalf of the parent. This allows us to remove the "unix" pledge promise from the parent, removing parent access to syscalls such as listen() and accept() in the AF_UNIX domain. ok tracey@ op@

ok op@

ok op, jamsek

In the future, gotd will fork+exec new processes for each client connection. Using unveil instead of chroot avoids having to start such processes as root. The -portable version could use chroot(2) where no equivalent to unveil(2) exists. A future component which starts new processes will be isolated as a separate process, which could run as root in the -portable version. ok op@

ok op@

ok op@