Bug#340375: Subject: kuser destroys all passwords if /etc/shadow isn't present
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?
Reply to: