On Fri, May 20, 2022 at 04:20:55PM +1000, raf <m...@raf.org> wrote: > On Thu, May 19, 2022 at 12:05:59PM -0700, "Kevin J. McCarthy" <ke...@8t8.us> > wrote: > > > On Thu, May 19, 2022 at 01:12:31PM -0500, Derek Martin wrote: > > > On Thu, May 19, 2022 at 11:06:38AM -0700, Kevin J. McCarthy wrote: > > > > Sorry, this isn't currently possible in Mutt. The $sendmail variable is > > > > handled specially: it's tokenized by space and invoked directly via > > > > execvp(). So you won't be able to use arguments with spaces in them > > > > inside > > > > the variable, or any shell quoting since it doesn't pass through the > > > > shell. > > > > > > Couldn't you do something like the following? > > > > > > set my_sendmail=/usr/bin/msmtp [...] --passwordeval=$(gpg --no-tty -q -d > > > ~/.user.gpg)" > > > set sendmail=$my_sendmail > > > > > > Don't know, haven't tried it, but as long as the first thing evaluates > > > to something that sendmail's tokenization can handle, seems like it > > > should work... > > > > $sendmail goes through muttrc evaluation like other variables, but when > > invoked to send an email, the resulting string is tokenized by space, '--' > > and various arguments inserted as needed, and then passed to execvp(). > > > > Yes, this should be documented and I'll add it to the config option shortly. > > > > I don't know why it was written this way, perhaps some security concerns, > > but I agree that it's surprising. > > > > -- > > Kevin J. McCarthy > > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA > > I think the reason would be that mutt is modifying the > command, not just executing it. It's modifying a > command in a complex external language that it can't > parse by itself unless it imposes very strict > limitations on the allowable syntax of the command. > I don't think it's a security decision. It's just > necessary. How would mutt know how to modify > sendmail="blah1 | blah2 | blah3" ? > > I think this limitation should be documented, but not > fixed. It could be fixed by adding something like % > interpolation placeholders for the things that are > added. But that might break existing commands that > contain %. Maybe # would be a better choice. But it's > still a bad choice. It requires the user to know and > use even more notation. > > An elegant solution already exists. Put complex shell > commands in a file and mutt only needs to see its name. > > But users need to be told when they are required to do > that. So in addition to documenting the limitation, a > new error message when the evaluated $sendmail contains > any (non-space) shell meta-characters would be helpful. > That's a clear indication that the user is expecting > shell parsing that isn't going to happen.
Actually, the documentation already did state that $sendmail is a "program and arguments". So it was probably fine. It just didn't explicitly state that it's not an arbitrary shell command. But I see that it's already been improved. I'm sending a patch that adds an error check for shell meta-characters when $sendmail is used. It might have been better to check right after reading .muttrc, but this seemed like a more natural place to put the code (i.e., right after the check that $sendmail exists). cheers, raf
