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.

3 months, 3 weeks

Re: FLTK 1.3.0 RC 1 released!

by rogerx.oss＠gmail.com

Dunno about the *other* distros, but Gentoo has several versions of FLTK available including 2.0_pre branch. And, somebody has volunteered a FLTK-1.3_rc1 ebuild on bugs.gentoo.org. Dillo is extremely important on all my platforms as I use Intel P3 CPU's. Using any other browser, and I'm just wasting my CPU cycles with unneeded html scripts -- even with noscript & no-ads plugins for Seamonkey! Maybe hook-up with the FLTK mailing list to see if they're really going to push 1.3? From what I read a week ago, they're devoting all efforts on 1.3 and deprecated 2.0 branch. 2.0 branch might get it's features ported to 1.3. Cheers! -- Roger http://rogerx.freeshell.org/

13 years, 10 months

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

11 years, 10 months

Re: [Dillo-dev] Re: https approaches?

by Jorge Arellano Cid

On Fri, 14 Mar 2003, Ami Fischman wrote: > Thanks for the great summary. > > It looks to me like Jonathan Springer already implemented the BIO approach > for 0.6.5. The fact that it isn't integrated in 0.7 discourages me from > re-writing it for 0.7. > > Since implementing https as a pluging will require a change to the core > dillo code (AFAIK only dpi:/ URL's get handed to plugins), it would be nice > to get confirmation from the authors that this is OK (would be a candidate > for merging in) before spending the time. Jorge? Jorge wrote a full document explaining the dpi concept and also wrote a 30 page bookmarks server to illustrate it. Cheers Jorge.-

21 years, 8 months

Re: [Dillo-dev]Remote control of displayed URL

by Jorge Arellano Cid

Hi Ian, On Tue, 6 Jul 2004, Ian Walberg wrote: > I would like to be able to command dillo via a socket to a specific URL from > another application. > > Can this be done already? Yes it can be done. The specific dpi to provide for that service is not written yet, but the bookmarks-dpi commands dillo to open and refresh URLs all the time. > I tried a simple server plugin but did not get the > results I was looking for. Please explain further what you want to do. It may be a couple of days to write a specific server and get it working depending on what is required. > Thanks No problem. Cheers Jorge.-

20 years, 4 months

Re: Re: [Dillo-dev] [patch] Remote Control

by Melvin Hadasht

Hi Jorge, > > 1.2. HowTo > > [...] > > I think this will be better handled with a dpi. It solves > several problems and also add flexibility (you accurately mention > some of them in: Yes, I already started to read the dpi/dpid docs and sources. As Tomas already suggested, PI infrastructure can be handy, at least on the server side. For a moment; I was even thinking about using Dillo itself as a plugin. > > 3. Caveat > > [...] > > So please give a study to the framework, isolate the needed > commands (mostly done it seems) and I'll answer when time allows > me. > > Sorry for the short answer. :( Thanks for your comments. -- Melvin Hadasht

21 years, 3 months

Re: [Dillo-dev] dillo-0.8.6-rc1

by Jorge Arellano Cid

Hi, On Tue, Mar 21, 2006 at 11:40:04PM -0500, mike obrien wrote: > sorry, is this one an FLTK version? No, it is a GTK1 version that comes with a FLTK2-based downloads plugin. The build process will stop if you don't have FLTK2 installed, because the FLTK2-based downloads dpi is the default, and suggested choice. A simple way to install FLTK2 is to go to www.fltk.org and download the latest weekly snapshot. Now, if you don't want FLTK2 at all, it is possible to use the old downloads dpi. Just check "./configure --help" to know how. End users (those that install from packaged binaries) don't need FLTK2 installed at all, because the downloads dpi will be built statically-linked. -- Cheers Jorge.-

18 years, 7 months

Re: https approaches?

by Ami Fischman

I read the dpi1 document. As far as I can see, it refers to DPI's having a "scope" which URLs can fall inside of, and this scope is always prefixed with "dpi:/". Are you saying that: 1) There is no restriction in the code to the dpi:/ prefix? or, 2) You have no objection to removing the current restriction to dpi:/? If 1, please explain (or point to any documentation/source code that explains). As near as I can see dillo/src/IO/Url.c:a_Url_get_ccc_funct() branches to a_Dpi_ccc only if dpi:/ is the prefix. Furthermore, dillo/src/capi.c:a_Capi_open_url() branches on whether url_str starts with "dpi:/". If 2, do you already have plans in place for maintaining a list of which plugins handle which prefixes? Cheers, -- Ami Fischman usenet(a)fischman.org

21 years, 8 months

Re: [Dillo-dev] [RFC] Quo Vadis Dillo

by Frank de Lange

Paul Pelzl wrote: >On Tue, Nov 11, 2003 at 03:05:17PM +0100, Frank de Lange wrote: > >>Talking about my patch, what does need improvement? >>Some ideas: >>- select contents of location bar/search field when they are focused >> (DONE, in next version) >> > >Heh, I made that change myself about six months ago. > Hm, you should have shared your patch then, ey? I use hooks to grab-focus (->select all) and focus-out-event (->deselect all). What was your solution? >Using the location bar is nice, but I think the Mozilla Firebird >approach presents a more consistent interface. It has a separate >(small) search box to the right of the location bar. Ctrl-L takes you >to the location bar, Ctrl-K takes you to the search bar. > I use Phoenixbird as well (for those few pages which Dillo does not handle good enough). I think the search bar has both advantages and disadvantages. Advantage is that is is a more consistent user interface, disadvantage is that it is small. I'm also not that keen on the combination of page and web search in one dialog: even though they are both 'search' functions, they do conceptually different things. One leads to the loading of a new page, the other does not. I prefer to have the page-loading stuff (locbar, maybe web search bar) separate from non-page-loading stuff. I also think that having a special search bar just for web search is a bit of a waste of screen real estate. The location bar is big enough for even complex search terms, it is always there (will make it popup when pressing CTRL-L in full-screen mode for next patch, just like the search/status bar does now when popup_dialogs=NO). So, I'm not that sure about Firebird's search box. Anyone care to comment on this? >>- more key bindings (replacing current key handling where applicable) >>- remove compile options for tabs and frames, make tabs/frames standard? >> [ PDA/embedded developers: is this OK with you? ] >>- ??? >> > - i-search support within the "View Source" window would be helpful. > The whole 'View Source' window needs an overhaul. Best thing to do would be to implement a (sane, no 'notepad popup spam' like Microsoft products manage to produce) version of the 'view-source' protocol, so source is viewed in a normal window/tab/frame/... That way you get all facilities, for 'free'. This can be implemented in many ways, as a plugin (but I'm not that keen on plugins as they are implemented now...), in the current code, as a dlopen() library (not there yet...), etc. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

21 years

Re: [Dillo-dev] Dillo & Sylpheed-Claws: finally!

by Jorge Arellano Cid

Hi Melvin! > I want just to announce that Sylpheed-Claws (email client), as of the released > version 0.9.0claws, officially supports Dillo as its embedded HTML mail viewer, > in the form of a loadable plugin. Great! This is very good for both projects. I hope people will start to see that dillo can be easily used as an HTML viewing lib. > I would like to thank Jorge for integrating and improving the necessary > patches. Ack! The next step will be the reversal: a dpi to redirect mailto: to Sylpheed-Claws. > I would also like to thank him and all other contributors to Dillo for their > work and for providing such a fast/small/useable/useful browser. Keep on the > good work! Thanks a lot. Cheers Jorge.-

21 years, 5 months

Dillo-dev search results for query "plugin"