On Thu, Dec 11, 2014 at 08:00:28PM +0100, Goswin von Brederlow wrote: > On Tue, Dec 09, 2014 at 03:34:43PM +0000, Mark Brown wrote:
> > Please don't inflate severities pointlessly; there are simple solutions > > to this like changing passwords by logging into a specific system to do > > so which people will doubtless have adopted in the decade or so this has > > been present if they are affected. > 1) What system? The segfault always happens on every system. You simply > can not change your nis password at all. The normal thing I've seen is to have people log onto the master server (or make some similar arrangement) and make the change there. > 2) And it hasn't been a decade. It was reported a bit over a year ago. > 3) I first noticed this failing on Ubuntu recently while the nis > upstream version is indeed been around for ages. It used to work > previously with near identical version. So unless you changed > yppasswd.c in one of the debian revisions this probably is triggered > by a change in the crypt() implementation that is more recent, one > that validates the salt properly. There's definitely not been any substantial change in nis for some considerable time, the last non-packaging change I'm seeing in the changelog is about five years old and is in wheezy. > 4 ) This is a security issue so raising the severity is not pointless. > Users need to be able to change their password. Especially the initial > one set by the admin on account creation. It's not clear to me that this is something that has been newly introduced (as opposed to something people have always dealt with when using NIS, the version mentioned is the one in wheezy) - using shadow files with NIS is obviously a bit of a corner case given how meaningless NIS makes the extra security they add. If it's something that's just broken in this version and people would see regress on upgrades that's a bit different. I could probably go for important but given both the failure mode and the fact that it looks like this was an issue on the prior release it seems it does more harm than good to remove the package. > 5) There has been a trivial 1 line patch for the bug for the whole > time. Right, it's unfortunate that I didn't see that on the original filing (looking at the mail it appears it got hidden as a signature by the mail client I used to read the original submission, the mail is sadly a bit malformed which doesn't help).
signature.asc
Description: Digital signature
