omar-polo
commented
1 year ago There isn't a clearly defined deadline for it, but I'd like to get it done by the end of the year.
it didn't aged well, did it?
Anyway, I've resurrected the work and I'm happy with the privsep improvements. Now we follow a fork+exec pattern, propagate the configuration to sub-processes via ipc and the imsg handling is fully asynchronous.
What remains in my todo list is: (for the time being)
- a privsep crypto engine. I need it.
listen onper virtual host.- improve logging (style, location, etc.)
- make fastcgi easier to use / configure and more flexible.
I've mentioned before in some issue and in private conversations but never said clearly (outside of commit messages): the next release of gmid will be 2.0 and have some breaking changes.
The master branch is currently the work-in-progress for the future 2.0 so use it at your own risk. The documentation is incomplete. For something stable and documented, please use the latest 1.8.X release (currently 1.8.4) that will keep to receive updates until 2.0 is out. Said that, if you want to help squashing out bugs you're encouraged to try the master.
My plan is to try fix all of the things that would require a breaking change in 2.0 to provide a stable interface again after.
The biggest change is an internal one, half of which is already been done: fixing privsep. We had an "executor" process that was some sort of hack to do all the nice things we can't do in a sandbox. The server process asked this "executor" to run CGI scripts, open network sockets for proxying and/or fastcgi. I wanted to get rid of this because it's a way to escape the sandbox, and this has been done. Now it's the server process that opens the network sockets and CGI script support has been removed (see d29a2ee2246e1b1b0c5222a823820e42422c894e, the alternative is to use FastCGI with for e.g. slowcgi-portable). The downside is that we loose the sandbox for the server process outside of OpenBSD.
The other half of the privsep issue is to make the internal process handling better. The configuration should be sent over imsg and the sub-processes spawned only once at startup. Imsg handling should be fully asynchronous.
Running as uid 0 and chroot should also probably be made mandatory, or at least enabled by default.
Another invasive, but less than the previous, change to do is to allow binding to specific ip/ports per vhost, and possibly multiple times. Each server block should have a
listen ondirective and the globalportone should be removed.The fastcgi support should be extended to allow setting and changing parameters more easily, and under the hood it would be nice to "batch" multiple fastcgi params instead of one-per-record. FastCGI multiplexing is really nice but probably won't be done in time for 2.0.
If there are other things that would require a breaking change, feel free to open an issue so they can be discussed before 2.0. There isn't a clearly defined deadline for it, but I'd like to get it done by the end of the year.
As always, patches are welcome! :)