Re: [gentoo-dev] [RFC] Overlays and Metadata Cache

[Ciaran McCreesh]

On Sun, 21 Jun 2009 17:00:01 +0200
Patrick Lauer <patrick@g.o> wrote:
> > But generating that cache means running code, and one of the things
> > that code could do is modify every overlay distributed by the box in
> > question such that anyone using any of those overlays will run
> > arbitrary code whenever they do emerge -p world.
>
> Good, this means we have to isolate it so that only each overlay
> itself exists in an environment that generates the metadata cache. A
> bit bothersome, but nothing more than adding a line or two to the
> script(s) that drive(s) this process.

So your process would be to clone a new VM for every overlay, add the
overlay into that VM, do the generation and then grab the cache out of
the VM? Ouch.

> > There's a big difference between the levels of verification done for
> > developers and that which is done for overlay maintainers.
> > Currently, any overlay maintainer can root any box on which their
> > overlay is used (whether or not anything from that overlay is
> > installed). You're escalating this to any layman-listed overlay
> > maintainer being able to root any box using any layman-listed
> > overlay.
>
> Right, that would be silly. So ... we can restrict the whole concept
> to official overlays if we want (trust and all that), and we can keep
> separate environments per overlay to avoid cross-contamination. Which
> keeps us about as exposed as the status quo, but we make updates and
> dep calculation faster (at least for those overlays that are in a
> sane condition).

That's getting towards a more reasonable proposal. Although then if you
decide you trust official overlays, the cross-contamination thing only
needs to protect against accidental screw-ups, so you don't need the
whole VM mess at all.

> Y'know, what would be even more fun than this pingpong would be a
> consistent counterproposal from you. Point out all the issues at once
> instead of one per email and all that.

I don't necessarily have a counterproposal. I don't think it's a bad
idea in principle, I just don't think you've thought through the
security implications. Once you do that, I don't see a way of doing this
sensibly for overlays you don't absolutely totally trust.

> Like this we're at the third or fourth iteration, people (including
> me) get bored with the whole thread and some half-baked thing gets
> implemented because only three people manage to read the mail thread
> to its end ...

You end up with half-baked proposals if you jump straight into doing
something without repeatedly going over an idea until all the kinks are
worked out. Some of the flaws in the proposal aren't immediately
obvious and only come out after discussion.

I realise you believe I'm perfect and all-knowing, and can instantly
spot every single way your idea is flawed and immediately come up with
a perfect alternative, and I don't blame you for that belief. However,
a viable solution to this when untrusted overlays are involved doesn't
immediately spring to mind, and if such a solution exists, experience
suggests it'll only come about through possibly lengthy discussion, so
I'd rather not prejudice you with my preconceptions. If you're not
prepared to spend time discussing this, you'll definitely end up with
something that's either highly limited in scope or that opens up a
whole new avenue of abuse.

-- 
Ciaran McCreesh