Search results for "plugin" - Dillo-dev

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

12 years, 3 months

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)

17 years

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

12 years, 2 months

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.

8 months

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 >

13 years, 10 months

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.

9 months, 2 weeks

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.-

13 years, 10 months

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.

15 years, 2 months

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Fri, May 27, 2011 at 10:28 AM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Thu, May 26, 2011 at 03:42:04PM -0500, reza farivar wrote: > > On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann > > > > > [...] > > > Did you take special care to compile fltk-1.3 with X11 backend? > > > If not, you might run the dillo as native Cocoa application. > > > In that case you were more successful then me. > > > For me dillo with Cocoa-fltk starts, but does not load any remote > > > pages. There seem to be severe issues with the way fltk handles events > > > in the Cocoa case. > > > > > > > Hmm, maybe I should try recompiling fltk with X11 backend...But my > current > > native version is so close to working with no problems... > > Yes, it's amazing how close it is from working native. > Are plugins working OK? (e.g. can you browse the filesystem?) > 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. > > Do you know how to use gdb? > It would be great to know in what functions the busy wait happens. > It could be a timeout or anything. For this: gdb ./dillo > <when locked on high CPU usage, hit Ctrl-c> bt > Yes, Here's the result. I tried it a couple of times, and this looks like the culprit: #13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554 Those three lines are consistent everytime I break in GDB. The more detailed ones are different of course. Here's one, just in case: #0 0x00007fff87967dc5 in tiny_malloc_from_free_list () #1 0x00007fff87966fdd in szone_malloc_should_clear () #2 0x00007fff8799d32b in szone_memalign () #3 0x00007fff879a46eb in malloc_zone_memalign () #4 0x00007fff87376608 in CFSortIndexes () #5 0x00007fff87376480 in CFQSortArray () #6 0x00007fff87386ad2 in __CFRunLoopDoObservers () #7 0x00007fff87361da4 in CFRunLoopRunSpecific () #8 0x00007fff842457ee in RunCurrentEventLoopInMode () #9 0x00007fff842455f3 in ReceiveNextEventCommon () #10 0x00007fff842454ac in BlockUntilNextEventMatchingListInMode () #11 0x00007fff85739e64 in _DPSNextEvent () #12 0x00007fff857397a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554 #16 0x0000000100003a85 in main (argc=1, argv=0x7fff5fbff828) at dillo.cc:431 -Reza > This can hint us on what may be happening. > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

13 years, 10 months

[patch]: improve the "SSL disabled" warnings.

by onepoint＠starurchin.org

This is a purely cosmetic update to my previous patch: it adds a warning about alpha code to the output of "./configure --help" and improves the appearance of the "SSL is disabled" message from the plugin. It does not change any functionality. Regards, Jeremy Henty

16 years, 5 months

Dillo-dev search results for query "plugin"