public inbox for bzip2-devel@sourceware.org
 help / color / mirror / Atom feed
From: Jeffrey Walton <noloader@gmail.com>
To: Mark Wielaard <mark@klomp.org>
Cc: bzip2-devel@sourceware.org, Julian Seward <jseward@acm.org>
Subject: Re: bzip2 1.0.7 released
Date: Tue, 01 Jan 2019 00:00:00 -0000	[thread overview]
Message-ID: <CAH8yC8mSVCfgnd3joj-FB1MjK5VrtAWP3tNEYhA8sCf5KEf4KQ@mail.gmail.com> (raw)
In-Reply-To: <20190627205837.GD9273@wildebeest.org>

On Thu, Jun 27, 2019 at 4:58 PM Mark Wielaard <mark@klomp.org> wrote:
>
> On Thu, Jun 27, 2019 at 08:54:08PM +0200, Mark Wielaard wrote:
> > * Make sure nSelectors is not out of range (CVE-2019-12900)
>
> Well, that was quick... There is already a regression report about
> this fix. See https://bugs.launchpad.net/ubuntu/+source/bzip2/+bug/1834494
> ...
>
> -#define BZ_MAX_SELECTORS (2 + (900000 / BZ_G_SIZE))
> +#define BZ_MAX_SELECTORS (7 + (900000 / BZ_G_SIZE))
>
> But of course I cannot tell why increasing the max with 5 is correct.
> It might well be that the file is invalid. Before the fix bunzip2
> would overwrite some memory after the selectorMtf array. So it might
> be the file decompressed by accident in the past.
>
> I'll look a but deeper, but if people have a clue what exactly is
> going on that would be appreciated.

Hi Mark.

At this point, I think you should perform the root cause analysis.

I think you are having trouble identifying the the problem(s) because
the code is not instrumented, and it does not debug itself. It
requires manual intervention and time under the debugger. Time under a
debugger is mostly a waste of time in my opinion. You have better
things to do with your time.

If this were my module, then I would fill the program with ASSERT's so
the module debugs itself in non-release builds. Then, run all the
malformed test data you can find.

The good thing about instrumenting with asserts is, it is monkey work.
You can task an intern with it, and not waste a senior dev's time with
it. Even better, the intern can then identify the problems so you
don't waste your time with it.

I know assert's are not preferred in the Unix world. Many Unix dev's
prefer to cling to the old K&R way of writing code from the 1970's.
But there are a lot better ways to develop nowadays, and self
debugging code is one of them.

(This is really a policies and procedures problem. The development
process has gaps. The fix is to require completely instrumented code.
But to do that, you have to deal with the political problem of people
clinging to ancient K&R patterns).

Jeff

      parent reply	other threads:[~2019-06-27 21:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-01  0:00 Mark Wielaard
2019-01-01  0:00 ` Mark Wielaard
2019-01-01  0:00   ` Federico Mena Quintero
2019-01-01  0:00   ` Mark Wielaard
2019-01-01  0:00     ` Federico Mena Quintero
2019-01-01  0:00       ` Julian Seward
2019-01-01  0:00         ` Mark Wielaard
2019-01-01  0:00           ` Mark Wielaard
2019-01-01  0:00             ` Federico Mena Quintero
2019-01-01  0:00               ` Mark Wielaard
2019-01-01  0:00           ` bzip2 test suite (Was: bzip2 1.0.7 released) Mark Wielaard
2019-01-01  0:00           ` Alternative nSelectors patch " Mark Wielaard
2019-01-01  0:00             ` Julian Seward
2019-01-01  0:00               ` Mark Wielaard
2019-01-01  0:00                 ` Mark Wielaard
2019-01-01  0:00   ` Jeffrey Walton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH8yC8mSVCfgnd3joj-FB1MjK5VrtAWP3tNEYhA8sCf5KEf4KQ@mail.gmail.com \
    --to=noloader@gmail.com \
    --cc=bzip2-devel@sourceware.org \
    --cc=jseward@acm.org \
    --cc=mark@klomp.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).