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
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
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
> - 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