January 2004 - Dillo-dev - lists.mailman3.com

Re: Herba.l Products of the year, 2003
by Berryj 15 Jan '04

15 Jan '04

1 0

Re: Herba.l Products of the year, 2003
by Roberto.assente 15 Jan '04

15 Jan '04

1 0

Re: spam-safe and basic auth
by Jorge Arellano Cid 07 Jan '04

07 Jan '04

On Wed, 7 Jan 2004, Francis Daly wrote: > On Fri, Dec 19, 2003 at 05:45:50PM +0000, Francis Daly wrote: > > On Fri, Dec 12, 2003 at 06:32:54PM -0300, Jorge Arellano Cid wrote: > > > [...] > > > On to another topic, have you had a look at the basic > > > authentication patch by Madis and Tor? > > I've spent a few evenings on this now, and have through the mzz auth > patch, and tried implementing something similar myself. I don't see how > mzz avoids the "redirect loop" problem which it seems to generate. I got > the full mzz-wtab.diff file which applies cleanly to the 0.7.3 code, and > it compiled and ran okay, but failed to even ask for authentication when > I tried it against a 401 page. And it gave the "redirect loop" warning. > > So "doesn't work for me" is the best I can report about it for now, > unfortunately. I'm moving this thread to dillo-dev, just in case Madis or somebody else is interested in helping the development of this feature. > I believe that a 401-handler could be broadly analogous to the 30x > handler, Cache_redirect(). Within Cache_parse_header(), I set a new > value CA_Unauthorized for entry->Flags for a 401 response; and then > within Cache_process_queue(), if that value is set, call the new > Cache_reload_auth() just after where Cache_redirect() is called. Interesting idea. > For adding the Authorization: header, I just edit Http_query to > include an appropriate header if URL_RealmAccess is set (it's not used > elsewhere, and looks like it was intended for 401 usage); and within > Cache_reload_auth(), I set URL_RealmAccess and URL_E2EReload and call > a_Nav_push(). It seems to work fine for authentication pages with no > images, and for authentication pages with images which don't require > authentication. But images that *do* require authentication cause > breakage. Yes, a_Nav_push is for root urls (WEB_RootUrl). > The difficulty is in how to handle non-WEB_RootUrl requests -- I > was following Cache_redirect() for inspiration, and it appears that > Cache_redirect() just ignores them, and I don't see a clean way to > manage them. > > Why are sub entity redirections ignored? Is it because of > security/privacy concerns, or because it was difficult to do them > right? Because the only sub-entity type that dillo handles is image, and near 99% of image redirections is advertising, so given the state of the web, it's a feature! What could be done: my first thought is to check whether an URL (root or not) requires authentication (a flag). If it requires it and we have the auth cached, load it, if not, ignore. > If the former, then whatever the original plan was (using > a_Cache_open_url() or similar) would be worth learning. If the latter, > then unfortunately, in order to handle authentication it's going to have > to be addressed some time :-( Unfortunately I have little time to devote to this design, as I'm given priority to pushing the next release, that is, stabilizing the dpi framework (hopefully done), making the HTML warnings go into a window (not stdout), and adding an HTML error counter together with a "combat mode" parsing feature (a way to try to render pages full of errors in a simplistic but viewable way). Ah, and also giving a check to Keyb-nav-4 if it comes my way... > As I see it, the ideal situation would be that when Cache_parse_header() > finds the 401, it would be useful to check whether we have suitable > authentication credentials, and if so, initiate a new http request which > will feed into (and replace) the same "entry". Doing that directly, > though, probably cuts across too many layers of abstraction. Funny, quite the same I described above! No not that many layers. As you noticed, it can be viewed as a redirection (that asks for credentials on root pages.). It should be possible to implement it this way without breaking the current model. > (I did all my testing on the 0.7.3 codebase; I've just had a look at > CVS and it doesn't appear significantly different.) > > I'm quite happy to keep working on getting authentication working > (Basic, initially, but with the possibility of adding Digest or > anything else in the future) -- if you have any known-dead-ends from > implementing Cache_redirect, or ideas of "safe" ways to intercept the > cache handling, I'd appreciate hearing them. Try to prototype the idea above. It should work. Sorry for not being of more help by now. Cheers Jorge.-

1 0

Re: dillo configuration on AIX
by Jorge Arellano Cid 07 Jan '04

07 Jan '04

On Wed, 7 Jan 2004, Riccardo wrote: > Hello, Hi! > I have a question whichmight be a short configuration question. I'm > trying to build dillo 0.7.3 on AIX 4.2.1 using gcc. I already installed > and tested gtk and pth. Pth is different from pthread (POSIX threads). > > when configuring dillo it says it can't find pthreads. In fact it tries > -pthread. I'm sure that AIX has native threads, Yes, but our configure doesn't detect them yet. Although this should not be hard to do: Get the detected target system type string from the configure script. That is, near the third line of output, it says something like: checking target system type... i586-pc-linux-gnu Then add that option to "configure.in" inside the case statement for pthreads. Something like: [...] case $target in *-*-linux*|*-*-solaris*) AC_CHECK_LIB(pthread, pthread_create) ;; + *-*-aix*) + AC_CHECK_LIB(pthreads, pthread_create) + ;; [...] Then follow the directives at: http://home.t-online.de/home/Andreas.Steinmetz/unix/pthreads.html That is basically adding a call to pthread_init() somewhere in main() in dillo.c. Run autoreconf or autogen.sh, configure, make, tweak and send some feedback! :-) > but in any case -lpth > should be used to use libpth. I'm not an expert with AIX development, > I'm using version 4.2.1. > Can dillo be linked against lpth? other projects usually have a > configure option top select the threading model. Against Pth, no. Cheers Jorge.-

2 1

MINISTRY OF MINES AND NATURAL RESOURCES,SIERRA-LEONE
by BRIGEDIER EVANS GIWA 07 Jan '04

07 Jan '04

Dear sir, I PRESUME THIS LETTER WILL NOT BE A SURPRISE TO YOU. I am Brigedier Evans Giwa, a soldier by profession, formerly a director with the ministry of Mines and Natural Resources in SIERRA-LEONE before the out - break of the civil war in Sierra-Leone. When I was the director with that ministry, I acted as a link between foreign buyers of Diamonds and the Sierra-Leonian government, but ae a result of the civil war, I diverted the sum of US$36.5 million meant for Sierra-Leone government to a security company in Europe. All I need from you.: (1)Coming up with a viable business that we can invest this fund in. (2)To act as the beneficiary of the said money, as I cannot act in this capacity as I`m still directly or indirect involved in the peace negotiations going on in my country now. (3)To clear the money with the security company in Europe and lodge the money into an account we shall both run. After acknowledging this letter,and indicating your interest and willingness in my proposals, we shall arrange for a meeting in Europe to discuss your areas of interest and investment. As a christain, I will like to invest 20%of the money to help the less priviledged in the society.You willget 25% of the total money for your assistance and 5% will be set aside to offset whatever expenses incurred during the duratation of this transaction. Do kindly contact me through the below email address for further discussion and forsecurity reasons,this business remains confidential. Your Sincerly Brigedier. Evans Giwa giwa(a)consultant.com or egiwa(a)lycos.com

1 0

Improved stability patch for dpi framework!
by Jorge Arellano Cid 05 Jan '04

05 Jan '04

Hi Ferdi, (et all) After spending the last weeks hunting for some bugs in the dpi framework deeply, I've succeeded to track them down, and finally, to fix them! From time to time there were multiple dpid instances, this was due to a race condition while waiting for dpid to be "online"; if the process took around a second, dillo could end launching multiple instances of the daemon (I left a commented sleep in the dpid code that served to reliably reproduce it). Another nasty bug was that sometimes dillo crash-locked when requesting a dpi service, for instance: launch dillo -> ask for bm -> kill dpid -> ask for bm -> crash ...this was because of FD inheritance! The bm dpi survived, and kept its parent's FD open, so the connect-test succeeded but there was no server to answer. This couple was really hard to track. As a by-product, lsof showed a FD leak in dpi.c (one per dpi request) and another for dillorc. All of these bugs are fixed in CVS. The good news is that this is a big step towards 0.8.0 release because the stabilization of the dpi-framework is a necessity. There is still at least one pending thing to polish, but it is not a big problem to live with it in 0.8.0 because it causes little harm. This is: if dpid crashes (or is killed), the dpi servers will survive, but the new dpid will launch new processes for them (the old ones will last until their bore-time is reached). No crash, no locks. My first idea was to make a connection-test to dpi servers from dpid at start time, but unfortunately, the parent-child relationship would be lost for the second dpid, so we have to find another way to tell dpid that a dpi-server has finished. The "srs" may be used, although it may be a bit tricky to do when the dpi server has crashed; anyway, the connection test from dpid can detect the crash and bypass the old server with a new one. Cheers Jorge.-

1 0

Re: dillo 0.73 not compiling on slackware 3.9 ( libc5 )
by Jorge Arellano Cid 04 Jan '04

04 Jan '04

On Sat, 3 Jan 2004, matti christensen wrote: > Hello ! Hi! > > In Your README You asked to email comments on compiling Dillo on libc5, > and here's some of mine. Good, the first in a long time. > - slackware 3.9 is the last one with libc5 ( glibc 2.0.7pre6 ) and ( gcc > 2.7.23 ) No problem, I use slackware, and have deployed dillo on it in much earlier versions. > - kernel is the latest of 2.0 -series ( 2.0.39 ) which i have compiled > according to attached config and dmesg > > - i also compiled following in for Dillo ;o) > > --- XFree 3.3.6 > --- glib 1.2.9 > --- gtk+ 1.2.9 > --- jpeg-6b > --- libpng 1.2.5 > --- libtiff 3.5.7 > --- zlib 1.1.4 > > - when i try to make Dillo after making the changes to dns.c as You kindly > adviced, compiling stops to src/IO/mime.c saying "mime.c:34: parse error > before `static'" OK. It seems to be the G_GNUC_UNUSED directive. Remove lines 31 to 40 in mime.c. It should stop complaining about mime.c. If this is true, as I do expect, do the same with html.c and IO/Url.c. Please report me how it goes to fix it in current CVS. Cheers Jorge.-

1 0