- Dillo-dev - lists.mailman3.com

what crashes remain?

by jcid＠dillo.org

On Fri, Oct 03, 2008 at 06:32:50PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Oct 01, 2008 at 10:47:45PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > > > > > > 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()? > > > > > > > > > > > > No, I don't know. > > > > > > How is it triggered? > > > > > > > > > > Really? I've gotten them often throughout this whole fltk era. > > > > > Taking out my fix, here's a breakpoint on Nav_open_url, > > > > > triggered by leaving the window: > > > > > > > > > > Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > > > 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); > > > > > #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > > > #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 > > > > > #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 > > > > > #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 > > > > > #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 > > > > > #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 > > > > > #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 > > > > > #7 0x080e56f4 in fix_focus () at run.cxx:108 > > > > > #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 > > > > > #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 > > > > > #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 > > > > > #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 > > > > > #12 0x080e79fe in fltk::run () at run.cxx:399 > > > > > #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127 > > > > > > > > From the bt it's clear it happens, But how do I trigger/reproduce it. > > > > I've tried moving the mouse pointer out of the window, focusing another > > > > window, etc. With no luck. > > > > > > The reliable way that I'm using > > > (haven't checked how many of these steps/precautions are strictly necessary) > > > - type an url into the Location CustInput and press enter. > > > - don't touch the mouse > > > - when the page has finished loading completely > > > - move the mouse out of the window > > > > > > In case there's some WM interaction, I have fvwm. > > > > OK, I can see the bug with fvwm. > > > > Please check the CVS code. > > It solves the problem here. > > It's working! Form inputs were also checked and FltkEntryResource::setText() calls value() which is a wrapper for text(). -- Cheers Jorge.-

Oct. 3, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Wed, Oct 01, 2008 at 10:47:45PM +0000, corvid wrote: > > Jorge wrote: > > > On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > > > > > 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()? > > > > > > > > > > No, I don't know. > > > > > How is it triggered? > > > > > > > > Really? I've gotten them often throughout this whole fltk era. > > > > Taking out my fix, here's a breakpoint on Nav_open_url, > > > > triggered by leaving the window: > > > > > > > > Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > > 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); > > > > #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > > #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 > > > > #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 > > > > #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 > > > > #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 > > > > #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 > > > > #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 > > > > #7 0x080e56f4 in fix_focus () at run.cxx:108 > > > > #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 > > > > #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 > > > > #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 > > > > #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 > > > > #12 0x080e79fe in fltk::run () at run.cxx:399 > > > > #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127 > > > > > > From the bt it's clear it happens, But how do I trigger/reproduce it. > > > I've tried moving the mouse pointer out of the window, focusing another > > > window, etc. With no luck. > > > > The reliable way that I'm using > > (haven't checked how many of these steps/precautions are strictly necessary) > > - type an url into the Location CustInput and press enter. > > - don't touch the mouse > > - when the page has finished loading completely > > - move the mouse out of the window > > > > In case there's some WM interaction, I have fvwm. > > OK, I can see the bug with fvwm. > > Please check the CVS code. > It solves the problem here. It's working!

Oct. 3, 2008

patch: close windows from menubar

by jcid＠dillo.org

On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote: > Hi, > > Committed. > > On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote: > > BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything. > > Yeah. > Even MenuBar::handle() doesn't see them. Seems like an FLTK bug/feature. If you try ./menu in FLTK's test/ directory, the CTRL shortcuts for the "Edit" menu don't work. Time to ask or to STR? -- Cheers Jorge.-

Oct. 3, 2008

patch: close windows from menubar

by jcid＠dillo.org

Hi, Committed. On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote: > BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything. Yeah. Even MenuBar::handle() doesn't see them. -- Cheers Jorge.-

Oct. 3, 2008

what crashes remain?

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 10:47:45PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > > > > 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()? > > > > > > > > No, I don't know. > > > > How is it triggered? > > > > > > Really? I've gotten them often throughout this whole fltk era. > > > Taking out my fix, here's a breakpoint on Nav_open_url, > > > triggered by leaving the window: > > > > > > Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); > > > #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > > #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 > > > #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 > > > #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 > > > #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 > > > #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 > > > #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 > > > #7 0x080e56f4 in fix_focus () at run.cxx:108 > > > #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 > > > #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 > > > #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 > > > #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 > > > #12 0x080e79fe in fltk::run () at run.cxx:399 > > > #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127 > > > > From the bt it's clear it happens, But how do I trigger/reproduce it. > > I've tried moving the mouse pointer out of the window, focusing another > > window, etc. With no luck. > > The reliable way that I'm using > (haven't checked how many of these steps/precautions are strictly necessary) > - type an url into the Location CustInput and press enter. > - don't touch the mouse > - when the page has finished loading completely > - move the mouse out of the window > > In case there's some WM interaction, I have fvwm. OK, I can see the bug with fvwm. Please check the CVS code. It solves the problem here. -- Cheers Jorge.-

Oct. 3, 2008

an experiment regarding cross site request forgery

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > On Wed, Oct 01, 2008 at 09:33:09PM +0000, corvid wrote: > > > Justus wrote: > > > > 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... > > > > > > Having done some reading now: > > > So for an HTTP redirect or an image request, A->B, > > > I gather up the cookies that I would send when asking for B > > > and discard those that I would not send if I were asking for A? > > > > Sounds good. In which cases this will not discard all cookies? > I should also mention that it does have the virtue of being easy to implement, so it wouldn't take much to be able to try it out. RFC 2965 mentioned not accepting the cookies that you get back from an untrusted request either, which is an interesting thought.

Oct. 3, 2008

an experiment regarding cross site request forgery

by corvid＠lavabit.com

Johannes wrote: > On Wed, Oct 01, 2008 at 09:33:09PM +0000, corvid wrote: > > Justus wrote: > > > 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... > > > > Having done some reading now: > > So for an HTTP redirect or an image request, A->B, > > I gather up the cookies that I would send when asking for B > > and discard those that I would not send if I were asking for A? > > Sounds good. In which cases this will not discard all cookies? Well... if we had two johannes.de cookies and one had the Secure attribute, then if http://johannes.de redirected to https://johannes.de, we'd send one cookie, even though the server will probably expect both, and it's not an uncommon sort of redirect, so it might be bad. But at undergraduates.uni-johannes.de, I lean toward not wanting to trust the requester more than I am really forced to. For that matter, I think the rules let you make cookies for a domain as wide as .uni-johannes.de ..or .co.uk... I don't know. Maybe what cookies do is fundamentally a hard problem, but sometimes it feels like they were quickly hacked together without much concern for anything. Or perhaps the controlling bodies had ad revenue in mind more than anything else.

Oct. 3, 2008

feature freeze

by jcid＠dillo.org

On Thu, Oct 02, 2008 at 10:18:42PM +0100, Jeremy Henty wrote: > On Thu, Oct 02, 2008 at 08:01:58PM +0200, Johannes Hofmann wrote: > > > 6.- redraw storms related to the MenuTabPager (noticed by Jeremy) > > [...] > > 6: Using the ShrinkTabPager avoids the problem > > Here's a (tiny) patch to use the ShrinkTabPager. Committed as workaround for redraw storms. -- Cheers Jorge.-

Oct. 3, 2008

an experiment regarding cross site request forgery

by corvid＠lavabit.com

Justus wrote: > corvid wrote: > > Justus wrote: > >> 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... > > > > Having done some reading now: > > So for an HTTP redirect or an image request, A->B, > > I gather up the cookies that I would send when asking for B > > and discard those that I would not send if I were asking for A? > I am not sure I understand your question. > > The basic csrf scenario is the following: > > 1. you log in to some web application hosted at good.org > 2. with the same browser instance using another window or tab (or you > just forget to log out and reused the same window) you visit evil.org > 3. evil.org hosts an html page that triggers an request to good.org, > either using an image/script/style/object/whatever tag in case of an GET > request or using an form and javascript / css to submit the form > 4. your browser sends any authentication credentials like cookies along > with the request since they are associated with the target host thus > allowing evil.org to change the state of your good.org account on your > behalf > > The proper thing to do is to fix this on the server side, but since csrf > isn't as widely known as xss many web applications are vulnerable to > this problem. I understand that there's a distinction between - dillo making the request on the user's behalf because he clicked a link or pressed a button or whatever, knowing the url. This request is made with the user's privileges. - dillo making the request on behalf of some code that caused a redirect or loaded an image (auth, css, javascript, etc. being implemented would result in further cases)... This request is sometimes made with some privileges depending on whether the requesting code has that privilege... So I want to be sure that I understand under what conditions the cookies can be sent. It seems that if the requesting url meets the conditions that would cause me to send it a cookie, then I either _did_ send it that cookie earlier, or it just gave it to me, so I would be (sort of) okay in sending that cookie in a request on its behalf. I see that rfc2965 also has some dot-based rules about "unverifiable transactions"... A bit of looking around the web gives me the impression that all of the various dot things that surround cookies have been an awful mess that don't map well to real-world trust boundaries. (This opera guy, for instance http://my.opera.com/yngve/blog/index.dml/tag/HTTP) Hmm...

Oct. 3, 2008

an experiment regarding cross site request forgery

by Johannes.Hofmann＠gmx.de

On Wed, Oct 01, 2008 at 09:33:09PM +0000, corvid wrote: > Justus wrote: > > 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... > > Having done some reading now: > So for an HTTP redirect or an image request, A->B, > I gather up the cookies that I would send when asking for B > and discard those that I would not send if I were asking for A? Sounds good. In which cases this will not discard all cookies? Cheers, Johannes

Oct. 3, 2008