Re: [BuildStream] Protect against plugin modifications of artifacts

[William Salmon <will salmon codethink co uk>]

On 22/06/2020 12:24, Tristan Van Berkom wrote:
> Hi William,
>
> Thanks for engaging in this.
>
> On Mon, 2020-06-22 at 11:02 +0100, William Salmon wrote:
> > Reply in line.
> [...]
[..]
> The main differences here are:
>
>    A.) The guarantees we can provide about running safe sandboxed code
>        compared with untrusted local python interpreter code.
>
>        This would lead us down a path of providing ever more carefully
>        crafted APIs in the core in order to produce reproducible output
>        in the artifact, all the while not being certain what python APIs
>        a plugin might use to produce output.

Else were you mention that you don't want to get in to a debate about if 
we can trust python. So lets not, lets decide were things should live 
and then decide if we need to change our plugin language separately.

If a plugin creates a config file with logic dependent on config options 
and variables etc and then the plugin adds a configure command that 
calls cat to add this text to a file. This seems just as susceptible to 
plugin author or plugin language issues as if the plugin directly adds a 
file to the cas (via the nice api we have now) so it can be included in 
the sandbox.

These seem equivalent except that using cat is more complex and requires 
cat be a build dependency. There are many alternatives to cat but they 
still require some extra bin be in the sandbox and adding new configure 
commands.

>    B.) Simply having a "second way" of doing things complicates things
>        for us, as the question of which way to choose arises for a
>        plugin author, when the safe way should be the only choice.

I agree that we should not have lots of ways of doing the same thing. I 
disagree on what is a good way to assemble a configuration file.