"Eric Polino" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 20 Jul 2007 00:02:56 -0400:
> On 7/19/07, Duncan <[EMAIL PROTECTED]> wrote: >> "Eric Polino" <[EMAIL PROTECTED]> posted >> [EMAIL PROTECTED], excerpted >> below, on Thu, 19 Jul 2007 21:52:16 -0400: >> >> > Yes there would be a few other small supporting packages. >> >> I may well be in the minority on this, but here it's not so much the >> compile time or space I'm worried about, but the whole security thing >> of not installing stuff that I'm not going to use and shouldn't need. > > If this is truly a problem, then I think the negative USE flags might be > the better solution then. This would allow users the ability to disable > potential insecure features. But really, I doubt security is an issue > here. Some people don't like negative USE flags because they are a bit counter- intuitive. You /enable/ the USE flag to /disable/ the feature, and that counter-intuitivity has some devs hoping to eventually do away with them entirely. Personally, while I generally prefer positive flags, negative flags serve a very good purpose precisely because they /do/ stick out -- if I encounter one, it's a pretty good indication I better think twice about disabling it (since it's generally enabled by default). It serves as a quite useful distinction between "do as you wish" flags and "do as you wish, but be SURE you know the consequences first." So I agree with you on the negative USE flag idea but believe many won't. The security issue is in general, and worse when an app is net-exposed as is the case here. Think of the recent aim:// protocol exploits in certain apps. If a user never uses AIM, they may not realize they are vulnerable, yet if these apps are installed with aim:// protocol active, they are /very/ exposed as the exploit (from what I've read) required simply that the remote end of the conversation invoke an aim:// URL with the malware payload attached. If it's possible to protect a user from that sort of exploit by making various protocols optional so they don't need them enabled when not necessary (and that's what Gentoo does with USE flags and compile from source), I believe it's a very good idea to do so. >> To be clear, if it's simply the USE flag defaults under debate, not a >> problem [but s]omeone mentioned just killing the USE flags and making >> them all hard dependencies > > [H]ow different would this be to any application that requires > dependencies and you can't change the fact that they require them. Required are required. Take it or leave it. Decision made by upstream and when a user chooses that app. Optionals are just that, optional. > The Pidgin team "sells" their application as having all these protocols > so they should be there, at least out of the box. But a big selling point of Gentoo is that it doesn't force you to take that "box" as it's normally shipped. You effectively get the components as a kit and assemble it yourself, with the ability to leave out parts that you don't need. That's a /good/ thing, at least to most Gentoo users, or by definition, they'd be using a distribution that comes with all those binaries "pre-assembled". To then ship it with all those options forced on... goes against one of the big points of running Gentoo in the first place. >> People not running -pv or -av... <content for project or user omitted> > > Don't know what you mean here. Simply that I down that down that topic lays a rant, and this isn't the place for it. This subthread is headed off-topic for gentoo-dev too, so I'm x-posting to gentoo-project, with further replies set to go there (if the listserv doesn't overwrite them). Or reply to me personally if you prefer. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
