This PR makes us treat most content of torrents parsed by parse-torrent as untrusted. Such torrent content was the taint source in CVE-2019-15782 (we do not flag this vulnerability yet, we are missing a flow step elsewhere).

Implementationwise, I would have liked parseTorrent(...) to be a labelled RemoteFlowSource, and then let the flow label mechanism ensure that we only propagate through certain properties of the parsed torrent, but that requires unreasonable adjustments in all Configurations.

Instead, I have used type tracking to track the parsed torrent, and then used certain property reads of that tracked torrent as ordinary RemoteFlowSources. This leads to sub-optimal sources in the path-problem alerts, but it is the same pattern as the one we use for RequestInputAccess: we do not provide a link to the request object itself, but rather a use of it.

Generally speaking, this new source is related to the js/zipslip sources where we model that something is expected to be provided by external parties and thus should not be trusted. We should investigate such sources more thoroughly, and perhaps even deprecate js/zipslip in favor of a js/path-injection with zip-file content as a RemoteFlowSource.

Evaluation

• 3 likely TPs among some packages that have parse-torrent as a dependency.
• sanity check on nightly.slugs (ongoing)