Viktor Dukhovni:
> On 16 Feb 2022, at 8:16 am, Wietse Venema <[email protected]> wrote:
>
> > postqueue -j | jq -r '
> > # See JSON OBJECT FORMAT section in the postqueue(1) manpage
> > select(.queue_name == "deferred")
> > | .queue_id
> > ' | postsuper -h -
>
> While we're on the topic of JSON output, FWIW, I am not convinced that
> the recent change to protect downstream consumers of JSON from
> non-printable content in "postqueue -j" output (which is robustly
> escaped in its JSON representation) was the right choice.
>
> 20211027
>
> Safety: the postqueue command now sanitizes strings before they
> are formatted as json output or legacy output. These outputs are
> piped into other programs that are run by administrative
> users. This closes a hypothetical opportunity for privilege
> escalation. Files: util/attr.h, util/attr_scan*.c,
> postqueue/showq_json.c, postqueue/showq_compat.c.
>
> IMHO any responsibility to handle unexpected string payloads falls
> squarely on the JSON consumer, not showq(8) or postqueue(1). Sure, use
> of "jq -r" exposes unescaped output and the user should be warned to
> expect the unexpected.
>
> Alternatively, perhaps there should be an option to turn off the safety
> net. Something like the '-J' option below (with appropriate
> documentation and warnings).
And what about non-json output?
Wietse
