Hello Michael, On Mon, 15 Jun 2015 10:42:00 +0300 Michael Tokarev <m...@tls.msk.ru> wrote:
> 15.06.2015 01:58, Alexander Gerasiov wrote: > > Hello Michael, > > > > On Sun, 14 Jun 2015 16:49:23 +0300 > > Michael Tokarev <m...@tls.msk.ru> wrote: > > > >> Package: minidlna > >> Version: 1.1.2+dfsg-1.1+b3 > >> Severity: important > >> > >> When specifying (uncommenting) option listening_ip in the config > >> file, minidlnad says: > >> > >> parsing error file /etc/minidlna.conf line 70 : > >> listening_ip=192.168.88.4 > >> > >> and ignores this line, listening to the whole 'net. > >> > >> This means that it is impossible to bind it to particular > >> (internal) ip address, even after using the only option for this > >> which is documented and appears to be available. Obviously this > >> has security implications, due to both lack of the way to secure > >> it and having too wide access when operator thinks it is secured. > > Mmm, this is not a bug in software anyway. And not a security issue. > > You're still free to protect yourself using iptables. > > This is a completely wrong approach. First we make something open > much wider than needed, next we say there's a way to block the open > door by using other means. The right approach is to not open the > door in the first place where it isn't supposed to be open. This is philosophy =) From other point one can say, that unix way is to use many simple tools each solving it's simple task. Door to enter and guard dog to bite strangers =) I agree, that it would be better (in this particular case) to have working solution in minidlna, but it's absence (if it really has a place in) is not a security bug anyway. > > > Is this a bug in documentation? - yes > > Is this bug closed in testing? - yes > > Should this bugreport be closed? - I think yes, feel free to prove > > your point. > > > > PS How do you see this report closed in right way? > > I think the functionality should be reimplemented. I don't think this > bug should be colsed, instead maybe keep it as a wishlist item wishing > that real measures to be implemented instead of relying on external > blocks. > > When I submitted this bugreport I did't know upstream dropped this > functionality, I thought it is just some minor prob in parsing the > options. So ofcourse I didn't know it is just documentation bug in > current package. Anyway, I think removing this functionality is > inacceptable, because it is the wrong approach as described above. Look. There is a bug in 1.1.2: (Fixed in 1.1.4) #756169 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756169 -a option and listening_ip config parameter were replaced with -i interface Network interface to listen on. Can be specified more than once. network_interface Network interface(s) to bind to (e.g. eth0), comma delimited. This option can be specified more than once. If unspecified or empty, minidlnad binds to all the valid network interfaces (except loopback). But there are some questions with them. See #786929 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786929 http://sourceforge.net/p/minidlna/bugs/218/ (Still open as wishlist) In your bugreport you mix two different already reported problems. So I merge your bugreport into first one. -- Best regards, Alexander Gerasiov Contacts: e-mail: g...@cs.msu.su Homepage: http://gerasiov.net Skype: gerasiov PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
