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. > 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. For me this means the package can't be used in my environment (I don't have plans to use iptables on this machine, all other services work correctly without external crutches). Keeping this bug as a wishlist to have real control on such a simple thing seems appropriate. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
