- Dillo-dev - lists.mailman3.com

Fuzzing dillo

by corvid＠lavabit.com

Jeremy wrote: > html.cc looks like a C file that was subsequently converted to C++ > because it makes little use of C++. If DilloHtmlForm and > DilloHtmlInput were given constructors and destructors and managed > with new and delete then lots of allocation/deallocation code would be > neatly factored out instead of sitting inline with all the other > logic. > > The type element of DilloHtmlInput leads to much horrible case code. > If DilloHtmlInput were an abstract class and the different Input types > were subclasses then all the type-dependent code could go into virtual > methods. This would break up the huge case statements that make much > of this code hard to follow. It's at least definitely worth trying, I think.

May 26, 2008

patch: goodbye to use_oblique and transient_dialogs

by jcid＠dillo.org

On Sun, May 25, 2008 at 08:19:05PM +0000, corvid wrote: > It's nice to get to delete things, and especially preferences, > since they have a natural tendency to grow and grow and grow. Committed. -- Cheers Jorge.-

May 26, 2008

remaining preferences

by jcid＠dillo.org

On Sun, May 25, 2008 at 08:32:02PM +0000, corvid wrote: > Jorge wrote: > > On Sat, May 24, 2008 at 07:28:47PM +0000, corvid wrote: > > > # Set this to YES, if you want to limit the word wrap width to the vieport > > > # width (may be useful for iPAQ) > > > limit_text_width > > > > > > It doesn't do anything. I don't think it's ever done anything. > > > It sure would be nice if it did something. But I don't have the expertise > > > to change that. > > > > For instance: Some times HTML pages for mailing lists render > > one looong line for a message. The MUA packs the message as a > > single line and the mail2html filter wraps it with PRE. AFAIR the > > SPEC said original formatting was to be honoured in PRE, but > > browsers, in practice, tend to wrap it. Sometimes you need one > > behaviour and then another. > > Are you saying that it does this, or that the intention is for it to do this? The intention is for it to do this. -- Cheers Jorge.-

May 26, 2008

remaining preferences

by corvid＠lavabit.com

Jorge wrote: > On Sat, May 24, 2008 at 07:28:47PM +0000, corvid wrote: > > # Set this to YES, if you want to limit the word wrap width to the vieport > > # width (may be useful for iPAQ) > > limit_text_width > > > > It doesn't do anything. I don't think it's ever done anything. > > It sure would be nice if it did something. But I don't have the expertise > > to change that. > > For instance: Some times HTML pages for mailing lists render > one looong line for a message. The MUA packs the message as a > single line and the mail2html filter wraps it with PRE. AFAIR the > SPEC said original formatting was to be honoured in PRE, but > browsers, in practice, tend to wrap it. Sometimes you need one > behaviour and then another. Are you saying that it does this, or that the intention is for it to do this?

May 25, 2008

patch: goodbye to use_oblique and transient_dialogs

by corvid＠lavabit.com

It's nice to get to delete things, and especially preferences, since they have a natural tendency to grow and grow and grow.

May 25, 2008

remaining preferences

by jcid＠dillo.org

On Sun, May 25, 2008 at 08:24:58PM +0200, Johannes Hofmann wrote: > On Sun, May 25, 2008 at 10:51:47AM -0400, Jorge Arellano Cid wrote: > > <snip> > > > > > Somebody using ION may check this. > > > > Works ok as it is. The dialog windows are placed over the bottom of > the main window. A bit like the new search bar. A quite nice concept > actually. > So I think the preference option can safely be removed. Great. Patch is welcomed! :-) -- Cheers Jorge.-

May 25, 2008

Fuzzing dillo

by jcid＠dillo.org

On Sun, May 25, 2008 at 08:14:29PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jorge Arellano Cid wrote: > > On Sun, May 25, 2008 at 01:12:38PM +0200, Justus Winter wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Hi :) > >> > >> I was playing around with Michal Zalewskis html fuzzer 'mangle' trying > >> to crash dillo and succeeded :). > > > > Good. > > > > It's no surprise because dillo2 needs a careful review of > > behaviour when facing strange/malicious values. Obviously this > > phase was procrastinated until basic functionality was completed. > > > > For instance, most probably you'll get to crash dillo2 by > > passing it some negative values in attributes. The problem of > > being robust when parsing garbage or malicious code needs a > > general strategy. > > Are you saying that it is too early to locate problems this way? No! It was too early, now dillo2 has almost all dillo1 had and more. Now it's a good time. What I meant is that a general strategy for these cases is better than a case by case approach. > The > process of finding problems using a fuzzer and generating minimal > testcases that trigger the problem is mostly automatic and I could > script the last bits that do require manual intervention with ease. > > In case these bug reports are useful at this point, here is another one: > > In file html.cc, function Html_tag_close_select: > > int size = input->select->options->size (); > > fails since input->select is NULL. The html fragment that triggers this > fault is attached. > <HEAD><FORM><SELECT><TEXTAREA> This is the same non-authorized element inside SELECT. It can be catched with the solution described in my last post. It'd be good to have the test cases. Go ahead. -- Cheers Jorge.-

May 25, 2008

[BUG]: Redirect to previous page + Reload crashes

by jcid＠dillo.org

On Sat, May 24, 2008 at 03:22:10AM +0000, corvid wrote: > Jeremy wrote: > > Dillo crashes as follows: > > * Point Dillo at http://starurchin.org:8080/dillo/here > > * Click the "There" link. Dillo is redirected back to the "Here" > > page. > > * Click the "Reload" button. > > * Dillo crashes inside a_Nav_reload() (nav.c) at the line "if > > (URL_FLAGS(url) & URL_Post) {" because url is NULL. > > > > I noticed this a few weeks ago but only just found a simple way to > > trigger it. Any ideas why this is happening? > > The problem went away when I tried the attached change, > but I may be treating the symptom rather than the disease. > > It must not be the result of a very recent change, because I > have a dillo from April 8 that crashes doing this. > > diff -pur dillo2/src/nav.c dillo2-cur/src/nav.c > --- dillo2/src/nav.c 2008-05-10 20:02:22.000000000 +0000 > +++ dillo2-cur/src/nav.c 2008-05-24 03:03:50.000000000 +0000 > @@ -185,6 +185,8 @@ static void Nav_stack_clean(BrowserWindo > void *data = dList_nth_data (bw->nav_stack, i - 1); > dList_remove_fast (bw->nav_stack, data); > dFree(data); > + if (bw->nav_stack_ptr >= a_Nav_stack_size(bw)) > + bw->nav_stack_ptr = a_Nav_stack_size(bw) - 1; > } > } > Committed. -- Cheers Jorge.-

May 25, 2008

patch: Re: [Dillo-dev] Fuzzing dillo

by jcid＠dillo.org

On Sun, May 25, 2008 at 02:41:32PM +0000, corvid wrote: > Justus wrote: > > I was playing around with Michal Zalewskis html fuzzer 'mangle' trying > > to crash dillo and succeeded :). Furthermore I was able to reduce the > > ~100k page that was triggering a NULL pointer dereferencing to three > > tags (see the attached page). > > > > Some digging around (html.cc is a monster ^^) revealed that > > > > style_attrs.setBorderColor ( > > Color::createShaded(HT2LT(html), > > style_attrs.backgroundColor->getColor())); > > > > in Html_tag_open_table was failing due to the fact that > > style_attrs.backgroundColor was NULL. > > > > Html_tag_open_select sets the backgroundColor to NULL and this is > > inherited by the table tag since it's a child of the select tag. > > I doubt I realized you can try to put things like tables inside selects > back when I wrote that. > > Maybe Jorge will know something easy and general that can be done based > on parse modes to keep dillo from wasting its time calling things like > Html_tag_open_table that aren't going to be displayed anyway, but the > attached patch at least fixes the crash. SELECT can be closed in Html_stack_cleanup_at_open(). SELECT can contain OPTGROUP and OPTION. It would be good to consider the other cases before making a patch. -- Cheers Jorge.-

May 25, 2008

remaining preferences

by jcid＠dillo.org

On Sun, May 25, 2008 at 07:02:53PM +0200, Johannes Hofmann wrote: > On Sun, May 25, 2008 at 10:51:47AM -0400, Jorge Arellano Cid wrote: > > <snip> > > > > > > # Enabling this will restrain OpenUrl and FindText, but may be required > > > # for the ION window manager. > > > transient_dialogs > > > > > > from fltk::Window::child_of(): > > > Tell the system that this window will not have an icon, it will > > > dissappear and reappear when \a parent is iconized or shown, and it > > > is forced to always be above \a parent. On X this is called a > > > "Transient window", and Windows calls this a "overlapping child". \a > > > parent is different than the parent(), which must be zero. > > > (and down in fltk::CreatedWindow::create, there's a > > > if (window->child_of() && window->child_of()->shown()) > > > XSetTransientForHint(xdisplay, x->xid, window->child_of()->i->xid);) > > > > > > If Justus gets rid of the dialogs, obviously the pref can be removed. > > > Enabling this means making our own dialogs for message(), choice(), input(). > > > > Somebody using ION may check this. > > Just searched my email. I had requested that feature some time ago - > well, it was Nov 2001 ;-) > I no longer use ion, but I will check how it works with current > dillo. The file dialogs are the only that will stay, right? We have choice5, message and maybe another. If ION works OK with FLTK2, it's OK to remove the preference. If not, I wouldn't assign high priority on it. -- Cheers Jorge.-

May 25, 2008