Search results for "plugin" - Dillo-dev

Re: Updated unveil patch

by Rodrigo Arias

Hi Soléne, Happy to see you here! On Sun, Jul 28, 2024 at 09:31:24PM +0200, Solène Rapenne wrote: >you should provide a command line argument to disable sandboxing, so in case >of a problem users can run dillo without sandboxing and see if it works better, >allowing to figure if sandboxing is the root cause of their problem. I don't think there is a need to use a command line argument, as we can add a configuration option in ~/.dillo/dillorc to disable it. >what happens if you have no ~/.dillo when you start dillo with unveil? Dillo will first try to load ~/.dillo/dillorc, if that fails it will try $prefix/etc/dillo/dillorc, and if that fails too will use the internal defaults. I propose to let the default value for the unveil in the configuration option enabled by default (which will only take effect when unveil support is compiled in). To disable it for testing purposes one can edit $prefix/etc/dillo/dillorc or copy it to ~/.dillo/dillorc and change it there (this is the default workflow for other options too). >why do you need to unveil the same directories multiple times in the >code? Dillo is composed of several plugins that work as separate programs. Including a Dillo plugin daemon (dpid) and several other builtin programs (dpis). Each of those programs is being constrained with unveil differently, as they have different requirements. Best, Rodrigo.

July 28, 2024

Re: FWD - dillo gopher plugin issue (reddit)

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > I don't have a machine with OpenBSD at hand, can you test if the build > succeeds using the current master code in OpenBSD with these CFLAGS? > It does on Linux: > > % git > clone https://git.dillo-browser.org/plugins/gopher && cd gopher % make CC=clang CFLAGS= > "-Wall -std=c99 -D_POSIX_C_SOURCE=200112L" $ make CC=clang CFLAGS="-Wall -std=c99 -D_POSIX_C_SOURCE=200112L" clang -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -I/usr/local/include -I/usr/X11R6/include -c io.c io.c:84:20: error: use of undeclared identifier 'AF_UNSPEC' 84 | hints.ai_family = AF_UNSPEC; | ^ io.c:95:8: warning: call to undeclared function 'socket'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 95 | fd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol); | ^ io.c:97:7: warning: call to undeclared function 'connect'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 97 | if (connect(fd, rp->ai_addr, rp->ai_addrlen) == 0) break; | ^ 2 warnings and 1 error generated. > There are many warnings that should be fixed (as below), but the > current includes should work otherwise. If not, does adding the extra > > + #include <sys/socket.h> > > line solves it? Looks better, now we get this: $ make CC=clang CFLAGS="-Wall -std=c99 -D_POSIX_C_SOURCE=200112L" clang -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -I/usr/local/include -I/usr/X11R6/include -c io.c clang -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -I/usr/local/include -I/usr/X11R6/include -c dpi.c dpi.c:19:47: warning: format specifies type 'unsigned int *' but the argument has type 'char *' [-Wformat] 19 | rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", key); | ~~~ ^~~ | %3s dpi.c:26:35: warning: format specifies type 'unsigned int *' but the argument has type 'char *' [-Wformat] 26 | rc = sscanf(keys, "%*d %4x' '>", local_key); | ~~~ ^~~~~~~~~ | %3s dpi.c:27:34: warning: field precision should have type 'int', but argument has type 'ssize_t' (aka 'long') [-Wformat] 27 | if (rc < 0) err(1, "comm key: %.*s", sz, keys); | ~~^~ ~~ dpi.c:28:35: warning: field precision should have type 'int', but argument has type 'ssize_t' (aka 'long') [-Wformat] 28 | if (rc < 1) errx(1, "comm key: %.*s", sz, keys); | ~~^~ ~~ dpi.c:18:2: warning: array index 30 is past the end of the array (that has type 'char[30]') [-Warray-bounds] 18 | buf[30] = '\0'; | ^ ~~ dpi.c:10:2: note: array 'buf' declared here 10 | char buf[30]; | ^ dpi.c:41:31: warning: field precision should have type 'int', but argument has type 'unsigned long' [-Wformat] 41 | err(1, "bad open_url cmd: %.*s", sizeof(buf), buf); | ~~^~ ~~~~~~~~~~~ dpi.c:51:26: warning: field precision should have type 'int', but argument has type 'size_t' (aka 'unsigned long') [-Wformat] 51 | err(1, "bad url end: %.*s", len, url_buf); | ~~^~ ~~~ 7 warnings generated. Regards, Alex

Oct. 31, 2025

Patch for xembed (text corrected)

by Johannes.Hofmann＠gmx.de

Hi, I test xembed support with the claws mail dillo plugin[1] and tabbed[2]. My guess is that the embedder needs to send some X events to the embedded program (dillo in this case) to make it work properly. Even with your patch dillo doesn't resize properly for me when I change the embedding window. I would look into the tabbed source code[2], which is pretty minimal. Cheers, Johannes [1] http://www.claws-mail.org/plugin.php?plugin=dillo [2] http://tools.suckless.org/tabbed/ On Mon, Dec 10, 2012 at 02:12:34PM +0100, podarcis wrote: > Hi all, > > Here is a patch to make embedding dillo into an X-window work. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > diff -r 9bad41ea1dde src/xembed.cc > --- a/src/xembed.cc Wed Dec 05 13:03:04 2012 +0100 > +++ b/src/xembed.cc Sun Dec 09 10:12:36 2012 +0100 > // TODO: Implement more XEMBED support; > > -void Xembed::show() { > +void Xembed::create() { > createInternal(xid); > setXembedInfo(1); > Fl::event_dispatch(event_handler); > diff -r 9bad41ea1dde src/xembed.hh > --- a/src/xembed.hh Wed Dec 05 13:03:04 2012 +0100 > +++ b/src/xembed.hh Sun Dec 09 10:12:36 2012 +0100 > @@ -14,10 +14,11 @@ > > public: > Xembed(uint32_t xid, int _w, int _h) : Fl_Window(_w, _h) { > - this->xid = xid; > + this->xid = xid; create(); > }; > - void show(); > + void create(); > int handle(int event); > + void resize(int x, int y, int w, int h); > }; > > #endif > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > tested with this FLTK program: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > #include <FL/Fl.H> > #include <FL/Fl_Window.H> > #include <FL/x.H> > #include <cstdio> > #include <iostream> > #include <sstream> > #include <string> > > using namespace std; > > > int main( int argc_, char *argv_[] ) > { > Fl_Window dw( 800, 600, "dillo embedded" ); > dw.resizable( &dw ); > dw.show(); > cout << "dw.xid = " << (unsigned long)fl_xid(&dw) << endl; > ostringstream cmd; > cmd << "dillo -f -g " << > dw.w() << "x" << dw.h() << " --xid " << > (unsigned long)fl_xid(&dw); > if ( argc_ > 1 ) > cmd << " " << argv_[1]; > cmd << " &"; > cout << "system '" << cmd.str() << "'" << endl; > system( cmd.str().c_str() ); > return Fl::run(); > } > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > What does NOT work is automatic resizing of the embedded dillo window, > when the size is changed. This would be nice to have. > > I do not know enough of the embedding stuff, but I wonder if the static > int event_handler() ever gets called with type ClientMessage - at least > I could not make it get there.. > > podarcis > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 11, 2012

https plugin status

by Christian.Kellermann＠nefkom.net

* Jeremy Henty <onepoint(a)starurchin.org> [080315 05:58]: > On Sat, Mar 15, 2008 at 01:22:09AM +0000, Jeremy Henty (ie. me) wrote: > > > I was wrong, the https filter dpi *is* starting. But, its debugging > > messages don't appear because it sends them to stdout, which dpid > > redirects to the DPI socket. This feels ... somehow ... wrong. > > And so it is! (Patch submitted in a new thread.) After redirecting > the debugging messages to stderr I see: > > [https dpi]: {In https.filter.dpi} > [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue > [https dpi]: { exiting https.dpi} > If you add an additional MSG output you see something like this: [https dpi]: {In https.filter.dpi} [https dpi]: dpip_tag <cmd='open_url' url='https://www.ccc.de' '> [https dpi]: ***Value of cmd, url or http_query is NULL - cannot continue [https dpi]: { exiting https.dpi} dpid_tag looks like there is a missing '. I added Index: dpi/https.c =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/dpi/https.c,v retrieving revision 1.1.1.1 diff -b -u -p -r1.1.1.1 https.c --- dpi/https.c 6 Oct 2007 22:36:34 -0000 1.1.1.1 +++ dpi/https.c 15 Mar 2008 07:51:29 -0000 @@ -191,6 +191,9 @@ static void yes_ssl_support(void) /*Get the network address and command to be used*/ dpip_tag = sock_handler_read(sh); + + MSG("dpip_tag %s\n",dpip_tag); + cmd = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "cmd"); url = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "url"); http_query = a_Dpip_get_attr(dpip_tag, strlen(dpip_tag), "query"); I am not sure whether this is really save, is this tag \0 terminated? Nonetheless something is lost on the way... Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 15, 2008

Patch for xembed updated

by Johannes.Hofmann＠gmx.de

Hi, On Sat, Jan 05, 2013 at 10:56:00AM +0100, podarcis wrote: > Hi, > > I have updated my patch (no removal of existing code, added > comments, trimmed the source,..). > > Let me perhaps explain from the beginning: > > My starting point was, that when embedding dillo from an external > program using the --xid parameter, dillo's window didn't show up in > the embedder. Thanks for the updated patches and the background info. Here is some background info on the xembed stuff from my side: dillo2 supported xembed more or less automatically as it was based on gtk2. The claws-mail dillo plugin used this feature to display html. When porting dillo to fltk we had to implement xembed on our own or break support for the claws-mail plugin. That's why we added xembed.cc. > > I have now found, there's a one-line fix for that problem: > > -> dillo_xembed_patch_1.txt I tend to commit this, but I still need to double check that it doesn't cause any problems. The advantage is that it will give some initial encouraging result if someone tries out --xid without a fullblown xembed implementation. > > After that was working again (by the way: it worked in dillo2 > already) I tried to make resizing of the embedder window work too: > > -> dillo_xembed_patch_2.txt > > A test program for all this: > > -> dembed.cxx I would prefer a minimal fltk-based example program in the test directory, that implements the embedder side of xembed. It shouldn't be too hard to do (e.g. by looking at the tabbed sources). It would be cool if you would like to work on that. BTW. we use a pretty restricted set of C++ features in the dillo source tree (e.g. we don't use iostream). Cheers, Johannes

Jan. 8, 2013

Re: [PATCH v2] Unveil patch

by Rodrigo Arias

Hi, On Fri, Aug 02, 2024 at 01:04:32PM +0200, a1ex(a)dismail.de wrote: >> I think a simple approach to test this is to find out if we cannot >> read the ~/.ssh/id_rsa private keys from Dillo or plugins by any >> means. So far I think we could read them by forging a call to the >> file plugin and maybe by forking a new process that doesn't have the >> unveil() protections and then reading ~/.ssh/id_rsa from there. > >Right, but this attack vector seems pretty unlikely, and assumes the >system is already somehow compromised (by calling a malicious program >on the filesystem in an unveiled location). I think an RCE bug could allow an attacker to write an exploit in an HTML document (or image or any other thing parsed from the web) that would cause Dillo to execute the fork() syscall and then access those files and transfer the content to a remote host. See: https://en.wikipedia.org/wiki/Return-oriented_programming If this is the case, unless we prevent Dillo from being able to fork I don't think the unveil(2) protection is enough without pledge(2) to prevent this attack. We can test it by putting this code after the last unveil() call, as if Dillo was running an exploit: int ret = fork(); if (ret < 0) { perror("fork failed"); } else if (ret == 0) { /* Child */ FILE *f = fopen("/home/<theuser>/.ssh/id_rsa", "r"); // Adjust path if (f == NULL) { perror("game over exploit, fopen failed"); } else { int c; while ((c = fgetc(f)) != EOF) fputc(c, stdout); fclose(f); } exit(0); } If you see your SSH key in the stdout, the unveil() protection alone is not enough to mitigate this attack (check that the key exists first, I used id_rsa). This would also confirm that unveil() settings don't get inherited in forked children. >> >To-Do: >> >- Add prefs parsing to plugins to get 'save_dir' (may need help >> >here) >> >> I assume you could reuse the same prefs parser from Dillo, but we >> would need to link the DPIs with some of the code that is now only >> being linked in the browser. > >I have made some efforts to do that, but was not successful yet. I >included an example earlier of downloads.cc where I made some progress, >but still something missing. > >I still wonder if it makes more sense to just use a fixed location >(~/Downloads) if we are calling unveil, and override the save_dir with >that. This ties back to my response above. Maybe for now we can add a simple implementation of the parser just to parse the "save_dir" and the new "enable_unveil" (or similar) option, like dpid is doing for dpi_dir. Parsing the complete dillorc preferences requires splitting the preferences code into something that can be linked standalone in the dpis, which will require more effort. >> What happens if someone puts save_dir to $HOME?, should we restrict >> it maybe? > >To give access to ~/, and yet still protect ~/.ssh, we could do >something like this (simplified example): > >unveil("/home/user", "rwc"); >unveil("/home/user/.ssh", ""); > >But again, maybe it's better to override save_dir entirely if we are >using unveil. I think we could just not allow $HOME to be set as save_dir (or any directory that contains $HOME, like /home) and refuse to start if this is the case. Best, Rodrigo.

Aug. 4, 2024

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: > > On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < > obeythepenguin(a)gmail.com > > > wrote: > > > > > On Fri, 27 May 2011 13:38:43 -0400, reza farivar < > rf.opensource(a)gmail.com> > > > wrote: > > > > > > Yes. Well, the only plugin I could see is the save button on the > panel, > > >> and > > >> it can successfully navigate the filesystem and save a page correctly. > > >> > > > > > > That one isn't a plugin, actually. Does the bookmarks button work? > > > > > > Yes, bookmarks work. (This is a bit of strange implementation of > bookmarks, > > no? took me a bit to find out difference of section and item) > > Good! > > If you can see the html page from the bookmarks, it means the > whole dpi framework is working on Mac; they communicate using > sockets. > > So it seems the main thing pending is socket support in fl_wait > for Mac (see my previous email). > Yes, I also think it's the source of this problem (see my other email). But what really perplexes me is that this happens only when I enter a URL manually. When I follow links from one page to another it never happens. Are you guys using different (FLTK) functions when opening a new page or following a links (whether in the same tab or in a new tab)? And it seems that as Dillo "warms up" I get less of this problem... > > View source works too, and chances are cookies are working (otherwise > many > > servers would complain). I cant find the rest (downloads, etc.) > > If one works, all of them work. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

May 27, 2011

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Tue, Jun 18, 2024 at 03:28:20PM +0200, a1ex(a)dismail.de wrote: >> This also allows patching the HTML of sites so you can fix them to >> work better (or at all) in Dillo. This is also done by Firefox from >> the webcompat[2] project in what they call "interventions", as >> sometimes page authors don't fix them or take a long time, so they >> patch it from the browser directly. You can open about:compat to see >> the long list of patches, here[3] is one for YouTube. > >This would be very impressive, a real step forward for Dillo in my >opinion. Do you think this is something that would be relatively >straight-forward to implement, or is it more of a long-term goal with >lots of work required to get there? Either way, sounds like there are >exciting times ahead for Dillo! Adding a mechanism to rewrite the HTML is surprisingly not super complicated, as the internal design of Dillo is centered around the CCC, the "Concomitant Control Chain", which is basically a chain of bi-directional pipes connected together to pass data around. Here is how Dillo currently receives data from the a TLS server (AFAIK). I'm only drawing the incoming direction, but the outgoing link is similar. Net +--------+ +-------+ +------+ +-------+ ---->| TLS IO |--->| IO |--->| HTTP |--->| CACHE |-... +--------+ +-------+ +------+ +-------+ src/tls.c src/IO.c src/http.c src/capi.c And adding a new rewrite module (named SED in the diagram) would require rerouting the chain to add a new element (not hard): Net +--------+ +-------+ +------+ +=====+ +-------+ ---->| TLS IO |--->| IO |--->| HTTP |---># SED #--->| CACHE |-... +--------+ +-------+ +------+ +=====+ +-------+ src/tls.c src/IO.c src/http.c | src/capi.c | +---------+ | rulesrc | | ... | +---------+ The module can then forward the content parsed from the HTTP module to the appropriate scripts defined in the rules, and then read the output and forward it to the next steps in the chain. When no rules apply, it can just forward the content to the cache as-is. Now, the interesting part is that we can place another SED module between the IO and the HTTP nodes, so we can rewrite the HTML content *and* the HTTP headers too. This would allow for example writing a plugin that matches a given mime type and on-the-fly rewrites it into an HTML file changing the Content-Type header. This is already done by the plugins, but they mix the two things together. For example we can display a .gmi file served via the "gemini:" protocol, but we cannot display a local .gmi file. Same for manual pages with the "man:" protocol, which cannot open manual pages served via "file:" or "http(s):". The solution with the new design would involve: 1) Open a "gemini:" link 2) The request is routed to the gemini: dpi handler (like now) 3) The gemini plugin returns the .gmi file as-is as an HTTP response, instead of converting it to HTML 4) The .gmi mime type matches a rewrite rule and is rewritten into HTML in the SED node. Now, if we open a .gmi via HTTP: 1) Open a "https:" link 2) The request is routed to the usual HTTP/IO/TLS chain 3) The HTTP server returns the .gmi file as-is as an HTTP response. 4) The .gmi mime type matches a rewrite rule, and is rewritten into HTML in the SED node. Notice that the HTTP content can be compressed. So, for example, this simple rewrite script: #!/bin/sh sed 's_www.youtube.com_inv.vern.cc_g' Would only work well in the SED node *after* the HTTP content is uncompressed and the headers removed. The rewrite rules should indicate in which position of the chain they apply. As a side note, keep in mind that all of these pieces work in stream mode. Each node reads a bit of data, process it and sends it to the next node of the chain, without the need to store the whole thing in memory. Same with that sed command I wrote as an example. Best, Rodrigo.

June 18, 2024

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote: > On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: > > > On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < > > obeythepenguin(a)gmail.com > > > > wrote: > > > > > > > On Fri, 27 May 2011 13:38:43 -0400, reza farivar < > > rf.opensource(a)gmail.com> > > > > wrote: > > > > > > > > Yes. Well, the only plugin I could see is the save button on the > > panel, > > > >> and > > > >> it can successfully navigate the filesystem and save a page correctly. > > > >> > > > > > > > > That one isn't a plugin, actually. Does the bookmarks button work? > > > > > > > > Yes, bookmarks work. (This is a bit of strange implementation of > > bookmarks, > > > no? took me a bit to find out difference of section and item) > > > > Good! > > > > If you can see the html page from the bookmarks, it means the > > whole dpi framework is working on Mac; they communicate using > > sockets. > > > > So it seems the main thing pending is socket support in fl_wait > > for Mac (see my previous email). > > > > Yes, I also think it's the source of this problem (see my other email). > > But what really perplexes me is that this happens only when I enter a URL > manually. When I follow links from one page to another it never happens. Are > you guys using different (FLTK) functions when opening a new page or > following a links (whether in the same tab or in a new tab)? No, but when you hit ENTER, FLTK has a chance to queue events and zero-wait timeouts for the widget callback and necessary stuff. OTOH, clicking a link goes another path (inside dillo). > And it seems that as Dillo "warms up" I get less of this problem... Timimg issues are moody. e.g. Have you tried dillo listening a good mp3? :-) BTW, good you asked Manolo G. (FWIW, FLTK2 has code for socket events in Mac). -- Cheers Jorge.-

May 27, 2011

web bug save?

by corvid＠lavabit.com

I wrote: > I wrote: > > I wrote: > > > Johannes wrote: > > > > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > > > > Sometimes I wonder whether > > > > > connecting through to a TOR network could help us a lot with it. > > > > > > > > You can already use dillo with privoxy and tor. We could perhaps > > > > make it more convenient to configure such a setup. > > > > We also would need to make sure that really all requests go through > > > > the proxy, e.g. I'm not sure, whether wget called from dowload.dpi > > > > uses the proxy from dillorc. > > > > > > I have warnings in the FAQ and dillorc that the wget env variables would > > > need to be set appropriately, but it would be nice to have dillo send that > > > to the dpi in requests so that it can set the environment for sure before > > > execing wget. > > > > I just committed a patch to set the environment variable from the preference > > if it wasn't already set. > > > > issues: > > - maybe we should have an ftp_proxy pref, too. > > - ISTR that dillo doesn't understand user/pass in URLs. > > This means that dillo doesn't do the right thing if > > - the env var has the user/pass > > - dillo is setting the env for wget. > > It turns out that if I want to add the ability for ftp/downloads > to do the right thing with the no_proxy pref as well, > I would have to send a no_proxy arg to the dpi. > > It would be cleaner to send the proxy URL to the dpi > (and set/clear it there in the environment for wget) every time > that it's needed than to have the proxy URL in the environment > and send a no_proxy arg when it's needed. > > So I'm going to back out that change. This turns out to be a somewhat complicated situation. I naively imagined that whatever I found in wget's 1500-line manpage was what there was, but since wget is a gnu program, it's a subset selected who-knows-how. wget understands the http_proxy, https_proxy, and ftp_proxy environment vars. dillo understands the http_proxy environment var. If it is not set, dillo will use the http_proxy pref. dillo uses its http_proxy value for both http and the https plugin. Whatever we might do to get *_proxy set a certain way in the environment in the downloads/ftp dpis, wgetrc can override them. - should the https plugin use the https_proxy environment var if it's set? I'm leaning toward no. - should dillo try to set the https_proxy env var from the http_proxy pref for the benefit of the downloads dpi? Well, the downloads dpi doesn't like https anyway right now because we haven't given it any sort of #ifdef ENABLE_SSL add argument "--no-check-certificate" #endif, but we could and probably should add the argument. As for the question, ... not sure. (Maybe we should just let wget do all of our https, at least instead of the current plugin.) - should dillo have https_proxy prefs and ftp_proxy prefs? On one hand it might minimize confusion, but then I could take the same amount of space in dillorc to write a big comment explaining all of this. (The unpleasant part of putting things in dillorc or explaining things in dillorc is that I know that no one who upgrades is going to look through it meticulously to see what tiny things have changed.) wget also understands the no_proxy environment variable and wgetrc option. Dillo understands the no_proxy preference. Coincidentally(?), they have the same format. - Should dillo set the env var for wget from the pref if not set? I think so, for the benefit of http downloads. - Should dillo use the env var for itself if set? I kind of don't want to add the complexity. I don't know. (And to get user/pass into wget for proxy, it seems that the proper thing is to stuff them into the env var *_proxy urls.) Anyway, I'm finding this all somewhat tricky to think about.

Jan. 12, 2010

Dillo-dev search results for query "plugin"