[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Raisin, was Critique of the Xen Security Process
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |