On Mon, 2019-02-04 at 15:04 +0100, Alexis Ballier wrote:
> On Mon, 04 Feb 2019 14:54:40 +0100
> Michał Górny <mgorny@g.o> wrote:
>
> > On Mon, 2019-02-04 at 14:48 +0100, Alexis Ballier wrote:
> > > On Mon, 04 Feb 2019 14:28:28 +0100
> > > Michał Górny <mgorny@g.o> wrote:
> > >
> > > > On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote:
> > > > > On Sun, 03 Feb 2019 20:28:49 +0100
> > > > > Michał Górny <mgorny@g.o> wrote:
> > > > >
> > > > > > ---
> > > > > > What do you think?
> > > > > >
> > > > >
> > > > > What is the difference with sunrise ?
> > > >
> > > > The difference, as noted in the mail, is that it doesn't rely
> > > > on developers having time to review ebuilds. Therefore, it is
> > > > less likely to die because of developers lacking time to review
> > > > stuff.
> > >
> > >
> > > Then I fear you will see the same pitfalls, and it already started:
> > > I recall sunrise haters being very strongly against the idea
> > > because, TBH, our sandboxing mechanism isn't a real sandbox. It may
> > > have improved, but I doubt it's up to the point that we can safely
> > > run untrusted code there.
> >
> > Sandboxing has nothing to do with security, and trying to 'improve'
> > its security is a waste of time. What's the point of preventing
> > ebuilds from doing malicious things at build time if they can install
> > files that do malicious things afterwards?
>
>
> Because one may or may not run a malicious binary. You are more likely
> to install it. And even more likely to source the ebuild.
1. There are trivial ways to make you run something. Imagine an ebuild
installing into /etc/local.d. Or /etc/cron.d.
2. By design, postinst is run with full privileges. It is meant to
allow ebuilds to run stuff, as root.
--
Best regards,
Michał Górny