Re: Stop reporting non-bugs as bugs!
John Goerzen wrote:
>
> There are a number of non-bugs reported as bugs in cfingerd (see
> http://www.debian.org/Bugs/db/pa/lcfingerd.html). All were reported
> by jbj@image.dk.
>
> One thing that REALLY bothers me is that each bug he reported contains
> this at the end:
>
> "This message is hastily written . . . Its contents may be
> deliberately or accidentally untrue."
>
> Deliberately untrue??? When reporting a bug?
>
This is my standard tagline, it is intended to fight off lawyer types
who might claim that I "should" have known something was untrue, it
doesn't mean I'm a habitual liar.
>
> Now let me say that I have no problem with people reported bugs that
> they encounter. However, I DO have a problem with people reported
> bugs that they have NEVER encountered (see #24902, he never actually
> tried upgrading it but claimed it didn't work) or bugs that may
> THEORETICALLY exist after examining the source but may not really
> exist. I feel that this is what has been happening here.
Ok, one or two were a little far fetched, I would not have bothered
if I had not found the others.
>
> One other thing -- bugs he reported are the only things holding up
> hamm -- yet they may be "untrue". This sounds very suspicious to me.
> On the one labeled "Critical", he even refuses to give any details.
I did already (after less than two hours) send the details to the
maintainer. The reasons I did this is in the report.
As for holding up hamm, that was never my intention, but this was
labeled beta, so I thought intensive testing was desired.
>
> Now let's take a look at most of the other bugs:
>
> Let's cover them.
>
> #24895
>
> The submitter complains that all users can be listed using
> documented features.
>
> OF COURSE THEY CAN. This is what finger is supposed to do!
>
> The rest of the problem mentioned offer no justification
> or confirmation of the problem or cases where it is encountered.
This is a summary post, please refer to all the other reports
for details.
>
> #24902
>
> The submitter complains that cfingerd ignores an
> existing config file on upgrade.
>
> This is totally false. cfingerd's preinst detects an existing
> config file in the old location if doing an upgrade.
>
> DOING AN INSTALL IS NOT THE SAME AS DOING AN UPGRADE.
>
I *did* put in an apology in case my testing was flawed.
The exact sequence of events was:
I upgraded wholesale to hamm.
I found two cfingerd.conf files on my system.
I read the changelog.
I devised a simplified procedure to test if the bug was
still there.
I applied the test to the latest package release (repeatedly).
*then* I posted.
> #24907
>
> The submitter complains that cfingerd reveals Debian version.
>
> * So does Apache
> * And boa
> * and sendmail
> * and uname
> * and more...
>
> This is NOT a bug. I fail to understand how it could even
> be remotely contrued as such.
I consider it a bug, because the documentation brags about its ability
to hide information and because such hiding tactics is part of
*my* security policy.
I would not have complained if this was the only cfingerd bug.
>
> #24908 complaints that cfingerd runs programs from path.
>
> This is not a problem because cfingerd is started from inetd in
> Debian, so the path is KNOWN GOOD.
>
This is one of those far-fetched ones. It was found when tracking down
other issues and is reported because the documentation suggests
different behaviour, by showing off all the places where this does
not happen.
> #24909 complains that cfingerd reveals it is cfingerd.
>
> So what? And it's hardly a "back door" as the submitter reports.
>
> Most daemons reveal their name and version number.
It is a back door because its existence is not documented (without
my documentation patch that is).
>
> #24899 complains that the configuration refuses connections from
> machines with no identd.
>
> Not a bug. Modify the configuration.
>
I am complaining about a bad default, which is part of the package.
> #24897 has changes to documentation. Not a bug. Send it upstream.
>
The documentation is part of the package, the bug-reporting policy
suggests including a fix if possible. So I did. There is no known
alternate method for reporting bugs in documentation.
As for upstream, all recent development has been done by the
Debian maintainer, and released as a Debian package.
> Now then, that leaves two bugs that may indeed be serious (one of
> which doesn't have any useful information in it, the other seems to
> have a misunderstanding of the setuid mechanism) and one or two that I
> skipped because I'm not familiar enough with cfingerd's extra features
> to comment.
As for the setuid stuff, it seems the original developer got it
wrong. The package claims running all external programs as
nobody, but leaves the real uid set to root, which allows the script
to double back as illustrated. Source code comments say that this
will happen, but the documentation says the opposite.
By the time I send this, independent confirmation has been posted,
and the bug has been closed, because the closer believes the
consequences to be less serious than I do. I bow to his opinion.
>
> I do not mind, and indeed ENCOURAGE, the submission of bugs that
> really are bugs (as the claimed buffer overflow would be). However, I
> DO mind when people submit numerous non-bugs.
>
> --
> John Goerzen Linux, Unix consulting & programming jgoerzen@complete.org |
> Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org |
> ----------------------------------------------------------------------------+
> Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
--
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: