[Users] That won't work.

[Dragony]

On Tue, 13 Oct 2020 17:39:12 +0100 Jeremy Nicoll (jn.ml.clwm.729 at letterboxes.org) wrote:

>There's a refinement needed in the general case, if several parms 
>are to be passed and any can be empty, which is to prefix or 
>suffix each hex string with something so that even if the hex part
>is completely empty the script sees a placeholder.  So if eg one
>was passing three vars one might insert
>
> p1=hex1 p2=hex2 p3=hex3
>
>or just 
>
> p=hex1 p=hex2 p=hex3
>
>(ie no need to number them).  Then if hex2 was empty, the string 
>would be 
>
> p=hex1 p= p=hex3

Constructs like

|p{echo -n `echo '%t%c'|grep -o '[a-zA-Z0-9]*@domain.com'`}

Require the invocation of a shell and quoting %vars makes concatenating vars like '%t%c' not as easy as that anymore. I think its hard to implement a fix supporting constructs like above in a secure way. Considering that I doubt that many people are using |p anyway, I would just drop shell execution support completely and tell people to use a much simpler command syntax like:

|invoke_header(/your/tool) ;Invokes /your/tool and gives the mail header data to STDIN.

|invoke_pointer(/your/tool) ;Invokes /your/tool and gives the full path to the locally stored mail file as the first argument.

This has the following advantages:

1. Its secure. Claws can't do anything wrong with that. No shell is invoked.

2. The user can do his own business in his script. If he needs shell, then he can invoke the shell in his script. Thats his own risk then.

3. It doesn't give the possibility of a out-of-memory DOS attack. Some people want to parse the whole mail, but giving the whole mail to STDIN might lead to problems if that user receives a really big mail of >100 MB. Giving a pointer to the locally stored file makes the user responsible for taking care of his memory problems.

- Dragony