[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xen-devel
Subject:    Re: [Xen-devel] Critique of the Xen Security Process
From:       Lars Kurth <lars.kurth.xen () gmail ! com>
Date:       2015-11-11 9:59:55
Message-ID: 51949509-BA12-43FE-BEE5-922190CAE640 () gmail ! com
[Download RAW message or body]


> On 11 Nov 2015, at 09:43, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > Project Raisin is aiming to help with this
> 
> Indeed, and it might also allow us to make some of the above options the
> default in the future.
> 
> Maybe in the meantime perhaps a ./configure --ensure-offline or --disable-
> downloads which:
> * either disables stubdoms automatically or checks you've passed --
> disable-stubdom as well
> * either disables all the other things which might be cloned or requires
> the corresponding --with-system-foo=, or has a guess at a default system
> version
> * sets FETCHER to /bin/false
> 
> would be useful? (essentially as a guard against new options being required
> to turn stuff off).
> 
> > but it doesn't seem
> > to have a lot of community effort behind it and it too attempts to
> > install dependencies on my machine and wants to be run with sudo.
> 
> I believe it has a mode where it simply checks for dependencies and tells
> you what is required and thereby avoids the need for sudo, but I'm not
> sure.

It seems that raisin may provide a good baseline the for "build process security", \
but it would of course be good to hear this from others who have raised this issue. \
Assuming it is (we probably need a few ACKs for this), would it make sense to take \
this into a separate thread then (with an appropriate CC list), and refer to it from \
here?

Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[prev in list] [next in list] [prev in thread] [next in thread]