October 2008 - Dillo-dev - lists.mailman3.com

what crashes remain?

by Johannes.Hofmann＠gmx.de

Hi, On Wed, Oct 01, 2008 at 10:33:20AM -0400, Jorge Arellano Cid wrote: > Hi, > > On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > It's still possible to crash dillo if you click on a remote link and > > > quickly click on some images to load them. Doesn't crash every time, > > > but typically within four tries or so. I had assumed it was the same > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > If I stick > > > a_Bw_stop_clients(bw, BW_Img); > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > earlier today, so there's something wrong with just doing that. > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > That message means big trouble: the event loop stepped over itself... > > > > I've tried several different ways but can't get to crash it. > > > > Does the attached patch help? > > > > -- > > Cheers > > Jorge.- > > > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > > */ > > void DilloHtml::loadImages (const DilloUrl *pattern) > > { > > + dReturn_if_fail (bw->nav_expecting == FALSE); > > + > > for (int i = 0; i < images->size(); i++) { > > if (images->get(i)->image) { > > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { > > Can you still crash dillo this way, with the latest CVS? > (i.e. without the above patch). I'm currently seeing all sorts of crashes and I suspect that they are related to xpmImage from fltk. Could someone with a linux machine please check current dillo with valgrind especially when the new mini_bug_xpm is shown? Also changing mini_bug_xpm to 15x15 seems to fix things for me. I don't understand all that completely, but other crashes might be related to this. Cheers, Johannes

Oct. 1, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > It's still possible to crash dillo if you click on a remote link and > > > quickly click on some images to load them. Doesn't crash every time, > > > but typically within four tries or so. I had assumed it was the same > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > If I stick > > > a_Bw_stop_clients(bw, BW_Img); > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > earlier today, so there's something wrong with just doing that. > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > That message means big trouble: the event loop stepped over itself... > > > > I've tried several different ways but can't get to crash it. > > > > Does the attached patch help? > > > > -- > > Cheers > > Jorge.- > > > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > > */ > > void DilloHtml::loadImages (const DilloUrl *pattern) > > { > > + dReturn_if_fail (bw->nav_expecting == FALSE); > > + > > for (int i = 0; i < images->size(); i++) { > > if (images->get(i)->image) { > > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { > > Can you still crash dillo this way, with the latest CVS? > (i.e. without the above patch). Yes. Also, I found out why loading was sometimes randomly disabled (as mentioned yesterday). You know how leaving the window sometimes causes an extra Nav_open_url()? That was turning nav_expecting back on. The following patch has gotten rid of those for me:

Oct. 1, 2008

what crashes remain?

by jcid＠dillo.org

Hi, On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > It's still possible to crash dillo if you click on a remote link and > > quickly click on some images to load them. Doesn't crash every time, > > but typically within four tries or so. I had assumed it was the same > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > If I stick > > a_Bw_stop_clients(bw, BW_Img); > > in the DilloHtml destructor, I can no longer get it to crash, but > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > earlier today, so there's something wrong with just doing that. > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > That message means big trouble: the event loop stepped over itself... > > I've tried several different ways but can't get to crash it. > > Does the attached patch help? > > -- > Cheers > Jorge.- > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > */ > void DilloHtml::loadImages (const DilloUrl *pattern) > { > + dReturn_if_fail (bw->nav_expecting == FALSE); > + > for (int i = 0; i < images->size(); i++) { > if (images->get(i)->image) { > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { Can you still crash dillo this way, with the latest CVS? (i.e. without the above patch). -- Cheers Jorge.-

Oct. 1, 2008

segfault -- callback + closed window?

by jcid＠dillo.org

On Tue, Sep 30, 2008 at 03:16:30PM -0400, Jorge Arellano Cid wrote: > On Tue, Sep 30, 2008 at 06:39:44PM +0200, Johannes Hofmann wrote: > > On Tue, Sep 30, 2008 at 12:41:21PM -0400, Jorge Arellano Cid wrote: > > > On Tue, Sep 30, 2008 at 12:03:57PM -0400, Jorge Arellano Cid wrote: > > > > On Tue, Sep 30, 2008 at 05:22:08PM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > On Mon, Sep 29, 2008 at 07:38:20PM +0000, corvid wrote: > > > > > > I hit ',' a few times, going back past a page with a > > > > > > big progressive jpeg webcomic, and hit ^Q to close the window > > > > > > while dillo was thinking its way past that image. > > > > > > > > > > > > Got: > > > > > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > > > [Switching to Thread 16384 (LWP 2782)] > > > > > > 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > > > > > at Widget.cxx:575 > > > > > > 575 widget->damage_ |= DAMAGE_CHILD; > > > > > > (gdb) bt > > > > > > #0 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > > > > > at Widget.cxx:575 > > > > > > #1 0x0804f679 in UI::button_set_sens (this=0x82ce9d8, btn=UI_STOP, sens=0) > > > > > > at ui.cc:1109 > > > > > > #2 0x08054c59 in a_UIcmd_set_buttons_sens_cb (vbw=0x81ad858) at uicmd.cc:835 > > > > > > #3 0x080e47f9 in fltk::wait () at TabGroup.cxx:116 > > > > > > #4 0x080e489d in fltk::run () at TabGroup.cxx:116 > > > > > > #5 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127 > > > > > > > > > > > > > > > > > > Maybe that's just a part of life with callbacks... > > > > > > > > > > > > > > > > I no longer see this crash when removing the buttons_sens workaround > > > > > in uicmd.cc as in attached patch. > > > > > Does someone remember why it was introduced? > > > > > > > > It comes from dillo1. > > > > > > > > Committed. > > > > > > > > BTW, this is exactly what I meant with a UI getting the wrong bw. > > > > I think this should be fixed before the release. > > > > > > Update: I have a patch that works in my tree. It gets rid of > > > bw as the window's user_data(). > > > Just allow me some time to test/polish. > > > > > > > Cool. Just wanted to start it myself. > > Please try the attached patch, not tested, I'm on my way > to the airport. I just committed a more polished version. It gets rid of the ui->vbw(), the user_data() setting on FOCUS event and has a new version of win_cb(). Please give it some good testing. -- Cheers Jorge.-

Oct. 1, 2008

an experiment regarding cross site request forgery

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote: >> Cross site request forgery is the one where the bad person sticks >> an image tag or some javascript or whatever on a page, >> and your privileges are used to do something. Johannes Hofmann wrote: > To me the cross site request forgery issue looks more like an issue of > the cookie system. No. CSRF is caused by browsers sending authentication credentials implicitly with every request to an host. Those credentials might be cookies, http AUTH headers, ssl client certificates or even your IP address in some (stupid) intranet solutions. Joerg Sonnenberger wrote: > There's nothing wrong with that. Such an image URL is a simple GET > request. Any web application doing a modification is broken by design > and there are good reasons for allowing such URLs. The problem is > allowing POST actions to a different site than the one issuing it. This is true, GET requests shouldn't be state changing. But there are ways to create POST requests automatically (most ''active content'' can do this) or by tricking the user into clicking on the submit button by styling them via css (this is called "clickjacking" nowadays... yay for more buzzwords) and using some social engineering ("click the monkey to win big $$$). Disallowing cross domain POST requests seems very restrictive but would solve the problem. Johannes Hofmann wrote: > Perhaps we should be more careful when to send out a cookie. > What about not sending cookies with image requests, if the host of > the image url is different from the one in the main page? > What do other browser do about this? Yes, I think this is the way to go. One need to decide when to send out authentication credentials (legitimate session) and when to strip them (CSRF attempt). Martin Johns and I developed a firefox extension [0] that does exactly this. Please see [1] pages 29 - 37 or [2] for more information. [1] is also a pretty good introduction to CSRF. Please note that the browser independent proxy solution is deprecated (but should work unless the twisted framework changed its api too much) and the firefox extension is somewhat unmaintained at the moment... Justus 0: http://www.nongnu.org/requestrodeo/ 1: http://www.informatik.uni-hamburg.de/SVS/personnel/martin/psj06johns-e.pdf 2: http://www.informatik.uni-hamburg.de/SVS/papers/2006_owasp_RequestRodeo.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI41/IoPmwNWhsaZYRAhXNAJ0WbzFz51LEObLbF8/oEPkUuZtT4ACfbCNG KDOXrmHCAOyhR15a+p5tgR0= =Kokv -----END PGP SIGNATURE-----

Oct. 1, 2008