March 2003 - Dillo-dev - lists.mailman3.com

Two branches?

by TheStar

Why don't we have a branch more like the Linux kernel? I would _love_ to have a cvs branch that had every bit of developmental code in it so that we can see what's happening: gtk2 with pango tabs floating tables support <-- especially this one cut & paste support Even though it will be _very_ unstable. My theory is, if it is good enough for a screenshot, it's good enough for the 'developmental' branch. This would also mean that the developer's personal trees will be better sync'ed Of course, I'm just thinking, as I always do ;) I have yet to code... (A bit of python ;) )

March 6, 2003

Re: [Dillo-dev] freezing of dillo.0.7.0

by Jorge Arellano Cid

On Wed, 5 Mar 2003, robert w hall wrote: > In article <Pine.LNX.4.44.0303051147440.397-100000(a)infinity.cl>, Jorge > Arellano Cid <jcid(a)softhome.net> writes > > [...] > > Yes, the Linux kernel had a bug and it was fixed. > > > > Linux >= 2.4.9 => No problem. > no - see below > > > >> I originally compiled dillo0.6.6 against slack 7, kernel 2.4.5 (IIRC, or > >> even 2.2.18) with no problems. However dillo0.7.0 does freeze, > > NB > >even when > >> compiled against the headers for, and run under, kernel 2.4.19. > > so 2.4.19 + slack 7 + dillo 0.7.0 'ne marche pas' > > BUT it > >> compiles and runs ok when compiled under slack8.1, with the same headers > >> and kernel. > > There are more things in Heaven and Earth... Please test the latest CVS code and tell us how it goes. Cheers Jorge.-

March 6, 2003

Re: [Dillo-dev] More bugfixes

by Sebastian Geerken

On Tue, Mar 04, Jorge Arellano Cid wrote: > Sebastian: Please review BUG#424, Keith says it's a trivial fix. Yes, this is correct. Committed. > Ah, can anyone reproduce/not_reproduce bug 406? I can't. I've tried severals ways to circumvent the internationalization, but could not confirm this bug. Sebastian

March 5, 2003

Re: [Dillo-dev] freezing of dillo.0.7.0

by robert w hall

In article <Pine.LNX.4.44.0303051147440.397-100000(a)infinity.cl>, Jorge Arellano Cid <jcid(a)softhome.net> writes > > >On Thu, 27 Feb 2003, robert w hall wrote: > >> Is the description of the 'freezing' of dillo given in the README an >> uptodate description of the problem. This implies that it is a kernel >> version effect... > > Yes, the Linux kernel had a bug and it was fixed. > > Linux >= 2.4.9 => No problem. no - see below > >> I originally compiled dillo0.6.6 against slack 7, kernel 2.4.5 (IIRC, or >> even 2.2.18) with no problems. However dillo0.7.0 does freeze, NB >even when >> compiled against the headers for, and run under, kernel 2.4.19. so 2.4.19 + slack 7 + dillo 0.7.0 'ne marche pas' > BUT it >> compiles and runs ok when compiled under slack8.1, with the same headers >> and kernel. There are more things in Heaven and Earth... -- robert w hall

March 5, 2003

Alternative toolbar icons

by Jorge Arellano Cid

Hi there! I just updated the Icons page (the toolbar alternatives) (BUG#410). Go give it a look! Cheers Jorge.-

March 5, 2003

Re: a vulnerability in dillo

by Ivan Popov

Hello Jorge, thanks for your answer! On Wed, 5 Mar 2003, Jorge Arellano Cid wrote: > Probably (soon) socket file descriptors will reside in > /tmp/dillo and use temporary filenames, or something akin (this My first reaction is - who would be responsible for creating that /tmp/dillo? The first user? probably not. root at host startup? not a good idea to rely on the host admin to be able to run a program. May be something like /tmp/dillo-<truly-random-chars>/ per dillo instance, then you are rather safe against tampering but you have to make your bookmark server aware of possible parallel server accessing the same bookmarks. I would suggest not to rely on a common name all dillo instances of the same user would share. Then it would be 1. widely known and open to tampering 2. not working across different hosts anyway, as you need a server process per host, while bookmarks file may be shared between hosts. Just in case - I am glad you do not try to put sockets in/under homedirs. 1. the underlying filesystems may not support that 2. there is a hardcoded (in the specification) limit on the path name length of a unix socket - it breaks on some setups with homedirs deep in the filetree I mention it as it is a fairly often mistake of different software with unix sockets, to put sockets under the user's homedir. Best regards and thanks for dillo! -- Ivan

March 5, 2003

Re: [Dillo-dev] Re: hidden fields in forms broken?

by John Bradford

> > I've come across an apparent form anomaly when using dillo to test a > > separate application. > > > > If I create a html form, the data submitted differs depending on whether > > I use "text" or "hidden" input types -- specifically, the "hidden" type > > is not parsed for html entities. This causes breakage when I want to set > > the value to the four-character string x"'y, for example. > > > > The code for this is in html.c, around line 3077 (version 1.132), where > > just using the same "init_str = (value) ? value : NULL;" as most other > > types would work. > > > > >From the comment, it was clearly a deliberate decision to > > leave out entity-parsing for DILLO_HTML_INPUT_HIDDEN (and > > DILLO_HTML_INPUT_PASSWORD, around line 3049). The change appears to have > > been made between revisions 1.5 and 1.6, where the "submit" (and others) > > type explicitly had Html_parse_entities() called but the "hidden" type > > didn't. > > > > I don't see any dispensation in the HTML DTD which makes "hidden" and > > "password" immune to the entity rules. Is the exception in dillo an > > oversight that just hasn't been spotted yet? Or is there some reasoning > > that I'm missing behind the way things are? > > > > For reference, other web browsers I tried took the html fragment > > > > <form> > > <input type=text name=plain value="x"x"> > > <input type=hidden name=hide value="x"x"> > > <input type=submit> > > </form> > > > > and on submission, the URL had the same value for "plain" and "hide". > > In dillo, the query string is plain=x%22x&hide=x%26quot%3Bx > > This is quite an interesting issue! > > I digged through the historical releases and the root of the > problem is very far (before 0.3.2!). > > As I currently see it, the SGML type for those INPUT attribute > values is CDATA, so entities SHOULD/MUST be parsed!!! > > Does anyone know otherwise? I noticed problems with this when I was developing a web based regular expression editor, and thought it was a problem with my code, but checking with another browser, it seemed to be a Dillo bug. Also, note that Dillo breaks on code like this: <input type="hidden" name="foo" value="<b>bar</b>"> displaying "> when it shouldn't do. John.

March 5, 2003

Re: hidden fields in forms broken?

by Jorge Arellano Cid

Francis, > I've come across an apparent form anomaly when using dillo to test a > separate application. > > If I create a html form, the data submitted differs depending on whether > I use "text" or "hidden" input types -- specifically, the "hidden" type > is not parsed for html entities. This causes breakage when I want to set > the value to the four-character string x"'y, for example. > > The code for this is in html.c, around line 3077 (version 1.132), where > just using the same "init_str = (value) ? value : NULL;" as most other > types would work. > > >From the comment, it was clearly a deliberate decision to > leave out entity-parsing for DILLO_HTML_INPUT_HIDDEN (and > DILLO_HTML_INPUT_PASSWORD, around line 3049). The change appears to have > been made between revisions 1.5 and 1.6, where the "submit" (and others) > type explicitly had Html_parse_entities() called but the "hidden" type > didn't. > > I don't see any dispensation in the HTML DTD which makes "hidden" and > "password" immune to the entity rules. Is the exception in dillo an > oversight that just hasn't been spotted yet? Or is there some reasoning > that I'm missing behind the way things are? > > For reference, other web browsers I tried took the html fragment > > <form> > <input type=text name=plain value="x"x"> > <input type=hidden name=hide value="x"x"> > <input type=submit> > </form> > > and on submission, the URL had the same value for "plain" and "hide". > In dillo, the query string is plain=x%22x&hide=x%26quot%3Bx This is quite an interesting issue! I digged through the historical releases and the root of the problem is very far (before 0.3.2!). As I currently see it, the SGML type for those INPUT attribute values is CDATA, so entities SHOULD/MUST be parsed!!! Does anyone know otherwise? Cheers Jorge.-

March 5, 2003

Re: a vulnerability in dillo

by Jorge Arellano Cid

On Sun, 2 Mar 2003, Ivan Popov wrote: > Hello, > > having read the statement about dillo being a secure browser, It tries to be! > I want to draw your attention to the exploitable in different ways > bookmarks plugin interface. > > I submitted it as a bug and mentioned denial-of-service only, but creating > predictably named sockets in /tmp opens to other possible attacks > (e.g. spoofing your bookmarks) as well. > > I realize dillo and the plugins are evolving at fast rate, but this issue > can (and should?) be fixed even on the early stages of development. Probably (soon) socket file descriptors will reside in /tmp/dillo and use temporary filenames, or something akin (this also solves the problem of a pre-existent file with the same name). > Thanks for the great software! > I appreciate dillo - it is small, fast and functional. Thanks for your nice comments too. Cheers Jorge.-

March 5, 2003

Re: [Dillo-dev] freezing of dillo.0.7.0

by Jorge Arellano Cid

On Thu, 27 Feb 2003, robert w hall wrote: > Is the description of the 'freezing' of dillo given in the README an > uptodate description of the problem. This implies that it is a kernel > version effect... Yes, the Linux kernel had a bug and it was fixed. Linux >= 2.4.9 => No problem. > I originally compiled dillo0.6.6 against slack 7, kernel 2.4.5 (IIRC, or > even 2.2.18) with no problems. However dillo0.7.0 does freeze, even when > compiled against the headers for, and run under, kernel 2.4.19. BUT it > compiles and runs ok when compiled under slack8.1, with the same headers > and kernel. > Is this a gcc problem? (I'm using 2.91.66 with slack 7). It may be another kind of freeze! Please get the latest CVS and test it (dillo 0.7.0 freezes on Solaris because of another bug, but it's fixed on the CVS). I've used Slackware since 3.5 aprox. and never had problems with the default gcc. > (The suggested patch poll-fix-fast of course does not run in cleanly > against 0.7.0., and though the source compiles the executable still > freezes). Yes, it's quite a burden to maintain such patches, and the right fix is to upgrade the kernel. > Sorry if I've missed something on this. HTH, and as I said, it was probably another thing... Cheers Jorge.-

March 5, 2003