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

[Patrick Lauer]

> > The metadata cache is "inert" in the sense that it isn't executable
> > code (and if anyone tries to execute it ... "You're doing it wrong"
> > comes to mind"), so adding it does not pessimize the situation.
>
> 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.

> > Hmm. I can't think of any sane way to prevent people from writing bad
> > ebuilds. And I also can't think of a reliable method to detect such
> > or prevent users from trying to use them. In short, we just have to
> > trust people. As a sidenote, we just randomly trust devs too. And it
> > usually works ...
>
> 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).

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. 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 ...