Re: [BuildStream] Add setting to disallow insecure transports

[Michael Catanzaro <mcatanzaro gnome org>]

On Thu, Jun 25, 2020 at 9:21 pm, Tristan Van Berkom 
<tristan vanberkom codethink co uk> wrote:
>   * 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 ?

Secure transport: https:// ftps:// sftp://

Insecure transport: http:// ftp:// git:// and most anything else

>   * Is the URI scheme really any indicator ?
>
>     If so, why ?

Well... that's just how transports work, they are either secure or 
insecure. Now, it is possible to use https:// insecurely, by ignoring 
TLS certificate errors, or by allowing connections that use weak 
ciphersuites, but buildstream doesn't need to worry about any of that 
because whatever it uses to handle https:// (libcurl?) will be 
relatively secure by default.

>   * 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 ?

The use case is that I keep discovering elements in gnome-build-meta 
that use http://. I just counted and we have 12 currently, all of which 
must have snuck in since the last time I checked for them. Because we 
don't have project.refs on the master branch, that means any MITM 
attacker between the build server and the server that hosts the tarball 
can trivially replace the tarball with arbitrary malicious content and 
we would never notice. This is quite easy for a skilled attacker to do, 
e.g. with a BGP attack. Without project.refs or refs pinned in the 
file, we don't notice and will happily include the malicious content in 
the new runtime.

http:// plus GPG could theoretically be secure, but that requires 
significant effort to set up and I really don't care. There is zero 
excuse for not using https:// in 2020. The safest approach is to 
completely ban it from the GNOME runtime (and freedesktop-sdk). 
Similarly, ftp:// and git:// also need to be banned. If we have 
projects that cannot be downloaded safely from upstream, we can rehost 
them.

Michael