On Sun, Aug 24, 2008 at 10:05:30PM +0400, Dmitry E. Oboukhov wrote:
> Package: initramfs-tools
> Severity: grave

> This message about the error concerns a few packages at once. I've
> tested all the packages (for Lenny) on my Debian mirror. All scripts
> of packages (marked as executable) were tested.

This is far below the quality I expect from a mass bug filing that's been
reviewed by debian-devel. Mass bugfilings at RC severity need to be held to
a much higher standard than this, particularly when we're in the middle of a
release freeze.

It was certainly not my impression that "Possible mass bug filing" as a
subject line meant that bug reports were imminent.

Problems with this report:

- the justification for "grave" severity is that it's a security hole, but
no "security" tag was set
- information is available about what versions are affected, but no Version:
pseudoheader is set
- the contents are 100% generic and requires the maintainer to search
through a list of packages/files to find out what script is supposed to be
vulnerable
- there is no information in the bug report about the /methodology/ used to
detect vulnerable scripts, leaving the maintainer no opportunity to
provide feedback about bugs in said methodology

and finally,

- this bug report is a false positive. /usr/share/initramfs-tools/init is a
script installed in the initrd, which is a single-user context; there's no
possibility that this is exploitable.

Please take responsibility for providing the missing information to the
package maintainers, and for correcting the false positives that you've
filed.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Quoting Steve Langasek (vorlon@debian.org):

> This is far below the quality I expect from a mass bug filing that's been
> reviewed by debian-devel. Mass bugfilings at RC severity need to be held to


Even though I overread the thread when Dmitry posted his intent to
-devel, I feel like there was *no* strong agreement that this MBF was
really wished and welcomed.

I should also have added that I personnally strongly object to it for
three reasons:

- timing wrt the release
- timing wrt the "half of the developers are VAC" status we generally
have in August
- the obvious lack of preparation

It may sound like acting against the "we will not hide problems" item
in the Social Contract, but I wouldn't be shocked if *all* these RC
bugs are downgraded to important (I would even downgrade them to
wishlist, see the example that made Neil react).

If I come on any such bug on packages I maintain or co-maintain, I
will immediately downgrade the bug report in such way, mentally
thanking the bug submitter for the extra work and ranting about yet
another nice method to delay the release.

TK>> Quoting Steve Langasek (vorlon@debian.org):
TK>>> This is far below the quality I expect from a mass bug filing that's been
TK>>> reviewed by debian-devel. Mass bugfilings at RC severity need to be held
TK>>> to
TK>>
TK>> Even though I overread the thread when Dmitry posted his intent to
TK>> -devel, I feel like there was *no* strong agreement that this MBF was
TK>> really wished and welcomed.

TK> Yes, this mass bug filing is of bad quality and should not have happened as
TK> such. However:

TK>> If I come on any such bug on packages I maintain or co-maintain, I
TK>> will immediately downgrade the bug report in such way, mentally
TK>> thanking the bug submitter for the extra work and ranting about yet
TK>> another nice method to delay the release.

TK> I would like to ask maintainers not to do this. I've quickly checked just a
TK> number of these bugs and, between the false positives, already found a
TK> handfull of genuine, true positive issues. Checking where the bug comes from
TK> usually doesn't take a lot of time, so while I share the annoyance, you are
TK> already annoyed, so better turn it into something useful by double-checking
TK> the code rather than downgrading them out of hand.

Thank You for your encouragement

More 10 packages already patched and uploaded

All, please again, be understanding to possible mistakes.
--

. '`. Dmitry E. Oboukhov
: :’ : unera@debian.org
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537

On Mon, 2008-08-25 at 10:09 +0200, Thijs Kinkhorst wrote:
> On Sunday 24 August 2008 22:00, Steve Langasek wrote:
> > Please take responsibility for providing the missing information to the
> > package maintainers, and for correcting the false positives that you've
> > filed.
>
> Yes, please. I think the only way the damage of this bad bug filing can be
> mitigated is if you, Dmitry, review all bugs you filed and provide for each
> bug the exact piece of code that you think has the problem and an assessment
> of the exploitability in the context of the specific package.
>
> I expect you start working on this immediately?

It might be best to first downgrade (if not close) all bugs filed under
the first attempt so that packages are not removed from testing in the
time it will take to reassess the actual risk from the pattern matches.

Once you have added to the bug report specific information on the
precise piece of code that can be shown to be used in the normal use of
the program and in such a way as to be available, by default, on a
multi-user system, then you can think about raising the severity again.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

On Mon, 2008-08-25 at 10:09 +0200, Thijs Kinkhorst wrote:
> On Sunday 24 August 2008 22:00, Steve Langasek wrote:
> > Please take responsibility for providing the missing information to the
> > package maintainers, and for correcting the false positives that you've
> > filed.
>
> Yes, please. I think the only way the damage of this bad bug filing can be
> mitigated is if you, Dmitry, review all bugs you filed and provide for each
> bug the exact piece of code that you think has the problem and an assessment
> of the exploitability in the context of the specific package.
>
> I expect you start working on this immediately?

One further suggestion - use usertags. You should make it easy for
others to check the overview of the mass bug filing by using usertags in
the BTS to create a single page that lists all the bugs and only the
bugs from the mass bug filing.


--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Le Mon, Aug 25, 2008 at 07:16:00AM +0200, Christian Perrier a écrit :
>
> - timing wrt the release
> - timing wrt the "half of the developers are VAC" status we generally
> have in August
> - the obvious lack of preparation

In addition, security issues should better be reported upstream first so
that all the distributions have a chance of providing corrected versions
when the details are made public…

Have a nice day,

--
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org