linux-kernel - Re: Linux 2.6.21

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Apr 2007 09:54:29 +0200
From:	Matthias Andree <matthias.andree@....de>
To:	Indan Zupancic <indan@....nu>
Cc:	Johannes Stezenbach <js@...uxtv.org>, Adrian Bunk <bunk@...sta.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Diego Calleja <diegocg@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.21

On Mon, 30 Apr 2007, Indan Zupancic wrote:

> I don't know, but what about telling the hapless person who went
> through the process of posting a bug what's wrong with the bug report?

It's a tedious process you keep doing over and over and over and over again,
and my experience shows it's sheer luck if people can actually fill in
the missing bits given the list.

Usually you have to ask thrice to obtain even the most essential
information such as version. Let alone vendor patches.

Anyways, the solution to this problem is someone _politely_ asking
reporters to provide necessary information and also point out that they
cannot ever hope to have their bug fixed without making a best-effort
attempt at answering all questions the first time they're being asked.

There are notable exceptions, people pinpointing code fragments at fault
and everything, but those are usually tech people and not end users.

> That said, if someone is an obvious idiot, ignoring saves time. But I
> think that's quite rare, and in general you should give the reporter
> feedback, and then ignore the bug report. (Until it improves.)

And that is what happens all too often (not in absolute figures, but in
the developer's perception of it) - insufficient information to debug.

Yes I know, some of the bugs hide themselves so well you actually need
four or five reports by different people to actually pinpoint the bug,
perhaps accompanied by insufficient interface documentation that make it
difficult to verify assumptions/expectations or assess potential
solutions (such as the res_init() issue in fetchmail, or probably the khubd going
south issue in Linux), but that's not the point.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/