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