On Fri, 03 Mar 2006, Loïc Minier wrote: > If music sharing is a questionable feature to you, you don't need to > discuss this further, you're obviously the security guy, talking in > debian-security@ of stuff he doesn't want to support security-wise, and
You are *not allowed* to support security holes by the Social Contract, on the grounds that they can cause far more damage to users than whatever benefits they might bring. So drop the attitude. We're trying for a middle-ground solution, here. > don't want to see running on his server. Would this discussion happen > on a multimedia list, the situation would be kind of the opposite, and > people would be shouting loud if that wasn't pulled in by default. Then they can (read: should) use DeMudi, and DeMudi has all the excuses in the world to ship with all mdns services enabled by default. The Debian project *officially* recognizes the need for specialized distributions, you know. OTOH, when you package for Debian, you are doing the general distribution packaging. You are not allowed to cather to any special group needs in detriment of security, expect a lot of complaining if you do. So let's work on a way to reach a middle ground, shall we? In fact, I think you already stated in another post that a master switch would be fine, so this discursion could very well end here and now. > not having any central server, you have to listen for requests. Any > other proposal to implement the functionality and interoperability with > iTunes is welcome. The master switch addresses both your needs, and the security ones. All you need to do is not to hide it if you're shipping it with the default being the less secure choice. IMHO, make it priority medium, use a shared template that all mdns services can use (there is no reason why we shouldn't generalize this solution), and you can default to mdns enabled. Do not use priority low, unless you are going to default to mdns disabled. > Besides, the work is done quite cleanly with a chroot and a separate > user. Yes, which is good. But don't feel singled out, we are just as severe with every package. A lot of them decided to ship bound to localhost for this reason. Others implement master switches through debconf. Others prefer to ship with functionality disabled. As for using a separate user, that is the *rule*, not the exception. Yes, some crap in Debian still wants to run as root by default for dubious reasons, but that's not the rule anymore. > That's outrageous, the fact you don't have anything on your network is No, it is not. Your assumptions are just that, assumptions. And they may not be right. Do not assume you can even *run* an active (as opposed to a passive - listens only, never transmits) mdns service in a network just because a package that has mdns capabilities was installed: you cannot know that. Above all, never ever assume desktops are plugged to trusted networks. That is, in fact, outrageous. > I completely agree with the managed network part, but in such a > network: > - would you have music players installed? > - wouldn't you filter out any other port than HTTP, HTTPS, and FTP? Inside the network? Most managed networks have filtering at the borders, at key router nodes, and if it has a more advanced distributed-firewall mentality, on the all of the important boxes themselves (but that usually doesn't reach the workstations). Sure, there are places where the local workstations have remote-controlled firewalls, but they're not common (and AFAIK rarely used for anything but emergency virus/worm spread control). That said, music players are quite often allowed in a lot of managed networks. I never worked at a place where they were forbidden, in fact (but that doesn't mean music *sharing* is allowed). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
