taint untrusted data

[frasertweedale]

Purebred handles several kinds of untrusted data:

• emails, and parts thereof after parsing
• files provided by the user (attachments, composed email content)
• process output (especially when subprocesses operate on untrusted data!)

We should use types to demarcate these untrusted data and force (or at least "strongly encourage") the programmer to sanitise the data properly before handling it. This is especially relevant when:

• sending data to the terminal for display
• logging data (not that we currently do any logging)
• deciding a file name based on untrusted data
• probably some other situations?

The specific deliverables are grouped by the kinds of data we want to taint:

• [x] output from subprocesses
• [ ] mail bodies
• [ ] files loaded by the user (mail bodies may cover this)
• [ ] mail header values
• [ ] tags (and other direct data from libnotmuch)

[frasertweedale]

@romanofski POC commit: https://github.com/purebred-mua/purebred/commit/7e2b74cbaa421967c92abb79b8bfe1baab4dc39e. LMK what you think. It doesn't have to be a big bang, we can do it progressively.

[romanofski]

Yep I like this very much. So the deal is basically that we use Tainted to express the fact that the data could be malicious or "dirty" and needs to be "cleaned" before displaying. (I think that's exactly what you wrote in the description, but I wanted to express it with my words in order to have it understood).

[frasertweedale]

Cool, so I'll push forward with this on the subprocess side and make that the first deliverable. Afterwards I'll turn focus to taint on mail bodies / parts.

[romanofski]

Btw @frasertweedale was wondering whether is might use the plugin system too or should we just apply what we already have?

[frasertweedale]

No, this is built-in behaviour.

It is a good question whether data from plugins should be trusted or not. In general, because the user explicitly enables the plugin, there is no need to taint data from plugins. But perhaps there will be a use case.