Structurally fixing command injection bugs

[Vasilij Schneidermann <mail@vasilij.de>]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

I've come across a few recent bugfixes arising from the same underlying problem
recently:

- Command injection in etags via system(3): CVE-2022-45939
- Command injection in htmlfontify.el via `shell-command-to-string`
- Command injection in ruby-mode.el via `shell-command-to-string`

The issue is well-known: Passing user input containing shell control
characters to system(3) is dangerous. Quoting the argument strings is a
band-aid solution. The text-book solution is to avoid using the shell in
the first place whenever possible. Emacs even provides a convenient
function for this, `process-lines`. It does not use the shell, accepts
several argument strings, raises errors (rather than failing silently)
and returns its output as a list of lines, thereby removing the need for
removing the trailing newline.

I see several options for moving forward:

- Keep using `shell-command-to-string` and `shell-quote-argument`
- Migrate existing use of `shell-command-to-string` to `process-lines` 
- Come up with a different replacement working much like
  `process-lines`, but returning a string instead (I have no idea what
  an appropriate name would be, maybe `command-to-string`?)

PS: Where should I report analogous misuse of `shell-command-to-string`?
I cannot submit patches currently because I've changed employers and
need to renew copyright assignment, again (that would be the third time
already).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]