Robert G. Brown <rgb@xxxxxxxxxxxx>: > 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. This problem is easily solved. Yum gives users progress messages on download anyway; these messages should *always* include the source site of the RPM. To go with this, the default behavior should be to stop and asks for confirmation when a redirect takes you to a repository you have not previously indicated you trust. (Any repository in your conf is trusted by definition.) You speak of the "whim" of an intermediate repository administrator, but I think repository administrators are far more likely to have an accurate model of repo dependencies than end users are. > 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. The mechanism required for the repository to make suggestions is the same as the mechanism for it required to do transparent redirects, The only difference would be policy choice in the client. You're quite right that following redirects blindly would be bad. The correct answer is to have the facility, but make sure that following the redirects isn't blind. I think my proposal and your counter just merged. For either proposal, we need a new piece of per-repository (or perhaps per-channel) metadata, which is a package redirect list. The client (yum) needs to know that it should look at that list when a repo search fails to find a match. It's a client policy issue how much checking the client does before chasing the link. > 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. Agreed. However, all this stuff depends on having the right metadata in the infrastructure first. That's problem one. > 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. I already thought of this one. Breaking such loops is trivial; you keep a list of visited repositories and simply don't add a redirect if it's already present in the list. > 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. Yes, but we already have this problem. That is, any repo compromise could already fuck up a lot of end users badly. Redirects wouldn't make it worse, unless the redirection chasing is hidden from the user (which I'm not proposing). > Lovely idea in the abstract, terrifying in the concrete. As I said, I think my proposal and your counter have merged. We can de-terrify this; all we have to do is inform the user of sources and have a known_hosts equivalent that stops the user for a check before diving into an unknown repository. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
