Re: avahi-daemon
On Fri, Mar 03, 2006, Joey Hess wrote: Standard Desktop task installs do not install Recommends anyway, so rhythmbox does not pull in avahi-daemon in those situations and you need to deal with that somehow. It's a but in task installation then. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: On Fri, 03 Mar 2006, Loïc Minier wrote: On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: True. But that requires a broken kernel, which we patch regularly as a security procedure anyway. Mounting removable filesystems suid,dev allow a lot more damage *by design* in the standard Linux security-model. And we also support avahi security-wise, and would patch it in the case of a knwon vulnerability. Nobody ever implied that avahi is badly maintained. And unless mdns/avahi is somehow being shipped configured in such a way so as to allow for immediate local root priviledge escalations, I don't think I understood the point you wanted to make. You were making the point that it's a security bug to mount USB sticks automatically without nodev and nosuid, and people responded to you that it was already a security risk to mount a filesystem automatically. You finally replied that implies a borken kernel and the kernel is supported security-wise. My point was to draw the following parallel: - mounting a filesystem automatically = listening on the network - kernel vulnerable = avahi vulnerable - kernel supported security-wise = avahi supported security-wise (- protecting with nodev nosuid = not having anything advertized) I stated that the fact that an hipotetic kernel bug *also* allows for local root exploits through a nosuid,nodev removable filesystem does *not* excuse us to have removable filesystems being mounted suid,dev, which depending on the filesystem type allows for immediate local root privilege escalation, *by* *design*. Which I completely agree with. But by default, no music is shared via avahi, so it would require a bug in avahi (exactly like it would require a bug in the kernel) to do anything nasty. Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Internal trusted networks? (was Re: avahi-daemon)
Hi, On Sat, Mar 04, 2006, Javier Fernández-Sanguino Peña wrote: I thought security people would recommend havin a per-port ACL for allowed traffic, and port visibility set to limit the view to only the router when not otherwise required. I don't think you have seen many corporate (i.e. hundreds of nodes) networks. I've seen a few, and, from my limited experience: Uh, I never said that's what I would expect to see on a corporate networks. I've connected to networks at HP, I've connected to network of security firms, and they didn't have the measures I mentionned. I've read about using such drastic limitations in the interview of a famous security guy (and considered the idea was too impractical to applu to the networks I manage). It was someone famous, like some Netfilter or OpenBSD architect, but I can't find the article where I've read that (help welcome to find it back). So even if the security people as you so put it, would recommend per-port ACL allowed traffic they would (and do) get shunned by other IT departments. At most, IT security can get a bridge firewall [1] setup between sensible networks to isolate and try to control traffic between them. Right, _in practice_ no one can follow very strict security guidelines, which is the point I was making in mentionning extreme security measures. In practice, security has limits. With people bringing laptops (and all kind of devices) from the outside of the network, unprotected/uncontrolled WiFi access points, etc. there is no such thing as an internal trusted network. But you're still way more secure while sitting behind a NAT with responsible coworkers than connected to the Internet directly, without any firewall, and that's where desktops sit most of the time. Bye, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006, Michael Stone wrote: On Fri, Mar 03, 2006 at 02:36:38PM +0100, Loïc Minier wrote: Do you have any other solution permitting the same functionalities, but without the listening port? No. If someone wants that functionality than that's how they need to get it. The question has always been about what level of effort is necessary on the user's part to enable that functionality. My point of view is that installing the application gets them the functionalities they'd expect to find in the default setup. But you are doing nice in pointing at typical services running on a desktop machine: - apache2 (and will be even more common with gnome-suer-share and DAV file sharing) - samba You think that's part of a typical desktop system? Fascinating. Yes, I think these are often part of a desktop. Does any of these run chrooted like avahi does? Samba even runs as root. Which of samba or avahi has the power to change file ownership, permissions, or simply to serve sensible files such as /etc/shadow? You continue with the specious arguments. What non-server dependency pulls in samba? What dependency pulls in gnome-user-share? The argument isn't whether someone who intentionally installs a package should get the functionality of the package, it's about what kind of side-effects might unknowningly be enabled by someone installing an apparantly unrelated package. If you find my last arguments were specious, let me reformulate them for your reading pleasure: straight: - I believe other apps typically installed on desktop systems are way more dangerous that the big hole people consider opened by avahi - avahi doesn't need a lot of rights to run, by design, and beyond this implements the classical security enhancements one expects to find in clean daemons In other words, even if it opens a new port, I believe this is less a security concern for desktops than other typical services. Concerning your dependencies remarks, I think I've answered to them enough already: this is a Recommends, nothing pulls in rhythmbox from a standard install up to a gnome-desktop-environment install, I proposed dependencies workarounds for most use cases (have a conflict from security packages, use your own meta-package...). Frankly, you're not considering the arguments I gave on dependencies, you even ignored them multiple times already, and since the core of this issue is about dependencies, and the fact that rhythmbox pulls in avahi by default, I'm not inclined to be interested in continuation of this discussion. If you feel there's a technical problem with the technical choices of a package or meta-package, bring it as a bug report, linking to this discussion, and if you don't get maintainer's agreement, please bring it to a technical committee. It's really here to help take technical decision where consensus can not be reached. -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006, Javier Fernández-Sanguino Peña wrote: On Fri, Mar 03, 2006 at 02:36:38PM +0100, Loïc Minier wrote: This is a desktop machine, it should permit sharing of files on your local network. DNS servers have their port 53 open to respond to name resolution queries, just consider your desktop installation to be a name server responding to stuff such as what services are available, what shares are available etc. /me looks doumbfounded Excuse me? Since when does a typical desktop machine provide users to share *music* on a local network? (Don't tergiverse the fact that ahdavi is used, in rythmbox, to share music, not files) I said sharing of files, and I meant files only, as in sharing of data files between coworkers with samba for example. And for the same thing, why would a typical desktop machine provide users to share even files! My desktop system at home (and my parent's and my uncle's and whatnot) are completely stand-alone desktop systems, connected to the Internet, with no LAN. They only need to talk to their (serial or USB connected) printer, that's all! Fine, and perhaps you don't even need music sharing on them, but does it still automounts filesystems plugged in USB? :) One can't know in advance what uses a system is for, I believe people installing Rhythmbox want to be able to share music by default (easily). You're free to believe the contrary, it's a matter of opinion, I gave numerous arguments to my position already, and don't want to talk in loops any further. You don't want it? Don't install it or configure it the way you like. I'm surprised that the over-bloat of Windows' desktop is now considered to be the good way of doing things. I'd rather have drawn a parallel with Apple software, such as MacOSX, or their Wifi APs. Please have a look at their traffic and open ports next time you get near one of them. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Hi, On Sat, 2006-03-04 at 10:26 +0100, Loïc Minier wrote: Concerning your dependencies remarks, I think I've answered to them enough already: this is a Recommends, nothing pulls in rhythmbox from a standard install up to a gnome-desktop-environment install, I proposed dependencies workarounds for most use cases (have a conflict from security packages, use your own meta-package...). Well, since the gnome meta-package is part of the gnome task, which I consider a common default to setup a desktop machine, it get's pulled in in an environment where Recommends are installed automatically. I think, your proposed solutions do not cover this issue at all. Users, who know what they want and what they are doing, do not run into this problem, since they can manually deselect avahi-daemon. We are indeed talking about regular users. In another mail, you agreed, the maybe only 10% of them want to share music. So, why give another open port to the other 80% (assuming, that 10% of the users know what they are doing ;o)). If you feel there's a technical problem with the technical choices of a package or meta-package, bring it as a bug report, linking to this discussion, and if you don't get maintainer's agreement, please bring it to a technical committee. It's really here to help take technical decision where consensus can not be reached. I have a technical question here. First of all, I think, that avahi-daemon listening on all interfaces by default, is what we want. It's the only reasonable setup for a multi-cast discovery daemon. A Debconf question about this is not even necessary here, IMHO. OTOH, the majority of Rhythmbox users might not want to share music, but install rhythmbox in an environment, where Recommends are pulled in automatically. Ok, we discussed that. But still it's only a Recommends. Therefore, rhythmbox needs to handle the absence og avahi-daemon gracefully, since you cannot rely on it's installation. For sake of plug-and-play and comfort, this might be even done in some kind of GUI message, which tells the user what to do, if he/she wants to access a feature, that requires the daemon's presence. If you agree on this, there is no reason, to lower the dependency to a Suggests and everybody would be happy. If you still think, that a feature, that is present by default but might be used only by a limited number of users overweighs the possible security implications of another open port, I think we really cannot come to a consensus in this point. My two cents. Philipp signature.asc Description: This is a digitally signed message part
Re: avahi-daemon
On Fri, Mar 03, 2006, Javier Fernández-Sanguino Peña wrote: (IMHO this dicussion is reaching to a point in which it should move to d-devel instead, but I'll keep it here) Uh, please don't move it there, in the contrary, this discussion already reached flame-level, and no arguments are coming in. I'd rather get things settled down, and solutions implemented. I made some efforst in listing solutions here, and in the bug report MS opened. I don't want the burden of following a new flame in debian-devel@ . It would be overly complicated to handle the case of a Suggests instead of a Recommends correctly: even if the code was updated to handle both Overly complicated? You are overestimating it. It's as simple with a Suggests: as with a Recommends: (people still use 'apt-get' which does not pull in Recommends: automatically). The software cannot rely on it being installed so it should check if the thing it needs is there, if it's not then it asks the user to install it. You've cut what I said, I explained why I didn't like that. Please don't cut like that, that's quoting out of context. I said it woud require code to disable preferences when avahi isn't there, the documentation would still refer to the features, but the user wouldn't have them, and a dialog would be ugliest: it would introduce package level information within an application. Yes, some of this can be done (patch for the runtime part welcome, file it, I'll check it, send it upstream, apply it). This can be an error in STDERR (as it is now, I believe) but, more elegantly, could be a window message instructing users what to do and what they gain (and lose) if they do (or don't). It's not that complicated. Please, send a patch. The code assumes it's there right now (and would crash if it wasn't in the past, hence the previous Depends dependency), feel free to enhance it to support a missing avahi at runtime nicely. So? The whole point of documentation is to tell people how to do stuff. Rhythmbox' section on Share music should start with You need to have installed for this feature to work. That's it. As simple as that. What a nice integration level, while you're at it, mention the ./configure switches. We're talking desktop users here, that is works out of the box. Based on that, you could assume that having more than one computer per household is not all that common. So, I *believe* that your average computer home user is typically going to extract music from CDs (to listen in their computer or on other devices, like MP3 players) more, on average, than sharing with neighbour PCs. You can stop right here, I'm not arguing it's useful on all computers, or even on the average computers. Besides, we're only considering computers where rhythmbox is installed. Now, take a look at Grip (install it), it's an application to extract audio data from CDs. Grip is useless unless you install additional encoders. If you don't have them (and there are in it's Suggests: or Depends:) then the software should instruct you to go and install them. Grip fails to do so properly, and people bug it often. There's no MP3 encoder in the Debian archive, what should Grip do then? This is mixing the MP3 encoder problem with a completely unrelated one. Please install sound-juicer, it will encode Ogg vorbis just fine, and by default. Do you see still think that the argument for the sake of Plug Play, for the sake of the average user should brandished in front of people as an excuse for not doing things properly? You're mixing issues. The fact stuff is patent encumbered and can't enter Debian has nothing to do with the current discussion. It would certainly be nice if we could legally permit people to install MP3 encoders, like MacOSX does. You might as well get the issue documented in the RB BTS if you want, I'll simply link to this thread where I clearly state that I think it's a desirable feature which should be working by default. :) I don't agree with you here and if I get to see avahi being installed in a default GNOME install in Debian and will make damn sure that I get to see it removed. Please do follow your opinions, I have no problem with that. I took the decision of the current deps with my own judgment, and hold to it after what I've read or heard on the subject. I wouldn't oppose any superior ruling to my judgment, which might be technically incorrect. The dep was strict because RB wouldn't start without it. Now it will start, but with a warning. I'm quite sure you can get it to crash if avahi isn't there though, but that's a bug. Then it's a bug, and it should be fixed in RB. Feel free to report it, and to provide a patch. It doesn't change the fact that the Recommends is there for functional reasons. That functionality is not required for most desktop users. Period. For every user you can show up that requires that I can show you
Re: avahi-daemon
On Sat, Mar 04, 2006 at 10:31:02AM +0100, Loïc Minier wrote: And for the same thing, why would a typical desktop machine provide users to share even files! My desktop system at home (and my parent's and my uncle's and whatnot) are completely stand-alone desktop systems, connected to the Internet, with no LAN. They only need to talk to their (serial or USB connected) printer, that's all! Fine, and perhaps you don't even need music sharing on them, but does it still automounts filesystems plugged in USB? :) It's not the same case, not at all. USB filemounts require local access to the system, connecting to a remote daemon does not. There's no paralellism here even if you want to force it. One can't know in advance what uses a system is for, I believe people installing Rhythmbox want to be able to share music by default (easily). You're free to believe the contrary, it's a matter of The truth is that people don't get rhythmbox because they installed it explicitly, they get rhythmbox because they installed 'gnome'. It's just not the same thing. And also: Rhythmbox is a very easy to use music playing and management program which supports a wide range of audio formats (including mp3 and ogg). The current version also supports Internet Radio, iPod integration, Audio CD burning, and metadata editing. There's *nothing* in that description (which is Rhythmbox' package) that implies that Rhythmbox provides music sharing capabilities. Is there? opinion, I gave numerous arguments to my position already, and don't want to talk in loops any further. You don't want it? Don't install it or configure it the way you like. It's not that I don't want it (I don't) I don't want a GNOME install to have it. I don't want user *users* to have a music sharing application they will certainly not need. I'm surprised that the over-bloat of Windows' desktop is now considered to be the good way of doing things. I'd rather have drawn a parallel with Apple software, such as MacOSX, or their Wifi APs. Please have a look at their traffic and open ports next time you get near one of them. Hah! That made me laugh for a bit. Please take a look at MacOS X security record, and their plug and play simplicity. For further reference I suggest you read: http://isc.sans.org/diary.php?storyid=1138 In its default configuration shell commands are executed simply by visting a web site - no user interaction required. http://www.securityfocus.com/brief/152 and http://docs.info.apple.com/article.html?artnum=303382 (take a look at the 'automount' and 'Safari' issues) Yes, plug and play is all fine and dandy, but if you take it to the extreme you get bitten by these bugs. I wouldn't be surprised if people taking the same route (hundreds of developers yelling plug play! plug play!) led the systems they developed to the same consequences (remote exploitable bugs and worms). Regards Javier signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006 at 09:51:31AM +0100, Loïc Minier wrote: On Fri, Mar 03, 2006, Joey Hess wrote: Standard Desktop task installs do not install Recommends anyway, so rhythmbox does not pull in avahi-daemon in those situations and you need to deal with that somehow. It's a but in task installation then. It's not a bug. I'm pretty damn sure that Joey knows what he's doing there. Javier signature.asc Description: Digital signature
Re: avahi-daemon
Hi, On Sat, Mar 04, 2006, Philipp A. Hartmann wrote: Well, since the gnome meta-package is part of the gnome task, which I consider a common default to setup a desktop machine, it get's pulled in in an environment where Recommends are installed automatically. Yup, so the GNOME task pulls it in by default, which means you get the feature and the open port. I think, your proposed solutions do not cover this issue at all. Users, who know what they want and what they are doing, do not run into this problem, since they can manually deselect avahi-daemon. We are indeed talking about regular users. In another mail, you agreed, the maybe only 10% of them want to share music. So, why give another open port to the other 80% (assuming, that 10% of the users know what they are doing ;o)). Ah you're correct, let's make it a Recommends: for the 10% of people wanting to share music, and a Suggests: for the 80% of people having no clue and which will never share music in the life of their system. But still it's only a Recommends. Therefore, rhythmbox needs to handle the absence og avahi-daemon gracefully, since you cannot rely on it's installation. For sake of plug-and-play and comfort, this might be even done in some kind of GUI message, which tells the user what to do, if he/she wants to access a feature, that requires the daemon's presence. It's completely correct to request the proper behavior of RB when the recommends isn't there. I could be very silly, and argue the other way around with something like the current RB code doesn't properly permit using RB without avahi-daemon intalled, and make that a Depend, but since I knew it was causing pain to people wanting a system without avahi but with gnome, and since RB was fixed not to crash when avahi wasn't there, I could downgrade that to Recommends. In other words, RB could be enhanced to work better when the Recommends isn't installed indeed. I don't consider a popup in the application to request installation of packages sensible at all. If you agree on this, there is no reason, to lower the dependency to a Suggests and everybody would be happy. If you still think, that a feature, that is present by default but might be used only by a limited number of users overweighs the possible security implications of another open port, I think we really cannot come to a consensus in this point. It's exactly the way you put, it, we can not come close to a consensus by comparing apples to oranges, security and usability. I must add people on this list are obviously biased towards security. Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Sat, Mar 04, 2006 at 11:07:25AM +0100, Loïc Minier wrote: I'm doing my final pass on the deb-sec part of this discussion, I don't intend to participate much further, no new arguments are popping up. Quite sincerily, this discussion is getting nowhere. There are sufficient arguments in this discussion to drive a truck through a wall, you just don't want to heed them. Some facts: - rhythmbox does not mention music sharing *at*all* in the package description. Even the GUI doesn't mention this (when starting it up for the first time) nor the documentation (in it's 'Introduction') - rhythmbox does not work properly if the discovery service (provided by ahavi-daemon) is not installed [1] - music sharing on the same LAN is not something most desktop users want to do (most households in European countries have a single PC per household) - (history shows...) network services, even if properly designed, are open to exploitation (the all software has bugs corollary) So, IMHO: - a default GNOME install should *not* install a network service, even if that enabled new features to the users. Consequently, if rhythmbox is part of the GNOME task, it should not pull in ahavi-daemon automatically (a Recommends: is automatic for aptitude, not for apt-get, and aptitude is the tool we suggest in our Release Notes for upgrades) - if rhythmbox has to be a part of the GNOME task, it should lower the ahavi-daemon dependency to a Suggests: - rhythmbox should be fixed, if it doesn't work without ahavi-daemon, to popup a window when you try to share music [2] and tell the user what steps it needs to take to enable that I'm CC'ing this to the bug report and open bugs to rhythmbox accordingly. Regards Javier [1] Or so does Loïc Minier say, whileas, I've found that I only see this when starting it up and all the features work just fine for me: (rhythmbox:25826): Rhythmbox-WARNING **: Unable to start mDNS browsing [2] It currently just says this when you set this on the Preferences: (rhythmbox:25826): Rhythmbox-WARNING **: Unable to notify network of music sharing signature.asc Description: Digital signature
Short summary (Was: avahi-daemon)
Hi, I'm stepping out of this discussion, but would like to summarize it a little (this is obviously biased): - the current default situation is on purpose, and is a choice between security and usability, completely subjective - RB can be enhanced to work better when avahi-daemon isn't installed - avahi can be enhanced to have a debconf question permitting to disable it Interested people can file bug reports, submit patches to make progress on the technical issues, disagreeing people can bring this up to the TC for a decision[1], as there's no steering committee as mstone puts it. Other technical enhancements can of course be proposed via the BTS. Cheers, [1] This might sound harsh, but it really isn't, I think it's the role of that committee. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Sat, Mar 04, 2006, Javier Fernández-Sanguino Peña wrote: Rhythmbox is a very easy to use music playing and management program which supports a wide range of audio formats (including mp3 and ogg). The current version also supports Internet Radio, iPod integration, Audio CD burning, and metadata editing. There's *nothing* in that description (which is Rhythmbox' package) that implies that Rhythmbox provides music sharing capabilities. Is there? Of course, you didn't imagine for a second that the description wasn't updated since the introduction of avahi. -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Sat, Mar 04, 2006 at 10:26:31AM +0100, Loïc Minier wrote: My point of view is that installing the application gets them the functionalities they'd expect to find in the default setup. And I agreed that perhaps the rhythmbox community would expect that, which is why I reconsidered and asked for its removal from the gnome task. But you were already pissed off and didn't even seem to give any consideration to the question of whether the rhythmbox community and the gnome community are the same. But you are doing nice in pointing at typical services running on a desktop machine: - apache2 (and will be even more common with gnome-suer-share and DAV file sharing) - samba You think that's part of a typical desktop system? Fascinating. Yes, I think these are often part of a desktop. Often is not the same as should always be installed by default on a common configuration, even if I agreed with the often categorization. If you find my last arguments were specious, let me reformulate them for your reading pleasure: straight: - I believe other apps typically installed on desktop systems are way more dangerous that the big hole people consider opened by avahi *none* of the services you listed are installed by a task that a user would typically select for a desktop system. A person who wants those things has to select them specifically. You have yet to acknowledge that. Concerning your dependencies remarks, I think I've answered to them enough already: this is a Recommends, nothing pulls in rhythmbox from a standard install up to a gnome-desktop-environment install, I proposed dependencies workarounds for most use cases (have a conflict from security packages, use your own meta-package...). You haven't really answered them, you've basically just decided that every gnome user should be a music sharer, and if they don't want it they should go out of their way to avoid it. IOW, instead of a simple, common procedure to install that functionality, you advocate an obscure, complicated one to disable it. Frankly, you're not considering the arguments I gave on dependencies, you even ignored them multiple times already, and since the core of this issue is about dependencies, and the fact that rhythmbox pulls in avahi by default, I'm not inclined to be interested in continuation of this discussion. Umm, I did consider it--that's why I stopped arguing about the rhythmbox dependency. If you feel there's a technical problem with the technical choices of a package or meta-package, bring it as a bug report, linking to this discussion, and if you don't get maintainer's agreement, please bring it to a technical committee. It's really here to help take technical decision where consensus can not be reached. I feel the technical committee is useless in its current form, so I will not be doing so. If someone else wants to, that's fine. I had hoped to simply arrive at some common ground, but you seem to feel that's impossible at this point. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Sat, Mar 04, 2006 at 11:16:08AM +0100, Loïc Minier wrote: I must add people on this list are obviously biased towards security. I guess you can stake out the ground of biased against security, but that's kind of a bad place to be for a software distributor in the 21st century. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Loïc Minier wrote: On Fri, Mar 03, 2006, Joey Hess wrote: Standard Desktop task installs do not install Recommends anyway, so rhythmbox does not pull in avahi-daemon in those situations and you need to deal with that somehow. It's a but in task installation then. If you mean a bug, no, I go out of my way to not install recommends, because Debian is still rife with long and useless recommends chains. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
Philipp A. Hartmann wrote: But still it's only a Recommends. Therefore, rhythmbox needs to handle the absence og avahi-daemon gracefully, since you cannot rely on it's installation. For sake of plug-and-play and comfort, this might be even done in some kind of GUI message, which tells the user what to do, if he/she wants to access a feature, that requires the daemon's presence. If avahi is not running, rhythmbox prints this to std(something) on startup and/or when you enble sharing in its prefs: (rhythmbox:24998): Rhythmbox-WARNING **: Unable to start mDNS browsing (rhythmbox:24998): Rhythmbox-WARNING **: Unable to notify network of music sharing Otherwise it behaves fine. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
Javier Fernández-Sanguino Peña wrote: - rhythmbox does not mention music sharing *at*all* in the package description. Even the GUI doesn't mention this (when starting it up for the first time) nor the documentation (in it's 'Introduction') Rhythmbox doesn't go broadcasting files over the network without being explcitly told to do so in the prefs. It does do mdns discovery of other music shares on the network automatically though. - a default GNOME install should *not* install a network service, even if that enabled new features to the users. Consequently, if rhythmbox is part of the GNOME task, it should not pull in ahavi-daemon automatically (a Recommends: is automatic for aptitude, not for apt-get, and aptitude is the tool we suggest in our Release Notes for upgrades) Does aptitude actually pull in new recommends when upgrading a package? IIRC it did not. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006, Joey Hess wrote: If you mean a bug, no, I go out of my way to not install recommends, because Debian is still rife with long and useless recommends chains. I completely agree there are a number of broken recommends, but shouldn't we fix these? Yes, it's painful. :( -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Loïc Minier wrote: I completely agree there are a number of broken recommends, but shouldn't we fix these? Yes, it's painful. :( I'd prefer not to break new installations in order to find them. This thread shows that pulling in recommends by default in aptitude is enough to expose problimatic recommends chains eventually. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006 at 01:26:24PM -0500, Joey Hess wrote: If avahi is not running, rhythmbox prints this to std(something) on startup and/or when you enble sharing in its prefs: Notice that *most* users will not see this as they will start up rhythmbox from a GNOME application menu and not their terminal. (rhythmbox:24998): Rhythmbox-WARNING **: Unable to start mDNS browsing (rhythmbox:24998): Rhythmbox-WARNING **: Unable to notify network of music sharing Otherwise it behaves fine. Yes it works. But check out '#355238: rhythmbox: A user cannot see why he cannot share music', there's something interesting in my bug report. The funny thing is that, even if the maintainer claims that this is a requierement, something that most people will want to use and blah blah: a) is not properly documented (see bug #355234), not even in the application documentation! b) it comfounds users, since a user that *does* wants to share music will enable it, the GUI marks it at enabled and does *not* work So much for plug and play and user friendliness, huh? Javier signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006 at 11:32:20AM +0100, Loïc Minier wrote: On Sat, Mar 04, 2006, Javier Fernández-Sanguino Peña wrote: Rhythmbox is a very easy to use music playing and management program which supports a wide range of audio formats (including mp3 and ogg). The current version also supports Internet Radio, iPod integration, Audio CD burning, and metadata editing. There's *nothing* in that description (which is Rhythmbox' package) that implies that Rhythmbox provides music sharing capabilities. Is there? Of course, you didn't imagine for a second that the description wasn't updated since the introduction of avahi. Which I'm surprised, since the introduction of avahi was a fundamental change. Moreover, there is not a slightest note in the (upstream) documentation or the README.Debian about music sharing and avahi. (for those that are not the maintainer, see #355234) I'm *very* surprised that this kind of change, which you tout as fundamental for the package and which, at some point, prevented the program from working at all is not documented anywhere in the package or upstream. Regards Javier signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006 at 01:41:14PM -0500, Joey Hess wrote: - a default GNOME install should *not* install a network service, even if that enabled new features to the users. Consequently, if rhythmbox is part of the GNOME task, it should not pull in ahavi-daemon automatically (a Recommends: is automatic for aptitude, not for apt-get, and aptitude is the tool we suggest in our Release Notes for upgrades) Does aptitude actually pull in new recommends when upgrading a package? IIRC it did not. Well, since rhythmbox is part of the gnome task, and it was already included in the gnome meta-package in sarge I guess you are correct (now). However, for sid users, notice that rhythmbox depended on avahi-daemon from version 0.9.2-3 (2006-01-22) until version 0.9.3-1 (2006-02-05). So, any sid user that upgraded his system (even from sarge or etch) in those two weeks (from January the 22nd to February the 5th) they *will* have avahi installed regardless. Also, any user that does a limite install and then installs the gnome meta-package (not the gnome-desktop task with tasksel) will pull in avahi too. Regards Javier signature.asc Description: Digital signature
Re: Internal trusted networks? (was Re: avahi-daemon)
On Sat, Mar 04, 2006 at 10:12:56AM +0100, Loïc Minier wrote: But you're still way more secure while sitting behind a NAT with responsible coworkers than connected to the Internet directly, without any firewall, and that's where desktops sit most of the time. Well, a NATed gateway is not that common for some desktop systems: - home users using bridge Internet connections (some cable companies provide cable-modem that act as a bridge) - dialup users (yes, there are still those kind of users) Regards Javier signature.asc Description: Digital signature
