Index | Thread | Search
Download raw body.
gotd(8) imported, and where this is going
I imported gotd(8) last night, after working on it whenever I found some spare time during the past couple of weeks. If you would like to help with further development of gotd, please keep reading. The commit message explains context: https://git.gameoftrees.org/gitweb/?p=got.git;a=commitdiff;h=13b2bc37 As implied in the commit message, this is nowhere near done. It is just an initial attempt at having a server code base we can start playing around with. While this code lives on the main branch now, and I will keep updating the devel/got port with releases from this branch, I will *not* ship a gotd binary package until we are confident that the design has settled and the code is ready for wider community testing. I recommend that -portable releases follow the same approach, i.e. ship the code but don't compile it by default. And provide a way to build it out of the got-portable.git repository for interested parties. Eventually, we should be confident that running gotd won't break anyone's repositories (as a rule of thumb, if you break or lose someone's repository just once, they will stop using your version control system). And we must be confident that running gotd won't expose an interesting attack surface, especially when serving anonymous fetches on the internet. In the long term, the more people can confidently run gotd servers for private or public small-scale use, the better the software will become. I believe this software fits into a niche which the native Git ecosystem, with all its focus on the web and big hosting, does not serve very well. We can take as much time as we need to get it done. There is no need to rush, no need to make promises, no need to ship it before we want to. As far as I'm concerned, we can keep iterating on this for years. What matters is the end result, not time-to-market (we are late already ;) Regarding the future: It is important to start on a regression test suite now, before we add many changes on top of the basic implementation. This will be my next step, and I would be happy to get help with this. If we can find a few people who want to write test cases in parallel, it can be done quickly. I received some questions and input from deraadt@, which is very helpful. I have never written a privsep daemon before, and this shows. There are some things the current design gets quite wrong. I am paraphrasing Theo's suggestions below. It might not be 100% what Theo had in mind, but this conversation is still fresh, and any misunderstandings on my part can be cleared up in further discussion. - gotsh(1) should not be required as a login shell. This has already been fixed on the main branch. It is now possible to invoke gotsh as git-receive-pack or git-upload-pack. Users who want to keep their regular login shell can drop gotsh under those names somewhere in $PATH where ssh can find them. - combining the "senfd" and "recvfd" pledge(2) promises is bad This happened because I went back-and-forth on fd passing during development. It should be possible to fix this by passing relevant fds differently. - authentication should not rely on gotd.sock path permissions alone There is currently no code which the legitimacy of anyone who is talking to the gotd unix socket. I've left this out for now because it is not required to develop basic Git functionality, but this issue is of great concern for multi-user systems. We will need a separate process which listens on the socket and rate-limits new connections. And a separate process which will allow/deny connections. My plan is to require allowed users/groups to be explicitly listed in the configuration file, on a per-repository basis to keep things simple (config file macros can prevent excessive repetition). - fork+exec needs to occur per session, not just once at startup Here is my evident lack of privsep/ASLR experience. If every session uses the same address space, any data leak becomes an oracle about address space layout for subsequent attempts. We will need to fork+exec per session, which ties in nicely with the authentication requirement above. After authentication, we could spawn a fresh instance of gotd and a corresponding reader or writer process to serve the session. This also solves my problem of wanting to run multiple readers/writers to serve clients in parallel, which is impossible in the initial implementation. - chroot is unnecessary on OpenBSD and requires root At startup, gotd needs root privileges to open its unix socket, and currently also to move forked reader/writer processes into a per-repository chroot. With on-demand fork+exec, putting new processes into a chroot will require root not just at start-up, but also at run-time. On OpenBSD we can use unveil as a root-less alternative. The current chroot mechanism will be moved to -portable, where the process which forks children for a new session will have to keep running as root, unless the target OS provides unveil or can somehow emulate what unveil achieves on OpenBSD.
gotd(8) imported, and where this is going