- Dillo-dev - lists.mailman3.com

BLFS Dillo page

by onepoint＠starurchin.org

I just updated the BLFS dillo2 Wiki page to reflect release 2.2. Is there anything else that should be changed? Eg. it doesn't say anything about CSS configuration files. http://wiki.linuxfromscratch.org/blfs/wiki/dillo2 Regards, Jeremy Henty

Feb. 13, 2010

dillo-2.2 has been released!

by onepoint＠starurchin.org

And the sha1sum is: 06b325a246a639d936dabfc73d005f951d23c151 dillo-2.2.tar.bz2 At least, that's what I got from evilhackers.com ! :-) Regards, Jeremy Henty

Feb. 12, 2010

Editable User-Agent

by corvid＠lavabit.com

Alexander wrote: > I would like to make a small proposal for another useful option in > dillorc: A customizable User-Agent string. > > I think this might be useful for some users that want to mime another > browser in order to avoid vulnerabilities due to zero day security > problems or that want to test their website with several browsers and > User-Agent strings. > > Enclosed please find a small patch that adds a new option to dillorc > which defines the User-Agent string via > > http_user_agent="Mozilla/5.0" Committed with modifications.

Feb. 11, 2010

dillo-2.2 has been released!

by jcid＠dillo.org

On Thu, Feb 11, 2010 at 07:23:38PM +0000, corvid wrote: > [...] > I think I have the website all updated except for the main page, and > Jorge will do the freshmeat stuff. Submitted. -- Cheers Jorge.-

Feb. 11, 2010

dillo-2.2 has been released!

by corvid＠lavabit.com

Get it at http://www.dillo.org/download/dillo-2.2.tar.bz2 Some highlights of this release are: - a major overhaul of the cookies subsystem - a reimplementation of the Dillo Plugin (DPI) API - a configurable connection limit - various CSS improvements Anyone using cookies should definitely upgrade, as important security fixes were made in the process of rewriting the cookies module. Pretty much all of the changes that would be of interest to users are mentioned in the ChangeLog ( http://hg.dillo.org/dillo/file/tip/ChangeLog ) In configuration files: dillorc has new options http_max_conns and show_help, and the default for no_proxy has changed. keysrc has new options for save and for various motion commands. You can also use keysym values in the rules now. I think I have the website all updated except for the main page, and Jorge will do the freshmeat stuff.

Feb. 11, 2010

Re: dillo-2.2-rc2

by Johannes.Hofmann＠gmx.de

On Thu, Feb 11, 2010 at 09:10:54AM +0100, Thomas Orgis wrote: > Am Wed, 10 Feb 2010 21:43:34 -0300 > schrieb Jorge Arellano Cid <jcid(a)dillo.org>: > > > > > What do you mean? > > > > Is the patch already included in v2.0.x-r6970? > > > > > > Nope. I have no idea what they're waiting for :s. > > > > AFAIU, FLTK-2.0 is dead and will seldom update. All the effort > > is concentrated in 1.3.x which they plan to release soon. > > FLTK development is puzzling... they have several development trees since many years now, none of which had a release yet. Heck, they have plans for FLTK 3.x!? > This development practice seems to suggest that dependent projects rather include snapshots of FLTK in their source... > And, how "soon" will that FLTK 1.3 release happen so that dillo might switch to something "stable"? > > This specific case might just mean that I'll add an optional patch to the fltk2-package of my distro to include horizontal scrolling, though. But it would be better if upstream did this, of course. Some fltk developers still seem to care a bit about fltk2, so maybe some cheering about the patch on the fltk list might help to get it in eventually. Cheers, Johannes

Feb. 11, 2010

Re: dillo-2.2-rc2

by thomas-forum＠orgis.org

Am Wed, 10 Feb 2010 21:43:34 -0300 schrieb Jorge Arellano Cid <jcid(a)dillo.org>: > > > What do you mean? > > > Is the patch already included in v2.0.x-r6970? > > > > Nope. I have no idea what they're waiting for :s. > > AFAIU, FLTK-2.0 is dead and will seldom update. All the effort > is concentrated in 1.3.x which they plan to release soon. FLTK development is puzzling... they have several development trees since many years now, none of which had a release yet. Heck, they have plans for FLTK 3.x!? This development practice seems to suggest that dependent projects rather include snapshots of FLTK in their source... And, how "soon" will that FLTK 1.3 release happen so that dillo might switch to something "stable"? This specific case might just mean that I'll add an optional patch to the fltk2-package of my distro to include horizontal scrolling, though. But it would be better if upstream did this, of course. Alrighty then, Thomas.

Feb. 11, 2010

Re: dillo-2.2-rc2

by jcid＠dillo.org

On Wed, Feb 10, 2010 at 05:21:03PM -0500, Dennis Nezic wrote: > On Wed, 10 Feb 2010 19:09:19 -0300, Jorge Arellano Cid wrote: > > On Wed, Feb 10, 2010 at 01:08:49PM -0500, Dennis Nezic wrote: > > > On Mon, 8 Feb 2010 16:45:06 +0100, Thomas Orgis wrote: > > > > Hm... regarding that... horizontal scroll events are not handled > > > > by dillo. One might need to investigate that in FLTK... > > > > > > http://fltk.org/str.php?L1964 > > > > > > Success!!1! :) > > > > What do you mean? > > Is the patch already included in v2.0.x-r6970? > > Nope. I have no idea what they're waiting for :s. AFAIU, FLTK-2.0 is dead and will seldom update. All the effort is concentrated in 1.3.x which they plan to release soon. -- Cheers Jorge.-

Feb. 11, 2010

Re: dillo-2.2-rc2

by dennisn＠dennisn.dyndns.org

On Wed, 10 Feb 2010 19:09:19 -0300, Jorge Arellano Cid wrote: > On Wed, Feb 10, 2010 at 01:08:49PM -0500, Dennis Nezic wrote: > > On Mon, 8 Feb 2010 16:45:06 +0100, Thomas Orgis wrote: > > > Hm... regarding that... horizontal scroll events are not handled > > > by dillo. One might need to investigate that in FLTK... > > > > http://fltk.org/str.php?L1964 > > > > Success!!1! :) > > What do you mean? > Is the patch already included in v2.0.x-r6970? Nope. I have no idea what they're waiting for :s.

Feb. 10, 2010

Re: dillo-2.2-rc2

by jcid＠dillo.org

On Wed, Feb 10, 2010 at 01:08:49PM -0500, Dennis Nezic wrote: > On Mon, 8 Feb 2010 16:45:06 +0100, Thomas Orgis wrote: > > Hm... regarding that... horizontal scroll events are not handled by > > dillo. One might need to investigate that in FLTK... > > http://fltk.org/str.php?L1964 > > Success!!1! :) What do you mean? Is the patch already included in v2.0.x-r6970? -- Cheers Jorge.-

Feb. 10, 2010

Re: dillo-2.2-rc2

by dennisn＠dennisn.dyndns.org

On Mon, 8 Feb 2010 16:45:06 +0100, Thomas Orgis wrote: > Hm... regarding that... horizontal scroll events are not handled by > dillo. One might need to investigate that in FLTK... http://fltk.org/str.php?L1964 Success!!1! :)

Feb. 10, 2010

dillo-2.2-rc3

by Johannes.Hofmann＠gmx.de

Hello, here comes rc3, which contains a minor addition to the blackhole fix. On some systems processes get a SIGHUP before SIGTERM / SIGKILL on shutdown. To make sure that we cleanup properly in that case, SIGHUP needs to be catched too. http://www.dillo.org/download/dillo-2.2-rc3.tar.bz2 SHA1: ec78c1b8a5f3e0199bd6ac0912edeabfd18ae35f If no issues come up this will become dillo-2.2. I want to release 2.2 tomorrow. We can wait with the freshmeat announcement until packages are available, but I don't want to delay the official release of the 2.2 sources any further. Cheers, Johannes

Feb. 10, 2010

middle_click_drags_page=NO [Re: [Dillo-dev] dillo-2.2-rc2]

by corvid＠lavabit.com

Johannes wrote: > corvid, should we get this into the dillo-2.2 release? I will have > to make some minor adjustments to the rc2 code anyway. It's up to > you. Just commit it if you think it should go in. Given the circumstances, I think I would prefer to save it for after release.

Feb. 10, 2010

middle_click_drags_page=NO [Re: [Dillo-dev] dillo-2.2-rc2]

by Johannes.Hofmann＠gmx.de

On Wed, Feb 10, 2010 at 12:08:27AM +0100, Thomas Orgis wrote: > Am Tue, 9 Feb 2010 01:28:46 +0000 > sc > > > > > middle_click_drags_page=NO > > > > > > > > in dillorc. A Major flaw of this setting is that pasting into form fields does not work. Any middle-click triggers URL loading... when this setting is YES, the pasting into form fields works, is not harmed by the page dragging functions. > > > > Please try the attached patch... > > > > Looks good to me! Built the 2.2 rc1 with this patch and it works as expected now (as one is accustomed from other browsers). > Nice to see that this is such a small patch, even. nice! corvid, should we get this into the dillo-2.2 release? I will have to make some minor adjustments to the rc2 code anyway. It's up to you. Just commit it if you think it should go in. Cheers, Johannes

Feb. 10, 2010

middle_click_drags_page=NO [Re: [Dillo-dev] dillo-2.2-rc2]

by thomas-forum＠orgis.org

Am Tue, 9 Feb 2010 01:28:46 +0000 sc > > > middle_click_drags_page=NO > > > > > > in dillorc. A Major flaw of this setting is that pasting into form fields does not work. Any middle-click triggers URL loading... when this setting is YES, the pasting into form fields works, is not harmed by the page dragging functions. > > Please try the attached patch... > Looks good to me! Built the 2.2 rc1 with this patch and it works as expected now (as one is accustomed from other browsers). Nice to see that this is such a small patch, even. Alrighty then, Thomas.

Feb. 10, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Tue, Feb 09, 2010 at 06:24:48PM +0100, Johannes Hofmann wrote: > On Mon, Feb 08, 2010 at 02:16:08PM -0300, Jorge Arellano Cid wrote: > > On Sun, Feb 07, 2010 at 07:15:59PM +0100, Johannes Hofmann wrote: > > > On Sun, Feb 07, 2010 at 08:59:44AM -0300, Jorge Arellano Cid wrote: > > > > On Tue, Feb 02, 2010 at 09:13:14PM +0100, Johannes Hofmann wrote: > > > > > On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > > > > > > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > > > > > > bf wrote: > > > > > > > > Because blackhole(4) is a common security measure, and because this > > > > > > > > problem did not exist under the previous dpi framework, it must be > > > > > > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > > > > > > > > > > > I finally looked back to refresh my memory on why we switched to inet > > > > > > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > > > > > > thinking on what we would do for Minix? > > > > > > > > > > > > At some point in time Minix 3 will have to implement UDS. > > > > > > In the meanwhile they can use the version with inet sockets. > > > > > > > > > > What shall we do about this TCP blackhole issue? > > > > > Should we try to switch back to UDS before release? > > > > > > > > Sorry for the delayed answer Johannes (I was out of the city). > > > > > > > > IMO, UDS before the release is too risky. It will need lots of > > > > testing time. > > > > > > Just came to the same conclusion ... > > > > > > > > > > I believe we may choose the solution bf has found > > > > to work better as workaround, make a patch with it and release. A > > > > few times in the past I rushed a "better" solution into an rc, > > > > only to learn not to do it! :) > > > > > > What patch exactly would you propose? I see > > > > > > * increasing dpid_idle_timeout > > > * adding a linger variable > > > * and a shell wrapper to start dillo > > > > a dpid_linger dillorc variable would save the user the trouble > > of re-compiling, but it would add the burden of prefs parsing in > > dpid. So, I'd say centinel solution could work: > > > > e.g. "touch ~/.dillo/DPID_LINGER" > > > > and dpid acting accordingly. > > > > Also a mention of the shell wrapper script in the README, with > > a link to a working example in our site would do the rest. An > > entry in the FAQ could help too. > > Jorge, as you might have seen already I committed a different fix > after reproducing the issue here on my system. Yes. When back home, I started answering email, then saw the patch ;-) > Please check it in the repo: > http://hg.dillo.org/dillo/rev/3a159d7e5098 +1 I think the committed solution is much better. My only concern with this type of solution is that it fails when the dpid gets hung (and then "kill -9" doesn't help). Maybe adding an unlink() call in dpidc's stop part is worth the effort. That way "dpidc stop" would always clear the centinel. ... but checking whether dpid is still alive after dpibye, killing it and thence going after each dpi with a kill signal looks like overkill (pun intended!) to me. ;) > * \todo what is the most portable way to ignore the signo > argument of without generating a warning? Is "int signo __unused" > gcc specific? a_Http_ccc() uses this nice trick: (void)Data2; /* suppress unused parameter warning */ -- Cheers Jorge.-

Feb. 9, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by Johannes.Hofmann＠gmx.de

On Mon, Feb 08, 2010 at 02:16:08PM -0300, Jorge Arellano Cid wrote: > On Sun, Feb 07, 2010 at 07:15:59PM +0100, Johannes Hofmann wrote: > > On Sun, Feb 07, 2010 at 08:59:44AM -0300, Jorge Arellano Cid wrote: > > > On Tue, Feb 02, 2010 at 09:13:14PM +0100, Johannes Hofmann wrote: > > > > On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > > > > > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > > > > > bf wrote: > > > > > > > Because blackhole(4) is a common security measure, and because this > > > > > > > problem did not exist under the previous dpi framework, it must be > > > > > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > > > > > > > > > I finally looked back to refresh my memory on why we switched to inet > > > > > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > > > > > thinking on what we would do for Minix? > > > > > > > > > > At some point in time Minix 3 will have to implement UDS. > > > > > In the meanwhile they can use the version with inet sockets. > > > > > > > > What shall we do about this TCP blackhole issue? > > > > Should we try to switch back to UDS before release? > > > > > > Sorry for the delayed answer Johannes (I was out of the city). > > > > > > IMO, UDS before the release is too risky. It will need lots of > > > testing time. > > > > Just came to the same conclusion ... > > > > > > > I believe we may choose the solution bf has found > > > to work better as workaround, make a patch with it and release. A > > > few times in the past I rushed a "better" solution into an rc, > > > only to learn not to do it! :) > > > > What patch exactly would you propose? I see > > > > * increasing dpid_idle_timeout > > * adding a linger variable > > * and a shell wrapper to start dillo > > a dpid_linger dillorc variable would save the user the trouble > of re-compiling, but it would add the burden of prefs parsing in > dpid. So, I'd say centinel solution could work: > > e.g. "touch ~/.dillo/DPID_LINGER" > > and dpid acting accordingly. > > Also a mention of the shell wrapper script in the README, with > a link to a working example in our site would do the rest. An > entry in the FAQ could help too. Jorge, as you might have seen already I committed a different fix after reproducing the issue here on my system. Please check it in the repo: http://hg.dillo.org/dillo/rev/3a159d7e5098 Cheers, Johannes

Feb. 9, 2010

valgrind [Re: [Dillo-dev] dillo-2.2-rc1]

by onepoint＠starurchin.org

On Sun, Feb 07, 2010 at 09:10:44AM -0300, Jorge Arellano Cid wrote: > On Thu, Feb 04, 2010 at 06:32:29PM +0000, Jeremy Henty wrote: > > On Wed, Feb 03, 2010 at 08:07:13AM +0000, corvid wrote: > > > > > > I've been wondering whether it is possible to check dpid and the > > > dpis as well. [...] > > > > [...] > > The tricky thing is identifying the process - currently I just > > slurp the whole output before doing anything, by which time the > > dpi might have died. It might be better to process it > > line-by-line so I can check the process table right away. That > > would need a little re-engineering. Or maybe it would be better > > to replace the dpis with wrappers that run valgrind? > > I'd definitely try with wrappers! I think you're right. It's a little kludgy but at least it's robust - you know for sure which program the output is from and you don't get scrambled results from multiple processes writing to the same stream. Regards, Jeremy Henty

Feb. 9, 2010

middle_click_drags_page=NO [Re: [Dillo-dev] dillo-2.2-rc2]

by corvid＠lavabit.com

I wrote: > Thomas wrote: > > one feature I motivated is not interacting as it should. > > It is the middle-click pasting into the browser window to trigger loading of the pasted URL, activated via > > > > middle_click_drags_page=NO > > > > in dillorc. A Major flaw of this setting is that pasting into form fields does not work. Any middle-click triggers URL loading... when this setting is YES, the pasting into form fields works, is not harmed by the page dragging functions. Please try the attached patch...

Feb. 9, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Sun, Feb 07, 2010 at 07:15:59PM +0100, Johannes Hofmann wrote: > On Sun, Feb 07, 2010 at 08:59:44AM -0300, Jorge Arellano Cid wrote: > > On Tue, Feb 02, 2010 at 09:13:14PM +0100, Johannes Hofmann wrote: > > > On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > > > > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > > > > bf wrote: > > > > > > Because blackhole(4) is a common security measure, and because this > > > > > > problem did not exist under the previous dpi framework, it must be > > > > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > > > > > > > I finally looked back to refresh my memory on why we switched to inet > > > > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > > > > thinking on what we would do for Minix? > > > > > > > > At some point in time Minix 3 will have to implement UDS. > > > > In the meanwhile they can use the version with inet sockets. > > > > > > What shall we do about this TCP blackhole issue? > > > Should we try to switch back to UDS before release? > > > > Sorry for the delayed answer Johannes (I was out of the city). > > > > IMO, UDS before the release is too risky. It will need lots of > > testing time. > > Just came to the same conclusion ... > > > > I believe we may choose the solution bf has found > > to work better as workaround, make a patch with it and release. A > > few times in the past I rushed a "better" solution into an rc, > > only to learn not to do it! :) > > What patch exactly would you propose? I see > > * increasing dpid_idle_timeout > * adding a linger variable > * and a shell wrapper to start dillo a dpid_linger dillorc variable would save the user the trouble of re-compiling, but it would add the burden of prefs parsing in dpid. So, I'd say centinel solution could work: e.g. "touch ~/.dillo/DPID_LINGER" and dpid acting accordingly. Also a mention of the shell wrapper script in the README, with a link to a working example in our site would do the rest. An entry in the FAQ could help too. -- Cheers Jorge.-

Feb. 8, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Sun, Feb 07, 2010 at 05:04:18PM +0000, corvid wrote: > Jorge wrote: > > With regard to UDS, it can be scheduled into the repo shortly > > after the release; Thereafter users can help us polish it from > > there. > > Do you expect that you will have time to do it yourself? Yes. > Would it make sense to make a 2.2.1 with just the uds dpi changes and > nothing else that isn't rather trivial? I guess it'll be UDS plus other things as the testing period needs to extend around a few weeks. -- Cheers Jorge.-

Feb. 8, 2010

middle_click_drags_page=NO [Re: [Dillo-dev] dillo-2.2-rc2]

by corvid＠lavabit.com

Thomas wrote: > one feature I motivated is not interacting as it should. > It is the middle-click pasting into the browser window to trigger loading of the pasted URL, activated via > > middle_click_drags_page=NO > > in dillorc. A Major flaw of this setting is that pasting into form fields does not work. Any middle-click triggers URL loading... when this setting is YES, the pasting into form fields works, is not harmed by the page dragging functions. I'll take a look at this. Can you add it to the bug tracker?

Feb. 8, 2010

dillo-2.2-rc2

by thomas-forum＠orgis.org

Am Mon, 8 Feb 2010 12:52:50 +0100 schrieb Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > Please give it a try and report back soon. > The intention is to release dillo-2.2 this week. This is not specific to dillo-2.2, and should not hinder the release, I guess, but I have to admit that one feature I motivated is not interacting as it should. It is the middle-click pasting into the browser window to trigger loading of the pasted URL, activated via middle_click_drags_page=NO in dillorc. A Major flaw of this setting is that pasting into form fields does not work. Any middle-click triggers URL loading... when this setting is YES, the pasting into form fields works, is not harmed by the page dragging functions. I say that here just to have it mentioned... not blaming anyone but myself. But perhaps someone of you guys has an easy fix available for that? Of course one fix could be to drop the whole paste-in-window-for-URL thing but I rather like the feature... just not when I intended to paste into a form field. Also, note that the middle-click-drags-page mode is always a no-op for me as holding down the middle mouse button triggers scrolling mode via X11 anyway (a sensible setup for a Thinkpad with Trackpoint, or trackballs on desktop systems). Hm... regarding that... horizontal scroll events are not handled by dillo. One might need to investigate that in FLTK... Well, at least I have, after long time, given this little piece of feedback about the URL pasting... sorry that I didn't tell earlier, and sorry that I don't have a patch at hand. Alrighty then, Thomas.

Feb. 8, 2010

dillo-2.2-rc2

by Johannes.Hofmann＠gmx.de

Hello, I just made a new release candidate for our upcoming dillo-2.2 release. It mainly addresses the blackhole(4) timeouts reported in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-January/007247.html The rc2 tarball can be found as usual at: http://www.dillo.org/download/dillo-2.2-rc2.tar.bz2 SHA1: 38221d3499ce5f91a0c6a945a23b066e9e46ef84 Please give it a try and report back soon. The intention is to release dillo-2.2 this week. Cheers, Johannes

Feb. 8, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by Johannes.Hofmann＠gmx.de

On Sun, Feb 07, 2010 at 08:59:44AM -0300, Jorge Arellano Cid wrote: > On Tue, Feb 02, 2010 at 09:13:14PM +0100, Johannes Hofmann wrote: > > On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > > > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > > > bf wrote: > > > > > Because blackhole(4) is a common security measure, and because this > > > > > problem did not exist under the previous dpi framework, it must be > > > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > > > > > I finally looked back to refresh my memory on why we switched to inet > > > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > > > thinking on what we would do for Minix? > > > > > > At some point in time Minix 3 will have to implement UDS. > > > In the meanwhile they can use the version with inet sockets. > > > > What shall we do about this TCP blackhole issue? > > Should we try to switch back to UDS before release? > > Sorry for the delayed answer Johannes (I was out of the city). > > IMO, UDS before the release is too risky. It will need lots of > testing time. Just came to the same conclusion ... > I believe we may choose the solution bf has found > to work better as workaround, make a patch with it and release. A > few times in the past I rushed a "better" solution into an rc, > only to learn not to do it! :) What patch exactly would you propose? I see * increasing dpid_idle_timeout * adding a linger variable * and a shell wrapper to start dillo > > With regard to UDS, it can be scheduled into the repo shortly > after the release; Thereafter users can help us polish it from > there. ok. Cheers, Johannes

Feb. 7, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by corvid＠lavabit.com

Jorge wrote: > With regard to UDS, it can be scheduled into the repo shortly > after the release; Thereafter users can help us polish it from > there. Do you expect that you will have time to do it yourself? Would it make sense to make a 2.2.1 with just the uds dpi changes and nothing else that isn't rather trivial?

Feb. 7, 2010

valgrind [Re: [Dillo-dev] dillo-2.2-rc1]

by jcid＠dillo.org

Hi Jeremy, On Thu, Feb 04, 2010 at 06:32:29PM +0000, Jeremy Henty wrote: > On Wed, Feb 03, 2010 at 08:07:13AM +0000, corvid wrote: > > Jeremy wrote: > > > > > > Thanks. Everyone is welcome to suggest improvements. > > > > I've been wondering whether it is possible to check dpid and the > > dpis as well. Apparently there's a --trace-children=yes option, but > > it's probably not that simple :) > > I'll look into it. It may not be so complicated - valgrind logs the > PID so it should be easy to group the log entries by process. The > tricky thing is identifying the process - currently I just slurp the > whole output before doing anything, by which time the dpi might have > died. It might be better to process it line-by-line so I can check > the process table right away. That would need a little > re-engineering. Or maybe it would be better to replace the dpis with > wrappers that run valgrind? I'd definitely try with wrappers! -- Cheers Jorge.-

Feb. 7, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Tue, Feb 02, 2010 at 09:13:14PM +0100, Johannes Hofmann wrote: > On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > > bf wrote: > > > > Because blackhole(4) is a common security measure, and because this > > > > problem did not exist under the previous dpi framework, it must be > > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > > > I finally looked back to refresh my memory on why we switched to inet > > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > > thinking on what we would do for Minix? > > > > At some point in time Minix 3 will have to implement UDS. > > In the meanwhile they can use the version with inet sockets. > > What shall we do about this TCP blackhole issue? > Should we try to switch back to UDS before release? Sorry for the delayed answer Johannes (I was out of the city). IMO, UDS before the release is too risky. It will need lots of testing time. I believe we may choose the solution bf has found to work better as workaround, make a patch with it and release. A few times in the past I rushed a "better" solution into an rc, only to learn not to do it! :) With regard to UDS, it can be scheduled into the repo shortly after the release; Thereafter users can help us polish it from there. -- Cheers Jorge.-

Feb. 7, 2010

How to use the tab or other keyboard keys to set foucs on web page links?

by corvid＠lavabit.com

Yong wrote: > I am using the Dillo on an embedded device for web browsing. Since > this device does not support mouse or touchscreen, > I have to use the keyboard(or some buttons). I found I cannot set the > focus on these links using tab keys( Dillo 2.2-rc1). > > If there any key configuration settings to set the tab key? Not currently. > If not, I want to modify the source code to add this function, Great! > is there any example or related patches for reference? I think the way to make this work would be something like: - borrowing from the dw/findtext.cc iteration code. - checking when style->x_link != -1 or you're currently on an embedded form widget.

Feb. 7, 2010

How to use the tab or other keyboard keys to set foucs on web page links?

by sdliyong＠gmail.com

Hello All, I am using the Dillo on an embedded device for web browsing. Since this device does not support mouse or touchscreen, I have to use the keyboard(or some buttons). I found I cannot set the focus on these links using tab keys( Dillo 2.2-rc1). If there any key configuration settings to set the tab key? If not, I want to modify the source code to add this function, is there any example or related patches for reference? Thanks a lot! Yong

Feb. 7, 2010

dillo-2.2-rc1

by Johannes.Hofmann＠gmx.de

Hello, On Tue, Feb 02, 2010 at 01:11:38PM +0100, Johannes Hofmann wrote: > On Sun, Jan 31, 2010 at 02:34:37AM +0000, corvid wrote: > > As you may have already noticed, we're at RC1 for the next release. > > Johannes has built a tarball: > > > > http://www.dillo.org/download/dillo-2.2-rc1.tar.bz2 > > SHA1: 146216a1541b20a3e042c62c0db8ee42f173ed01 > > > > Please test! > > Ok, for now we know about the TCP blackhole issue reported by bf. I think we need a decision about this soon. I made a short attempt to switch DPIs back to UDS, but couldn't get it working yet. If I find some more time this weekend I will try again. I would propose that we decide on Monday, whether we release our current rc1 as it is and document the issue or go with a possible UDS solution. In both cases I want the release to happen next week. Cheers, Johannes

Feb. 6, 2010

Editable User-Agent

by corvid＠lavabit.com

Alexander wrote: > I would like to make a small proposal for another useful option in > dillorc: A customizable User-Agent string. > > I think this might be useful for some users that want to mime another > browser in order to avoid vulnerabilities due to zero day security > problems or that want to test their website with several browsers and > User-Agent strings. I think I'm currently in favor of a configurable User-Agent header for privacy. - It might be good for dillo to start sending an Accept header. I send one because I use a Firefox user agent string, and sometimes servers don't send content if one isn't doing a good enough job of pretending to be Firefox. (I've never seen the Accept header convince a server that I dont want application/xhtml+xml or multipart/mixed, though, unfortunately). - Possibly we could print a MSG when we see User-Agent in the Vary header (it tells us when a response was in some way determined by that header). I would probably like that, but perhaps others would find it irritating.

Feb. 5, 2010

Editable User-Agent

by Hole.destructor＠gmx.de

Dear Dillo Developers, I would like to make a small proposal for another useful option in dillorc: A customizable User-Agent string. I think this might be useful for some users that want to mime another browser in order to avoid vulnerabilities due to zero day security problems or that want to test their website with several browsers and User-Agent strings. Enclosed please find a small patch that adds a new option to dillorc which defines the User-Agent string via http_user_agent="Mozilla/5.0" Kind regards, Alexander Voigt

Feb. 4, 2010

valgrind [Re: [Dillo-dev] dillo-2.2-rc1]

by onepoint＠starurchin.org

On Wed, Feb 03, 2010 at 08:07:13AM +0000, corvid wrote: > Jeremy wrote: > > > > Thanks. Everyone is welcome to suggest improvements. > > I've been wondering whether it is possible to check dpid and the > dpis as well. Apparently there's a --trace-children=yes option, but > it's probably not that simple :) I'll look into it. It may not be so complicated - valgrind logs the PID so it should be easy to group the log entries by process. The tricky thing is identifying the process - currently I just slurp the whole output before doing anything, by which time the dpi might have died. It might be better to process it line-by-line so I can check the process table right away. That would need a little re-engineering. Or maybe it would be better to replace the dpis with wrappers that run valgrind? Hmm, dillo is somewhat unusual in that it forks children that are intended to keep running after the parent dies. I don't know whether valgrind will handle that usefully. This needs some research. Meanwhile, you've got to love this extract from "man valgrind" regarding the "--child-silent-after-fork" option: This can make the output less confusing (although more misleading) Meaningful and correct: pick one! :-) Regards, Jeremy Henty

Feb. 4, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by bf2006a＠yahoo.com

--- On Sun, 1/31/10, Jorge Arellano Cid <jcid(a)dillo.org> wrote: ... > > > > > > Simple solution: try something like this > script to > > > start dillo: > > > > > > #!/bin/sh > > > ST="`ps -ef|grep "[0-9] dpid"|wc -l`" Since ps(1) on *BSD differs from POSIX, I used instead: ps -ax -ocomm | grep -ce "dpid" > > > if [ "$ST" = "1" ]; then > > > echo "Dpid is running OK!" > > > dillo > > > else > > > echo "Dpid is NOT running" > > > dpid & > > > dillo > > > fi > > ... > You can increase dpid's time to live: > > dpid/main.c:208 > - int dpid_idle_timeout = 60 * 60; /* > default, in seconds */ > + int dpid_idle_timeout = 60 * 60 * 24; /* > default, in seconds */ > > > Or simply let it linger forever: > > dpid/main.c:207 > - int i, n = 0, open_max; > + int i, n = 0, linger = 1, open_max; > dpid/main.c:295 > - if > (server_is_running("downloads")) > + if (linger || > server_is_running("downloads")) > > > Please test both and send your feedback. Once > we have a usable > workaround, we may think of a good patch (e.g. a dillorc > option). I have used tested both methods, and both seem to prevent the timeouts (or at least the great majority of them, in the case of the patch that just increases the ttl), when used with something like the script above. Such a script is not quite as convenient as simply starting dillo, but probably offers an adequate workaround for the initial part of this problem, for the moment. > Last but not the least, IMHO, > using verbs like "plagued" and > expressions like "or sit on my hands" doesn't help in > dillo-dev. Perhaps something is lost in translation, or we're just proving that what one person considers colorful or descriptive is considered to be too strongly worded by another. In any event, my language was not meant to be an attack upon anyone, and no one should construe it as such. On the whole, the new version looks good. Congratulations and thanks to those who put time and energy into improving dillo since the last release. b.

Feb. 4, 2010

valgrind [Re: [Dillo-dev] dillo-2.2-rc1]

by corvid＠lavabit.com

Jeremy wrote: > On Tue, Feb 02, 2010 at 11:11:05PM +0100, Johannes Hofmann wrote: > > The page http://starurchin.org/dillo/valgrind.html is really nice > > now! > > Thanks. Everyone is welcome to suggest improvements. I've been wondering whether it is possible to check dpid and the dpis as well. Apparently there's a --trace-children=yes option, but it's probably not that simple :)

Feb. 3, 2010

dillo-2.2-rc1

by onepoint＠starurchin.org

On Tue, Feb 02, 2010 at 11:11:05PM +0100, Johannes Hofmann wrote: > @Jeremy: haven't looked at your dillo valgrind logs for a while. Me neither, actually! They haven't shown anything new for a long time, which implies that the Dillo devs have been able to do a lot of work without adding new leaks. The Http_host_connection_get() leak looks like a recent regression, though. > The page http://starurchin.org/dillo/valgrind.html is really nice > now! Thanks. Everyone is welcome to suggest improvements. Regards, Jeremy Henty

Feb. 3, 2010

dillo-2.2-rc1

by Johannes.Hofmann＠gmx.de

On Tue, Feb 02, 2010 at 10:02:34PM +0000, corvid wrote: > Johannes wrote: > > Any other issues or success stories maybe? > > Jeremy's valgrind logs show some Http_host_connection_get() leakage. > should be fixed now. Thanks for pointing this out. Johannes

Feb. 3, 2010

dillo-2.2-rc1

by Johannes.Hofmann＠gmx.de

On Tue, Feb 02, 2010 at 10:02:34PM +0000, corvid wrote: > Johannes wrote: > > Any other issues or success stories maybe? > > Jeremy's valgrind logs show some Http_host_connection_get() leakage. @Jeremy: haven't looked at your dillo valgrind logs for a while. The page http://starurchin.org/dillo/valgrind.html is really nice now! I will try to fix the leak. Cheers, Johannes

Feb. 2, 2010

dillo-2.2-rc1

by corvid＠lavabit.com

Johannes wrote: > Any other issues or success stories maybe? Jeremy's valgrind logs show some Http_host_connection_get() leakage.

Feb. 2, 2010

dillo-2.2-rc1

by Johannes.Hofmann＠gmx.de

On Tue, Feb 02, 2010 at 05:16:38PM -0300, Jorge Arellano Cid wrote: > On Tue, Feb 02, 2010 at 01:11:38PM +0100, Johannes Hofmann wrote: > > On Sun, Jan 31, 2010 at 02:34:37AM +0000, corvid wrote: > > > As you may have already noticed, we're at RC1 for the next release. > > > Johannes has built a tarball: > > > > > > http://www.dillo.org/download/dillo-2.2-rc1.tar.bz2 > > > SHA1: 146216a1541b20a3e042c62c0db8ee42f173ed01 > > > > > > Please test! > > > > Ok, for now we know about the TCP blackhole issue reported by bf. > > > > Any other issues or success stories maybe? > > Fix for a compilation warning: > > diff -pru /home/jcid/C/Dillo/d2/dillo/dpid/dpidc.c dillo-2.2-rc1/dpid/dpidc.c > --- /home/jcid/C/Dillo/d2/dillo/dpid/dpidc.c 2010-01-25 11:28:59.000000000 > -0300 > +++ dillo-2.2-rc1/dpid/dpidc.c 2010-02-01 14:25:01.000000000 -0300 > @@ -98,7 +98,8 @@ int main(int argc, char *argv[]) > } else if (strcmp(argv[1], "chat") == 0) { > printf("Please enter the message: "); > bzero(buffer,256); > - fgets(buffer,255,stdin); > + if (fgets(buffer,255,stdin) == NULL) > + MSG_ERR("dpidc: Can't read the message\n"); > } else { > MSG_ERR("main: Unknown operation '%s'\n", argv[1]); > print_usage(argv[0]); Thanks, committed! :)

Feb. 2, 2010

dillo-2.2-rc1

by jcid＠dillo.org

On Tue, Feb 02, 2010 at 01:11:38PM +0100, Johannes Hofmann wrote: > On Sun, Jan 31, 2010 at 02:34:37AM +0000, corvid wrote: > > As you may have already noticed, we're at RC1 for the next release. > > Johannes has built a tarball: > > > > http://www.dillo.org/download/dillo-2.2-rc1.tar.bz2 > > SHA1: 146216a1541b20a3e042c62c0db8ee42f173ed01 > > > > Please test! > > Ok, for now we know about the TCP blackhole issue reported by bf. > > Any other issues or success stories maybe? Fix for a compilation warning: diff -pru /home/jcid/C/Dillo/d2/dillo/dpid/dpidc.c dillo-2.2-rc1/dpid/dpidc.c --- /home/jcid/C/Dillo/d2/dillo/dpid/dpidc.c 2010-01-25 11:28:59.000000000 -0300 +++ dillo-2.2-rc1/dpid/dpidc.c 2010-02-01 14:25:01.000000000 -0300 @@ -98,7 +98,8 @@ int main(int argc, char *argv[]) } else if (strcmp(argv[1], "chat") == 0) { printf("Please enter the message: "); bzero(buffer,256); - fgets(buffer,255,stdin); + if (fgets(buffer,255,stdin) == NULL) + MSG_ERR("dpidc: Can't read the message\n"); } else { MSG_ERR("main: Unknown operation '%s'\n", argv[1]); print_usage(argv[0]); Everything else seems OK so far. I'm expecting feedback from "bf". -- Cheers Jorge.-

Feb. 2, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by Johannes.Hofmann＠gmx.de

On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > bf wrote: > > > Because blackhole(4) is a common security measure, and because this > > > problem did not exist under the previous dpi framework, it must be > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > I finally looked back to refresh my memory on why we switched to inet > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > thinking on what we would do for Minix? > > At some point in time Minix 3 will have to implement UDS. > In the meanwhile they can use the version with inet sockets. What shall we do about this TCP blackhole issue? Should we try to switch back to UDS before release? Cheers, Johannes

Feb. 2, 2010

dillo-2.2-rc1

by Johannes.Hofmann＠gmx.de

On Sun, Jan 31, 2010 at 02:34:37AM +0000, corvid wrote: > As you may have already noticed, we're at RC1 for the next release. > Johannes has built a tarball: > > http://www.dillo.org/download/dillo-2.2-rc1.tar.bz2 > SHA1: 146216a1541b20a3e042c62c0db8ee42f173ed01 > > Please test! Ok, for now we know about the TCP blackhole issue reported by bf. Any other issues or success stories maybe? Please keep testing. Cheers, Johannes

Feb. 2, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > bf wrote: > > Because blackhole(4) is a common security measure, and because this > > problem did not exist under the previous dpi framework, it must be > > considered a regression, even if, in hindsight, it is to be "expected". > > I finally looked back to refresh my memory on why we switched to inet > sockets: Minix. If we do return to Unix sockets eventually, what is the > thinking on what we would do for Minix? At some point in time Minix 3 will have to implement UDS. In the meanwhile they can use the version with inet sockets. -- Cheers Jorge.-

Jan. 31, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by corvid＠lavabit.com

bf wrote: > Because blackhole(4) is a common security measure, and because this > problem did not exist under the previous dpi framework, it must be > considered a regression, even if, in hindsight, it is to be "expected". I finally looked back to refresh my memory on why we switched to inet sockets: Minix. If we do return to Unix sockets eventually, what is the thinking on what we would do for Minix?

Jan. 31, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Sat, Jan 30, 2010 at 08:32:49PM -0800, bf wrote: > > > --- On Sat, 1/30/10, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > From: Jorge Arellano Cid <jcid(a)dillo.org> > > Subject: Re: [Dillo-dev] Starting dpis on FreeBSD: blackhole(4) timeouts > > To: dillo-dev(a)dillo.org > > Date: Saturday, January 30, 2010, 9:08 AM > > On Sat, Jan 30, 2010 at 04:13:29AM > > -0800, bf wrote: > > >? I'm? using? dillo on FreeBSD > > 9-CURRENT, and ever since the dpi > > > framework was converted to use Internet domain > > > sockets, I've been > > > plagued? by? long? delays? > > > when? starting? dpis because I'm using > > > blackhole(4)? by setting net.inet.tcp.blackhole > > > to be nonzero. An > > > example of the problem: > > > > > > Nav_open_url: new url='dpi:/bm/' > > > Dpi_check_dpid_ids: Operation timed out > > > [dpid]: a_Misc_mksecret: e1ab7e05 > > > Dpi_blocking_start_dpid: try 1 > > > dpid started > > > > > > [...] > > > > ? I? understand. Although please notice that it > > looks as expected > > behaviour: the check for a responsive dpid socket is > > delayed just > > as with any port scan. > > > > ? Simple solution: try something like this script to > > start dillo: > > > > #!/bin/sh > > ST="`ps -ef|grep "[0-9] dpid"|wc -l`" > > if [ "$ST" = "1" ]; then > > ???echo "Dpid is running OK!" > > ???dillo > > else > > ???echo "Dpid is NOT running" > > ???dpid & > > ???dillo > > fi > > > Thanks, Jorge, for taking the time to consider this problem and > to propose a workaround. But, as I think you have noticed from a > remark in your second message, this only deals with the initial > timeouts, and not those arising after a period of quiescence. Yes, I notice... > Because blackhole(4) is a common security measure, and because > this problem did not exist under the previous dpi framework, it > must be considered a regression, even if, in hindsight, it is to > be "expected". I was hoping for a solution that did not require > me to either disable blackhole(4), or sit on my hands during > periodic timeouts. Does anyone have any ideas? and also notice an answer to this question there. Back to the problem: You can increase dpid's time to live: dpid/main.c:208 - int dpid_idle_timeout = 60 * 60; /* default, in seconds */ + int dpid_idle_timeout = 60 * 60 * 24; /* default, in seconds */ Or simply let it linger forever: dpid/main.c:207 - int i, n = 0, open_max; + int i, n = 0, linger = 1, open_max; dpid/main.c:295 - if (server_is_running("downloads")) + if (linger || server_is_running("downloads")) Please test both and send your feedback. Once we have a usable workaround, we may think of a good patch (e.g. a dillorc option). Last but not the least, IMHO, using verbs like "plagued" and expressions like "or sit on my hands" doesn't help in dillo-dev. -- Cheers Jorge.-

Jan. 31, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by bf2006a＠yahoo.com

--- On Sat, 1/30/10, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > From: Jorge Arellano Cid <jcid(a)dillo.org> > Subject: Re: [Dillo-dev] Starting dpis on FreeBSD: blackhole(4) timeouts > To: dillo-dev(a)dillo.org > Date: Saturday, January 30, 2010, 9:08 AM > On Sat, Jan 30, 2010 at 04:13:29AM > -0800, bf wrote: > >? I'm? using? dillo on FreeBSD > 9-CURRENT, and ever since the dpi > > framework was converted to use Internet domain > sockets, I've been > > plagued? by? long? delays? > when? starting? dpis because I'm using > > blackhole(4)? by setting net.inet.tcp.blackhole > to be nonzero. An > > example of the problem: > > > > Nav_open_url: new url='dpi:/bm/' > > Dpi_check_dpid_ids: Operation timed out > > [dpid]: a_Misc_mksecret: e1ab7e05 > > Dpi_blocking_start_dpid: try 1 > > dpid started > > > > [...] > > ? I? understand. Although please notice that it > looks as expected > behaviour: the check for a responsive dpid socket is > delayed just > as with any port scan. > > ? Simple solution: try something like this script to > start dillo: > > #!/bin/sh > ST="`ps -ef|grep "[0-9] dpid"|wc -l`" > if [ "$ST" = "1" ]; then > ???echo "Dpid is running OK!" > ???dillo > else > ???echo "Dpid is NOT running" > ???dpid & > ???dillo > fi Thanks, Jorge, for taking the time to consider this problem and to propose a workaround. But, as I think you have noticed from a remark in your second message, this only deals with the initial timeouts, and not those arising after a period of quiescence. Because blackhole(4) is a common security measure, and because this problem did not exist under the previous dpi framework, it must be considered a regression, even if, in hindsight, it is to be "expected". I was hoping for a solution that did not require me to either disable blackhole(4), or sit on my hands during periodic timeouts. Does anyone have any ideas? Regards, b.

Jan. 31, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by jcid＠dillo.org

On Sun, Jan 31, 2010 at 03:00:45AM +0000, corvid wrote: > Jorge wrote: > > On Sat, Jan 30, 2010 at 04:13:29AM -0800, bf wrote: > > > I'm using dillo on FreeBSD 9-CURRENT, and ever since the dpi > > > framework was converted to use Internet domain sockets, I've been > > > plagued by long delays when starting dpis because I'm using > > > blackhole(4) by setting net.inet.tcp.blackhole to be nonzero. An > > > example of the problem: > > > > > > Nav_open_url: new url='dpi:/bm/' > > > Dpi_check_dpid_ids: Operation timed out > > > [dpid]: a_Misc_mksecret: e1ab7e05 > > > Dpi_blocking_start_dpid: try 1 > > > dpid started > > > > > > [...] > > > > I understand. Although please notice that it looks as expected > > behaviour: the check for a responsive dpid socket is delayed just > > as with any port scan. > > Should this issue be listed under *BSD in README? I'd think so. Yes, but let's see how it works. Another required measure would be to increase dpid's time to live. -- Cheers Jorge.-

Jan. 31, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by corvid＠lavabit.com

Jorge wrote: > On Sat, Jan 30, 2010 at 04:13:29AM -0800, bf wrote: > > I'm using dillo on FreeBSD 9-CURRENT, and ever since the dpi > > framework was converted to use Internet domain sockets, I've been > > plagued by long delays when starting dpis because I'm using > > blackhole(4) by setting net.inet.tcp.blackhole to be nonzero. An > > example of the problem: > > > > Nav_open_url: new url='dpi:/bm/' > > Dpi_check_dpid_ids: Operation timed out > > [dpid]: a_Misc_mksecret: e1ab7e05 > > Dpi_blocking_start_dpid: try 1 > > dpid started > > > > [...] > > I understand. Although please notice that it looks as expected > behaviour: the check for a responsive dpid socket is delayed just > as with any port scan. Should this issue be listed under *BSD in README? I'd think so.

Jan. 31, 2010