severity 340375 important stop Since this bug is largely fixed in Sid, but not so totally resolved that I'd want to attach a "fixed" tag, I think the best course of action is to lower the bug to important, but keep it open. In any case, the bug isn't a regression with respect to what's in Etch at the moment.
Cheers, Christopher Martin On Saturday 17 December 2005 14:57, Christopher Martin wrote: > On Tuesday 22 November 2005 20:23, Charles G Montgomery wrote: > > Subject: kuser destroys all passwords if /etc/shadow isn't present > > Package: kuser > > Version: 4:3.4.2-1 > > Severity: grave > > Justification: renders package unusable > > Hello, > > I forwarded the issue upstream, and a check was added for the /etc/shadow > file in the KDE 3.5 branch. The kdeadmin upload that should clear NEW and > be in experimental shortly contains this fix. However, as you noted > yourself, this doesn't completely resolve the issue, since /etc/shadow > could be present but shadow passwords still not in use. > > Upstream seems to be under the astonishing impression that the ability to > disable the use of shadow passwords by clearing "/etc/shadow" from the > shadow file text field in Configure KUser is intuitive and clear to > users. Even the check for /etc/shadow was added reluctantly, and upstream > has stated that he has no intention of adding further checks. > > So what to do? Having /etc/shadow but not using shadow passwords is > probably a pretty rare configuration. We could add a README.Debian to > warn users of this quirk, but there is no guarantee that people would > read it. > > Any ideas, comments, suggestions from the team? Should the bug remain RC > once 3.5 enters unstable? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]