On Wed, 2 Feb 2005, Eric S. Raymond wrote: > One of the major problems with yum as it is now is that yum configuration > (specifying the set of repos you will query) is complicated. Yum users > typically have to patch their local config whenever either (a) the > dependency relationship between two repos changes, or (b) they want to > add a new specialized repo (as, for example, the RealPlayer repo). > > I think there is a simple added feature that would make life a great > deal less complicated for users: repository-level redirects. That is, it > should be possible for a a repository to say "if I don't have the > package you want and it matches a specified regexp, I'll chase this > specified list of URLS to build a set of other repos to try". > > With this feature, livna could redirect to .US and .US to > fedoraproject.org, which could in turn redirect to special-purpose > sites like the RealPlayer repo -- all transparently to the yum user. > > Users would subscribe to an entire chain of repositories by putting > the head end of the chain in their conf file. Repository rings like > rpmforge.net could redirect to each other. This would make me very nervous on the maintenance/update chain of any sort of security-conscious network (which should be ALL networks, of course). Each administrator has to be permitted to choose the repositories they wish to trust, given that any insertion of a trojanned RPM on any repository on the chain will suffice to completely compromise any system. Having a repository redirect to a site selected by ITS administrators means that I might never know just where my RPMs are coming from. It also gives crackers a clear target and exploit path on any repository anywhere in a trusted chain of repositories, where the administrator of a local system does not even know (that's the "transparent" part) what the structure of the chain is and where it might dynamically change overnight at the whim of an intermediate repository administrator or cracker that has taken over that system. So I'd say repository level redirects are a Bad Idea, in general. Really, really bad, the more that I think about it. I have a hard enough time really trusting the repository chains I already use, and tend to turn off updates on stuff from little "twig" repositories or privately maintained cool tool repositories when I'm not actually doing a primary install, and just live without updates until I'm ready to update by hand and watch what happens. However, I also acknowledge the problem you describe -- maintaining a a repository set isn't terribly simple and involves a certain degree of experience with unix aracana. Perhaps a better solution for the novice network administrator or the administrator of a standalone system is the development of a GUI tool for repo administration within yum -- a graphical browser, a graphical yum configuration tool -- with automated discovery features. I'd be perfectly happy for a repository to SUGGEST possible secondary servers to use in yum's already existing repository fallback mechanism -- I just don't want to follow such a chain blind, especially offsite and into a different organization that I might not trust. It would be truly lovely if the tool directly supported the kind of usage I just implicitly described -- having a search tool for repositories from which I can install e.g. realplayer, a selection tool to pick a repository from the list that I can trust or which has e.g. SSL credentials I can verify and via which I can obtain trusted gpgcheck keys, a tool for manipulating those keys (another nontrivial problem for the novice/single system administrator that is likely to have them setting "gpgcheck = 0" the first time they encounter a problem, which is likely to be the first time they add a twig-level repository), a tool for turning on access to that repository for the time required to do a single install or update, a tool for turning off access (put preserving the repository in the list) when not deliberately installing or updating from that site. That is, there are at least two levels of repositories that are likely to be of interest to a real network sysadmin and to many single system admins: a) Primary install/maintain repository -- e.g. fedora itself or one of its trusted toplevel mirrors or homemade/local mirrors of those mirrors. This might be local, might be remote, but I'd be very nervous indeed about fedora automagically forwarding me to a possibly different mirror that >>I<< didn't pick or know I'd be redirected to every single night. Even the nature of the network traffic that establishes the redirect appears to me to be vulnerable to some not terribly complex e.g. man in the middle attacks without adding in a whole set of network security specifications (e.g. all connections SSL verified). Not that some of these vulnerabilities might not be there already -- a good reason to prefer local mirrors for primary installation and maintenance, and to control the mirroring process as best one can. b) A local repository layer for installing local rpm-bundled tools. I'm presuming that this is as trustworthy as you (the local admins of the local repository) choose to make it, but robustness here is a matter of local fallback, not requiring redirect. Locally you control the yum.conf and other yum files used by the systems in your network. c) Remote "twig" repositories, where one can get realplayer, mozilla-milk fresh from the cow, jove, and other stuff that you want but which isn't in the a) or b) repositories for any of several reasons and which is likely to be installed with a significantly different level of trust associated with the twig repositories themselves. Sheer numbers of these twig repos in yum significantly increases your security risk and creates the possibility of some nasty chain reactions if any sort of loop topology such as "yum rings" is ever actually established. Compromising any repository in the ring might suffice in short order to compromise the entire linked set of rings -- maybe even all repositories, anywhere. That would be tough for linux, and yum, to live down. > When the repository relationships change, a repo administrator could change > a redirect in one place, rather than all yum users having to change > their conf files. > > Thoughts? Lovely idea in the abstract, terrifying in the concrete. rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
