| 1 |
On Mon, 04 Feb 2019 15:13:36 +0100 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> On Mon, 2019-02-04 at 15:04 +0100, Alexis Ballier wrote: |
| 5 |
> > On Mon, 04 Feb 2019 14:54:40 +0100 |
| 6 |
> > Michał Górny <mgorny@g.o> wrote: |
| 7 |
> > |
| 8 |
> > > On Mon, 2019-02-04 at 14:48 +0100, Alexis Ballier wrote: |
| 9 |
> > > > On Mon, 04 Feb 2019 14:28:28 +0100 |
| 10 |
> > > > Michał Górny <mgorny@g.o> wrote: |
| 11 |
> > > > |
| 12 |
> > > > > On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote: |
| 13 |
> > > > > > On Sun, 03 Feb 2019 20:28:49 +0100 |
| 14 |
> > > > > > Michał Górny <mgorny@g.o> wrote: |
| 15 |
> > > > > > |
| 16 |
> > > > > > > --- |
| 17 |
> > > > > > > What do you think? |
| 18 |
> > > > > > > |
| 19 |
> > > > > > |
| 20 |
> > > > > > What is the difference with sunrise ? |
| 21 |
> > > > > |
| 22 |
> > > > > The difference, as noted in the mail, is that it doesn't rely |
| 23 |
> > > > > on developers having time to review ebuilds. Therefore, it is |
| 24 |
> > > > > less likely to die because of developers lacking time to |
| 25 |
> > > > > review stuff. |
| 26 |
> > > > |
| 27 |
> > > > |
| 28 |
> > > > Then I fear you will see the same pitfalls, and it already |
| 29 |
> > > > started: I recall sunrise haters being very strongly against |
| 30 |
> > > > the idea because, TBH, our sandboxing mechanism isn't a real |
| 31 |
> > > > sandbox. It may have improved, but I doubt it's up to the point |
| 32 |
> > > > that we can safely run untrusted code there. |
| 33 |
> > > |
| 34 |
> > > Sandboxing has nothing to do with security, and trying to |
| 35 |
> > > 'improve' its security is a waste of time. What's the point of |
| 36 |
> > > preventing ebuilds from doing malicious things at build time if |
| 37 |
> > > they can install files that do malicious things afterwards? |
| 38 |
> > |
| 39 |
> > |
| 40 |
> > Because one may or may not run a malicious binary. You are more |
| 41 |
> > likely to install it. And even more likely to source the ebuild. |
| 42 |
> |
| 43 |
> 1. There are trivial ways to make you run something. Imagine an |
| 44 |
> ebuild installing into /etc/local.d. Or /etc/cron.d. |
| 45 |
|
| 46 |
|
| 47 |
Think of an automated QA check for those ebuilds, running some sanity |
| 48 |
checks and then uninstalling them. |
| 49 |
|
| 50 |
> 2. By design, postinst is run with full privileges. It is meant to |
| 51 |
> allow ebuilds to run stuff, as root. |
| 52 |
|
| 53 |
|
| 54 |
And that is precisely that kind of design that makes it hard or |
| 55 |
unrealistic to have unreviewed global repositories. |
Archives