February 2010 - Dillo-dev - lists.mailman3.com

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