Search results for "plugin" - Dillo-dev

Re: Hardening Dillo with unveil and pledge

by Rodrigo Arias

Hi Alex, On Sat, Jul 20, 2024 at 09:03:48PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >On Sat, 20 Jul 2024 16:34:47 +0200 >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> >+ if (unveil("/home", "rwc") == -1) { >> >> We may want to constraint this a bit further, so a malicious actor >> cannot read anything from /home/.config. Maybe only /home/.dillo and >> the downloads directory would be suitable? > >Absolutely, that was my initial intention, but just wanted to keep the >example patch as simple as possible. There are a number of things in >$HOME which we probably don't want the browser having access to. Ups, I meant $HOME, not /home :-) There is a dGethomedir() function in dlib/dlib.h to help with this, which also works with other systems. >> >+ if (pledge("stdio rpath wpath cpath inet unix dns tty proc >> >prot_exec", >> >> Does this work with plugins, when the dpid daemon is not running?, as >> I believe it has to fork and exec the dpid program. > >I started with a mindset of "whats the bare minimum of permissions we >can get away with". But its clear that we would need "exec" as well for >full functionality. I can see clear benefits on restricting the file system access, but do you have in mind which type of attack the pledge() configuration would you help mitigate? I think allowing exec and inet is too permissive and would allow an attacker to easily spawn a remote shell as soon as a RCE bug is found. Maybe we can remove exec by spawning first the dpid daemon and then restricting the exec syscall with pledge. Currently it is only started when a request to a dpi plugin via a_Dpi_ccc(). >At some point I may try to submit an improved patch to the OpenBSD >ports maintainers. Unfortunately that won't do much for users of Linux >and other systems. I think is a good idea more OpenBSD people review this part, as I'm not very familiar with pledge(2). However, I'm afraid having this patch only in OpenBSD may cause a negative effect, as we may start receiving bug reports that are only happening on OpenBSD with that patch and cannot be reproduced on Linux or other systems without it. Maybe you can make a hardened Dillo port, so people can still test the non-hardened port to determine if the problem comes from these changes. This could be also controlled by a dillorc option (Dillo shouldn't be able to write dillorc), so it can be disabled for testing. The latter could be applied to upstream Dillo if we allow compiling the pledge part conditionally and would benefit from the CI tests on BSD too. Best, Rodrigo.

July 21, 2024

Patch for xembed updated

by podarcis＠lavabit.com

> Please have a look at the enclosed diff 'xembed_removed_demo.diff', > that removes the *WHOLE* xembed protocol implementation and only > keeps the window creation. > > Still embedding with 'tabbed' works as before. This really makes me > wonder... Update: I just tested Claws Mail (writing this mail with it) from the Ubuntu 12.04 distribution together with the 'Dillo_Viewer' plugin (which was not so easy to get, because it is not longer in this distribution - I had to take it from another distibution, openSuse-12.2) Result: dillo with the *removed xembed support* (see previous posting) integrates perfectly (including resizing) into the Claws Mail preview window! Also does dillo with *my patch*. Just to let you know.. Cheers, podarcis

Jan. 11, 2013

hyphenation in dillo

by corvid＠lavabit.com

Sebastian wrote: > On Mon, Sep 10, corvid wrote: > > I was looking at the src for http://distrowatch.com , and the > > source page is very wide -- wider than any lines, so far as I > > could see. > > There is one line, which is very long (number 54), but the current > release breaks this line into multiple ones. Can someone provide > details about the vsource plugin? The vsource page has <style type="text/css">PRE {white-space: pre-wrap} and the css2 spec says "If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces (U+0020) unbroken by an element boundary is treated as a sequence of non-breaking spaces. However, for 'pre-wrap', a line breaking opportunity exists at the end of the sequence."

Nov. 7, 2012

dillo-2.2 has been released!

by corvid＠lavabit.com

Get it at http://www.dillo.org/download/dillo-2.2.tar.bz2 Some highlights of this release are: - a major overhaul of the cookies subsystem - a reimplementation of the Dillo Plugin (DPI) API - a configurable connection limit - various CSS improvements Anyone using cookies should definitely upgrade, as important security fixes were made in the process of rewriting the cookies module. Pretty much all of the changes that would be of interest to users are mentioned in the ChangeLog ( http://hg.dillo.org/dillo/file/tip/ChangeLog ) In configuration files: dillorc has new options http_max_conns and show_help, and the default for no_proxy has changed. keysrc has new options for save and for various motion commands. You can also use keysym values in the rules now. I think I have the website all updated except for the main page, and Jorge will do the freshmeat stuff.

Feb. 11, 2010

[PATCH] startup window

by thomas-forum＠orgis.org

Am Wed, 1 Apr 2009 09:47:11 +0200 schrieb Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > Hi, > attached patch adds a proper startup screen for dillo. Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". I don't want to be offensive, just voice my concern... Alrighty then, Thomas.

April 1, 2009

Re: [PATCH v2] Unveil patch

by Diego

Hi. Sorry I can't help dillo more. I'm always very busy with my work. El vie, 2 ago 2024 a las 1:24, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > > >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. > > You could use dParser_parse_rc_line() from dlib/dlib.[hc] ../dlib/dlib.c:int dParser_parse_rc_line(char **line, char **name, char **value) ../dlib/dlib.h:int dParser_parse_rc_line(char **line, char **name, char **value); ./srch dParser_parse_rc_line keys.cc: st = dParser_parse_rc_line(&line, &keycomb, &command); prefsparser.cc: st = dParser_parse_rc_line(&line, &name, &value); ../dpid/dpid.c: st = dParser_parse_rc_line(&line, &service, &path); Salud! Diego

Aug. 2, 2024

keyboard shortcuts non-functioning under KDE 3.5.10

by paul＠claws-mail.org

Hi Jorge, On Thu, 4 Jun 2009 12:23:57 -0400 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Paul, please let us know what binding are you trying to make, > what is failing and your keysrc. I'm not actually trying to make any. I got on to this problem when talking to Johannes on #claws - dillo1 had 'show controls' and 'reload' in the context menu, which was always very useful in Claws Mail with the plugin, because it runs `dillo -f`, but anyway... Even the default keybindings don't work for me. I don't have a keysrc file, but I did create one, at Johannes suggestion, but this didn't have any effect either. Pressing key-combos has no effect. best regards Paul -- "Thanks to his green candle, the 'Pataphysician can lighten our darkness."

June 4, 2009

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Fri, May 27, 2011 at 3:53 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > 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). > > Can you point me to parts of code for either of these two code paths? Filename / line number should suffice. > > > 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.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

May 28, 2011

[patch] Gopher DPI

by p37sitdu＠lavabit.com

I implemented basic Gopher support using DPI, patch is attached. It is already quite usable. "URL:" links are not supported, but Gopher servers send redirect pages for compatibility. The only major problem is unrecognized file types. I looked at FTP DPI. It sends Content-type: application/octet-stream. This forces Dillo to ask downloads DPI to start download. With gopher it doesn't work as downloads DPI doesn't suppport gopher. So Dillo just says "Content-Type 'application/octet-stream' not viewable.". I left it as it is for now, because I don't think adding support for all known and unknown protocols into downloads.cc is the right solution. Maybe downloads DPI protocol should be changed so Dillo would feed plugin with data it receives as octet-stream and downloads DPI would only save what it receives to disk instead of connecting to server and downloading the file itself.

Dec. 15, 2012

--xid option

by Johannes.Hofmann＠gmx.de

On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > Hi, > > > > attached patch tries to implement the missing --xid option that is > > used to embed dillo into the claws mailer. > > The right way to do this would probabely be to implement the > > complete XEMBED protocol which is also mentioned in > > doc/fltk-problems.doc. > > However a simple XReparentWindow() seems to work more or less here. > > Please test. > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > e.g. hg add xembed.hh xembed.cc Oh yes. Should be fixed now. Btw. I managed to install the claws mail client including the dillo plugin and it seems to work fine now with dillo2. That's why I just committed the xembed stuff. Cheers, Johannes

May 18, 2009

Dillo-dev search results for query "plugin"