On Sat, 4 Oct 2003, seth vidal wrote: > > After looking at this I have few suggestions. > > > > 1) Allow the user to disable the newtwork includes. > > How? The includes are to be used to specify the config file - the only > place to set them would be on the command line. And even then you'd > probably not have a functional config file at all. > Oh. I misunderstood and assumed that they existed in the config file itself, the whole thing being started from the config on the system. > > 2) Have do not allow network includes to override already > > configured global items. > > It wouldn't have to override them - it would just have to add a > repository that had newer packages than you do or than the other repos > do. > Again, my assumption was that the includes where occuring in the the config file itself. I must have completely misunderstood the feature. I have a config format for building RH distros that supports includes (but not from the network), so I was thinking along those lines. My bad...sorry. > > 3) Perhaps have certain items that cannot be set (or unset) > > via a network include. > > I think that would be a mess both programmatically and from a user > perspective. > The only one I would really see doing is the disabling of gpg signatures, as far as it being a mess programatically, it depends on how your parser is written. I haven't looked at it so I can't say. But just hypothetically if your parser handled includes by recursively calling itself again with the path/URL to the include then when the parser is re-enterd it knows whether it is picking something up with a URL as opposed to a filesystem path. Knowing this it can easily without too much convolutions make a decision of whether a particular config item should be parsed in said context. Even if it is not recursive, when it begins parsing the new file (i.e. the include) it could simply set a state variable depending on whether it was using the include off the net or the filesystem, and then, as above intelligent decisions can be made about the validaty of particular config items based on the state of the parser (i.e. is now parsing a config from the net, or from the filesystem). It is a little more involved with that, but I am sure you get the picture. Ulitimately, as with having the gpg sig checking disabled from a config over the net, I was only trying to point out that there may be some config items that are best not overridable by configs from a remote source that you don't have control over. > > > I think would go a long way towards making it more secure in a network > > environment. > > > > Cheers...james > > > > P.S. The gpg signing did come to mind, but now I am in fear of saying it > > (-; > > The problem with gpg signing the config file snippets is this: > > 1. you'd have to use gpg to check them > 2. you'd have to have configured a place to store the gpg keyring - b/c > we're checking text files, not rpms at that point. > 3. where would you look to find the configuration data to know where the > gpg keyring is stored? > > At that point it starts being highly questionable as to whether or not > to have this feature at all, b/c at that point running yum as a user > would be almost impossible depending on where the gpg keyring is stored. > I understood all that thus the (-;. I was only joking that it poped into my head as it must have yours or you wouldn't have mentioned it. Yes, security is about a lot more than algorthims, especially when you have to consider things like collusion, social engineering, physical security and other annoyances from the real world. Cheers...james > -sv > > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum >
