Re: [BuildStream] Add setting to disallow insecure transports

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Thu, 2020-06-25 at 12:12 +0100, Frazer Clews wrote:
> Hi
>
> For this issue I have come up with some solutions
>
> Some being similar to the acceptance criteria by adding a setting to 
> project.refs, although not sure if project.conf is more appropriate. Or 
> by setting an optional flag to either toggle or set the option to only 
> allow secure sources, personally prefer the latter as a toggle could get 
> confusing going from project to project.

The project.refs file is not the place for any configuration, this file
is mostly meant to (optionally) store `bst track` results in lieu of
the element.bst files themselves.

Configuration-wise, it may make sense as a project.conf configuration,
or it may make sense as a Source kind specific configuration, which
could then be specified for an entire project using the project.conf's
source configuration override section:

    https://docs.buildstream.build/master/format_project.html#source-overrides

> I have been experimenting where to put in the check for the type of 
> protocol being used and stop it, but only got it properly working so far 
> for ftp in downloadablefilesource.py and feels kind of hacky, so will 
> look into a better solution, but happy for suggestions

This is the part I'm not sure of, there are a few questions worth
pondering here.

  * How do we determine what is "secure transport" ?

    Certainly, once one opens a socket and starts speaking
    some kind of protocol, they could use end-to-end encryption,
    or they could be using cryptographic signing to verify
    downloaded results (like the GPG keys used by the ostree
    sources).

    How do we know ?

  * Is the URI scheme really any indicator ?

    If so, why ?

  * If the URI scheme is really an appropriate indicator, how
    can the core be made aware of what URI scheme a plugin is
    effectively using in order to download things ?

    We don't have any API for this.

Possibly, we need more input from the reporter (Adding Michael on CC
here) in order to determine what the underlying use case for this is.

For instance, would GPG verified downloaded content over http be as
trustable as non GPG verified downloaded content over https ?

Cheers,
    -Tristan