On Tue, Mar 03 2026, David Bremner wrote: > Anton Khirnov <[email protected]> writes: > >>> Maybe you explained this already, but, why do we need/want to involve >>> the shell? I assume there's a good reason not to just exec something >>> like we for hooks? >> >> We need some way of splitting the commandline into the argument list for >> evecve(), a shell is the obvious way of doing that; I suppose we could >> also make index.filter into a list option, IIRC I didn't know they >> existed when I decided to use the shell. It would complicate the related >> indexopts APIs though. >> > > Sorry, I've been meaning to respond to this in a more considered way, > but haven't found the time/spoons. Anyway I guess I have a (potentially > irrational) fear of the attack surface introduced by using the shell the > parse the command line of the filter program. Anton correctly points out > elsewhere that this command line is not input from email but explicitely > configured by the user. I'm feeling a bit out of my depth here assessing > how much risk there is (if any), so I've CCed a few people whose views > on security stuff (and/or shell stuff) I respect, in order to get a bit > more feedback (if possible).
I had a quick look to the changes - some things look somewhat complex so I'd have to take deeper look why some things are done. I hoped GIT_SSH_COMMAND would not use shell but it does -- but that uses Makefile-configured SHELL_PATH which is '/bin/sh' by default - still I'd recommend not use shell but go GIT_SSH path and just exec a program (have to look more of the usecase to consider a way to provide args if needed). Other thing is that glib2 which is used, provides some ways to exec programs and pipe IO. Using that could drop quite a few lines out of the change. Ah forgot to mention that I don't see security problem using shell there - just that it provides (marginally?) more footguns to the user (and execing /bin/sh -> /bin/bash (when not Debian) many times is slooower). Tomi _______________________________________________ notmuch mailing list -- [email protected] To unsubscribe send an email to [email protected]
