Fwd: Re: [BuildStream] Add setting to disallow insecure transports

[Frazer Clews <fr...@codethink.co.uk>]

So is it agreed when we will ban http, ftp, and git if its set in 
project.conf to only allow secure downloads? Also how do we want to deal 
with GPG, or can that come at a later date?


-------- Forwarded Message --------
Subject: 	Re: [BuildStream] Add setting to disallow insecure transports
Date: 	Thu, 25 Jun 2020 19:49:36 +0200
From: 	Sander Striker via buildstream-list <bu...@gnome.org>
Reply-To: 	Sander Striker <s....@striker.nl>
To: 	Michael Catanzaro <mc...@gnome.org>
CC: 	BuildStream <bu...@gnome.org>



On Thu, Jun 25, 2020 at 4:58 PM Michael Catanzaro <mcatanzaro@gnome.org 
<ma...@gnome.org>> wrote:

[...]

    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.


Absent a feature in BuildStream currently, would it be a suggestion to 
add a validation hook on the git repository that rejects definitions 
that have the url pattern you wish to ban?

Cheers,

Sander

    Michael


    _______________________________________________
    buildstream-list mailing list
    buildstream-list@gnome.org <ma...@gnome.org>
    https://mail.gnome.org/mailman/listinfo/buildstream-list

Re: [BuildStream] Add setting to disallow insecure transports

[Tristan Van Berkom <tr...@codethink.co.uk>]

Hi,

> On Jun 30, 2020, at 9:41 PM, Frazer Clews <fr...@codethink.co.uk> wrote:
> 
>  So is it agreed when we will ban http, ftp, and git if its set in project.conf to only allow secure downloads? Also how do we want to deal with GPG, or can that come at a later date?
> 

I’m not personally convinced that the URI scheme is that meaningful (ssh:// should be secure ? what about future proofing for new, secure URI schemes ?), or even that a URI scheme is a hard requirement for every possible kind of remote socket connection (sources fetch data, will they always use a URI to describe where from ?).

This doesn’t appear very defined, while it may make sense as a policy for gnome-build-meta (and as Sander suggests, possibly a good thing to validate in their git hooks), I don’t feel very confident that a feature in BuildStream for this is meaningful.

At best, this might be yet another good argument for implementing the much desired URL reporting via `bst source show`, which would allow gnome-build-meta to implement their policy more easily ?

Cheers,
    -Tristan



> 
> -------- Forwarded Message --------
> Subject:	Re: [BuildStream] Add setting to disallow insecure transports
> Date:	Thu, 25 Jun 2020 19:49:36 +0200
> From:	Sander Striker via buildstream-list <bu...@gnome.org>
> Reply-To:	Sander Striker <s....@striker.nl>
> To:	Michael Catanzaro <mc...@gnome.org>
> CC:	BuildStream <bu...@gnome.org>
> 
> 
>> On Thu, Jun 25, 2020 at 4:58 PM Michael Catanzaro <mc...@gnome.org> wrote:
>> 
>> [...]
>> 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.
> 
> Absent a feature in BuildStream currently, would it be a suggestion to add a validation hook on the git repository that rejects definitions that have the url pattern you wish to ban?
> 
> Cheers,
> 
> Sander
>  
>> Michael
>> 
>> 
>> _______________________________________________
>> buildstream-list mailing list
>> buildstream-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/buildstream-list
> 
> <Attached Message Part>