1 |
On Mon, 04 Feb 2019 14:54:40 +0100 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> On Mon, 2019-02-04 at 14:48 +0100, Alexis Ballier wrote: |
5 |
> > On Mon, 04 Feb 2019 14:28:28 +0100 |
6 |
> > Michał Górny <mgorny@g.o> wrote: |
7 |
> > |
8 |
> > > On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote: |
9 |
> > > > On Sun, 03 Feb 2019 20:28:49 +0100 |
10 |
> > > > Michał Górny <mgorny@g.o> wrote: |
11 |
> > > > |
12 |
> > > > > --- |
13 |
> > > > > What do you think? |
14 |
> > > > > |
15 |
> > > > |
16 |
> > > > What is the difference with sunrise ? |
17 |
> > > |
18 |
> > > The difference, as noted in the mail, is that it doesn't rely |
19 |
> > > on developers having time to review ebuilds. Therefore, it is |
20 |
> > > less likely to die because of developers lacking time to review |
21 |
> > > stuff. |
22 |
> > |
23 |
> > |
24 |
> > Then I fear you will see the same pitfalls, and it already started: |
25 |
> > I recall sunrise haters being very strongly against the idea |
26 |
> > because, TBH, our sandboxing mechanism isn't a real sandbox. It may |
27 |
> > have improved, but I doubt it's up to the point that we can safely |
28 |
> > run untrusted code there. |
29 |
> |
30 |
> Sandboxing has nothing to do with security, and trying to 'improve' |
31 |
> its security is a waste of time. What's the point of preventing |
32 |
> ebuilds from doing malicious things at build time if they can install |
33 |
> files that do malicious things afterwards? |
34 |
|
35 |
|
36 |
Because one may or may not run a malicious binary. You are more likely |
37 |
to install it. And even more likely to source the ebuild. |