Alexander Kurtz <kurtz.a...@googlemail.com> wrote: Hi,
> If my message has been FUD, I'm really sorry for that. However I believe > that there are a few things we should be talked about (calmly). Hey, you're the one reopening an old, closed and archived bug report for a bug that has been properly fixed, mixing several other "issues" in the same report and WRITING IN CAPS. Not to mention your post to -security on which I'm not even Cc:ed. >> 1. is bullshit, > I agree that one can argue about that point. It is certainly necessary > for some users to configure mt-daapd remotely. However, can you please > explain me, why this is enabled by default? CUPS is also reachable from > localhost only, in it's default setting, but I'd bet that one can > configure this. Just like CUPS, the interface is served over the same port that's used for client queries & streaming. Filtering the interface (only) out would be invasive and awkward. What should be added is: - selection of the interfaces to bind to, - IP ACLs. That's been a wishlist with upstream for months if not years. >> 2. is debatable, but really not a big deal either, it's a matter of >> policy, > As you said, it's a matter of policy. However, predictable passwords are > never good, are they? The password has to be changed, and the config file has to be edited to set the music library path anyway. It's *really* no big deal. >> 4. is wrong on the permissions, correct on the plaintext password. > You are right. But I still think that a hashed pw would be _better_. Of course it would. > It _might_ be even better to take the root pw like CUPS does. The password is transmitted in clear text (basic auth, base64) over HTTP, I don't think you want to use your root password for that. Really. Supporting a better auth mechanism in mt-daapd is highly desirable, and this has to be planned together with the password storage. You don't want to hash the password with a hash that's not usable with your auth mechanism :) SHA1 password hash and Digest with SHA1 as the algorithm have my preference for that. > I wanted to thank you for your immediate response. I hope we will find a > good solution together, but even if we don't we have at least discussed > the problem which is always better than not discussing it. There's no immediate solution with mt-daapd in its current state. It's not worth investing time in patching the current code. I'll take patches, though. Be careful if you venture in that code, there are anvils hanging up about everywhere, looking for a good target to drop on. JB. -- Julien BLACHE <jbla...@debian.org> | Debian, because code matters more Debian & GNU/Linux Developer | <http://www.debian.org> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
