I’m not talking about web links but symlinks on the system. I’ve got to fix up the tinderbox as we speak – the dev-libs/mpc update broken GCC, I’m thrilled that soon enough a C++ library upgrade will be able to break the compiler entirely! – but before doing so I was checking what was around on that system. And it turns out that way too many packages use absolute symlinks, both when installing from makefiles, and when creating ebuilds.
And there are more problems as well: a ton of world writable directories are also to be found on my tinderbox as it is, mostly in /var but not limited to. How many of these could be exploited for security issues, and how many of these are much less warranted than the stuff the hyped security guys focus on? Probably lots. Should I start reporting all of these as bugs? Possibly, yes, but I’m not sure if I’d be listened to, and for many packages the solution is going to be a very simple “drop the package as nobody’s interested”.
After this there is much debris that is there because upstream doesn’t understand how to properly install files on a Linux system. Sometimes there’s little you can do about it, as you need to keep it around for compatibility, but many other times, it’s extremely helpful to actually move things around in such a way that you don’t pollute the directories that, for instance, the linker has to search through to find the runtime libraries.
One very quick example about this latter situation is for instance move the daemons’ binaries out of /usr/sbin into /usr/libexec or whatever else you prefer (/usr/lib/${PN} works for me just as fine, it’s just a bit more arcane), so that it doesn’t pollute the path space for the root user. Especially when said daemons have no way to be executed in foreground for debug purposes.
At any rate, this is yet another piece of the puzzle that the tinderbox is helping to solve, so thanks again to all the people who contributed to it, the work is in progress (and yes, I did solve the mpc issue; bugs will resume flowing).