@@ -12,7 +12,9 @@ Tool parameters here refer only to those parameters that are not constrained by
Executing arbitrary user input is a signficant security risk and any design proposals **MUST** present a viable strategy to mitigate the risk of code injection.
Next to strategies of preventing the modification of essential arguments and mitigating code injection, proposed solutions need to balance the following constraints:
Provenance information on how exactly a given tool was called **MUST** be preserved.
Next to these imperative constraints, proposed solutions further need to balance the following constraints:
***Flexibility:** Users **SHOULD** be able to customize the behavior of individual tools to fit their use cases to the highest degree possible, and use cases **SHOULD** be limited as little as possible by design decisions.
***Ease-of-use:** Users **SHOULD** be able to run ZARP as conveniently as possible, with minimal management of tool parameters, with minimal risk of producing faulty runs and from various user agents (e.g., ZARP-cli, Snakemake).
...
...
@@ -36,6 +38,10 @@ In the function call that is bound to the `additional_params`, any wiring-critic
Parameters and values will be individually quoted in `parse_tool_config()` before compiling the return string.
##### Provenance
The entire command, including all user-supplied parameters and values, is expanded by Snakemake and is available in its logs.