Re: [Xen-devel] Raisin, was Critique of the Xen Security Process

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 11 Nov 2015, George Dunlap wrote:
> On Wed, Nov 11, 2015 at 4:24 PM, Doug Goldstein <cardoe@xxxxxxxxxx> wrote:
> > On 11/11/15 6:33 AM, Stefano Stabellini wrote:
> >> On Wed, 11 Nov 2015, Ian Campbell wrote:
> >>> On Mon, 2015-11-09 at 15:48 -0600, Doug Goldstein wrote:
> >>>>
> >>>> I'll echo this sentiment as well. Most distro packagers will dislike
> >>>> this and need to work around some of this behavior in their respective
> >>>> distros.
> >>>
> >>> This is something we have been working upstream to address as well. As it
> >>> stands I believe everything which the tools might download can be
> >>> redirected to instead an existing component (via one of the --with-system-
> >>> foo configuration options) or disabled (via a --disable-foo configure
> >>> option). So I think now the current state is that there aren't
> >>> "workarounds" but rather "supported ways to disable".
> >>>
> >>> The big outstanding issue is the stubdom build, the distro I care about
> >>> most (Debian) simply doesn't build these (for reasons above and beyond the
> >>> downloading).
> >>
> >> Yes indeed. I have been tempted to disable stubdoms in Raisin until they
> >> are properly integrated in it.
> >
> > Define "properly integrated in". What work needs to be done to support
> > this? Until the tooling really makes it easy to use stubdoms then people
> > won't really use them and improve them.
> 
> I think Stefano is talking about integrating stubdoms as an external
> build in Raisin.  At the moment, I think stubdoms are one of the only
> things that will still download random external tarballs when you're
> building with raisin.

Right


> >>
> >>
> >>>>  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.
> >>
> >> Yes, that is correct. Raisin won't try to use sudo before asking the
> >> user first. That is the expected behaviour, if it doesn't work that way
> >> is a bug.
> >>
> >> Moreover I would be happy to introduce signature checks on git clones
> >> and downloads in Raisin.
> >>
> >
> > Does it have the mode Ian mentions where it will just print the depends
> > out to the user instead of installing them for you?
> 
> Not exactly.  At the moment it will determine, based on your OS and
> what you're trying to compile, which packages you need, and of those
> which packages are not installed, to generate a list of packages to
> install.  If you pass "-v", and require a password for sudo, it will
> print the list it is about to install before prompting you for the
> password, at which point you could copy & paste if you want to.
> 
> So all the functionality is there internally, it's just a matter of
> adding commands to make it only print the list rather than trying to
> actually install them.

There is no need to pass "-v" to get raisin to print the dependency
list. Also, unless the user explicitly says "yes", raisin won't invoke
sudo.

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