Search results for "plugin" - Dillo-dev

Cookies performance

by Johannes.Hofmann＠gmx.de

On Tue, Jan 12, 2010 at 09:46:01PM +0100, Johannes Hofmann wrote: > On Tue, Jan 12, 2010 at 07:06:12PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Jan 12, 2010 at 05:42:03PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > I noticed that since the recent DPI update pages which use > > > > > cookies load slower (e.g. fltk.org) > > > > > Do others also see that? It could also be OS specific. > > > > > > > > I thought it seemed weirdly slow _sometimes_. > > > > I'll have to throw some gprof at it and hope for something > > > > simple and embarrassing. > > > > > > > > (I wonder whether it would be easy to do valgrind with dpid and the > > > > plugins.) > > > > > > I did some truss on the cookies dpi and found that it is reading > > > ~/.dillo/dpid_comm_keys quite often. Maybe that is related. > > > > It looks like it checks it through a_Dpip_check_auth() when it > > gets or sets a msg. As for whether it needs to, I don't know. > > > > I tried a little gprof, but a modest amount of browsing and > > accepting cookies wasn't enough for the dpi to use up enough > > time for gprof to generate stats. > > Yah, I don't think it's CPU bound. There must be something else. I > will have a look at it. Can you please test attached patch, whether it compiles and makes a difference for you? I speeds things up quite a bit here. We might also want to cache SecretKey in a_Dpip_check_auth(). Cheers, Johannes

14 years, 10 months

Re: [Dillo-dev] dillo-0.8.6-pre(CVS) compile error

by Jorge Arellano Cid

Hi, On Mon, Sep 05, 2005 at 02:59:38AM +0200, Diego Sáenz wrote: > El Sun, 4 Sep 2005 02:01:04 -0700 > south park <llmmix(a)gmail.com> escribio: > > > Hi, > > It works if compiled without "--disable-cookies" option. > > how to disable cookies in dillo? > > Dillo disables cookies by default (cookies are configured with > the $HOME/.dillo/cookiesrc file), but the code to use cookies is > in dillo(in that version in a DilloPlugIn outside dillo, but exec > by dillo if cookies enabled) is there. > > Read doc/Cookies.txt in dillo sources for more information. Although 'cookiesrc' is enough to control cookies, the compile option "--disable-cookies" was introduced because it served to reduce dillo's binary size for embedded environments (cookie support code is not small). Even now that most of that code was moved into an external plugin, it still saves some remaining cookie-code inside dillo. A patch for the problem is in the CVS now. Please test it. Note: the cookies.dpi is still compiled when cookies are disabled with "--disable-cookies" (near 5KB that can be safely ignored or deleted because it will never run). I don't feel like complicating the autotools* stuff to make the cookies.dpi not to compile ;-). Ah, I also added a message to remind cookies were disabled at compile time. > More about makefiles: Can somebody write a generic makefile for > DPIs(DilloPlugins) distributed outside dillo source. It need to > install the compiled DPI(DilloPlugIn) in the DPIs system > directory when "make install" run as root or install the DPI in > the $HOME/.dillo/dpi/ when not and then exec "dpidc register" There's a script in the tarball: install-dpi-local. More or less it does what you want. -- Cheers Jorge.-

19 years, 2 months

Re: Hardening Dillo with unveil and pledge

by Rodrigo Arias

Hi Alex, On Sat, Jul 20, 2024 at 04:02:54PM +0200, a1ex(a)dismail.de wrote: >Hi list, > >I have been experimenting with unveil[1] and pledge[2] on Dillo to >reduce possible attack surface. Right now these system calls are >exclusive to OpenBSD, but there are projects[3] working to bring them to >Linux and other systems. > >Basically, unveil restricts which areas of the filesystem a program can >access, and pledge restricts which system calls the program is allowed >to make. > >[1] https://man.openbsd.org/unveil.2 >[2] https://man.openbsd.org/pledge.2 >[3] https://justine.lol/pledge/ > >Initial testing indicates that both of these features are working >correctly with Dillo. I am including a patch which provides some basic >filesystem protection, and limits Dillo to the minimum amount of >syscalls possible. If anyone has questions or comments, they are >welcome. Thanks for the patch, I had just opened an issue on this topic a few days ago: https://github.com/dillo-browser/dillo/issues/225 I believe it would be nice to move the network facing code away from the parsers, so the parser code cannot use the network or read the file system. This requires separating them in different processes. I also have to take a look at Justine implementation of pledge(2) for Linux. Constraining the current design may already lead to some improvement. >+ 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? >+ 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. Easy test: $ dpidc stop $ dillo dpi:/bm/ Best, Rodrigo.

3 months, 3 weeks

Welcome & some news

by Jorge Arellano Cid

Hi there! After a few days watching the subscribers list grow, I think is a good time to welcome all of you to this our new home at the wearLab. We believe this new facilities will bring more pace to our internet related needs, and serve as an excellent base to keep developing dillo. The work had been hectic in the past weeks: moving the site, setting the new facilities, testing, debugging, reviewing, fixing and integrating patches an so on... In this recent past, my personal email has been flooded with dillo-related issues, so once more it's true that when the list is silent a lot of work goes behind the scenes! The plan is to integrate a few more patches I still have in the queue, before digging into dpi to make it work with unix domain sockets, and to enable automatic plugin launching. After that, a bit of testing and the next release will hopefully happen by late January. -- Santa passed near us and left a present! Look at: http://www.linuxfund.org/ This is the first grant Dillo Project receives. It's good news by all means. Thanks to all that took some time to vote! Note that this money doesn't fund the project, it will just let me continue trying with the funding initiative. This is the first priority. -- Considering that 0.7.0 wil be out soon, it'd be good to renew the screenshots page. I took some snaps (to be commited soon). The point is to have small thumbs with high definition big picture links. That way, the visitor can get a closer feel of our clean fonts and rendering. The idea is to show some well looking sites, some classic ones and the "average", to give quick and accurate insight. If you have a good site suggestion, just send the URL to the list so everyone can see! -- Best regards and happy celebrations! Jorge.-

21 years, 10 months

Feature Request

by Johannes.Hofmann＠gmx.de

On Sat, Nov 08, 2008 at 04:40:01PM -0500, me at swva wrote: > > I think I'm being unclear, in two ways. > >>> Just to check, I did this as root : >>> >>> [root@Hbsk2 btth]# rpm -q dillo >>> dillo-0.8.6-7.fc9.i386 >>> [root@Hbsk2 btth]# yum update dillo > ^^^^^^^^^^^^^^^^ >>> Loaded plugins: refresh-packagekit >>> updates-newkey | 2.3 kB 00:00 >>> updates | 2.6 kB 00:00 >>> fedora | 2.4 kB 00:00 >>> Setting up Update Process >>> No Packages marked for Update > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> [root@Hbsk2 btth]# > > On Sat, 8 Nov 2008, Johannes Hofmann wrote: > >> dillo-0.8.6 is no longer supported and you should consider to >> upgrade to dillo-2.0. >> But nevertheless for me it also works with dillo-0.8.6. > > For those who run other OSs, what the emphasized lines mean is the 0.8.6 > is what Fedora has, period. (I run F9, the latest release.) Any idea why > it's so far behind?? I didn't realize 1.0 had become official, let alone > 2.0 > >> If you enter "google.com" in the location bar and hit return >> it doesn't go to google? > > It does indeed. I'm putting this badly. > > I run Alpine 2.0; it is set to launch the default browser, which is > dillo -- and URLs in emails are what I use a default browser for. > > Does this mean something in my Alpine settings (and my Pine 4.64 > settings, which it took over) is wrong? My Fedora default browser setting > is simply "dillo %s"; my Alpine setting is something I'll have to dig > for, as it's buried way deep. I don't know what Alpine exactly does, but if I do dillo google.com on the command line, it works fine with both dillo 2.0 and 0.8.6.

16 years

Re: Updated unveil patch

by Solène Rapenne

Le 28/07/2024 à 19:14, a1ex(a)dismail.de a écrit : > Hi, > > Here is a new patch. I have done quite a bit more work on this and > think it may be close to completion. > > The '~/Downloads' directory has been unveiled to match the behavior of > Firefox and Chromium on OpenBSD, but Dillo's default of '/tmp' > continues to work as well. > > I have also made sure everything works fine when there is no ~/.dillo > directory, Dillo can create it, and also can access the system defaults > in '/usr/local/etc/dillo'. > > dpid is also now unveiled, as well as all of the stock plugins except > hello.dpi, I didn't see any point to that. > > Here are some other tests which I have run: > > - Regular browsing works fine > - Connect to an FTP site and download a file, also view a text file and > view an image > - Open a text and image file from /tmp and ~/Downloads > - Add/remove bookmarks > - Download a file to /tmp and ~/Downloads > - Save a page to /tmp and ~/Downloads > - View source still works > - Fonts and cursor icons are working correctly > - data: uri works correctly with text and images > > So far everything seems to be fine. I will keep testing, but would > really appreciate some help with reviewing this, there could be some > edge-cases which I missed. > > Regards, > Alex > > 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. what happens if you have no ~/.dillo when you start dillo with unveil? why do you need to unveil the same directories multiple times in the code?

3 months, 2 weeks

Re: [Dillo-dev] CinePaint and Windows port

by Jorge Arellano Cid

On Tue, 26 Aug 2003, Robin Rowe wrote: > Hi. I'm the project leader for CinePaint, an open source paint program used > mainly by the motion picture industry. Our code was branched from GIMP in > 1998. Hi! Yes, I knew about your project by the time we were applying to LinuxFund... > > How would the Dillo project feel about Dillo being embedded in another > application as a help browser? Very good. In fact it has been done in the past with the Sylpheed-claws email client: it embeds dillo for secure HTML mail viewing. In fact we're working in a remote control plugin for dillo to allow better support for this kind of functionality. Currently applications can launch Dillo and let the user navigate the help docs without problems. Now, if the app. wants to provide context sensitive help, it needs to end dillo and launch another instance to make it display the required page (quite fast, but not optimal), and here's where we're improving it. > We're looking for a new help system browser and considering Dillo. We are > impressed how compact your implementation is. We only need a limited set of > HTML features: links, images, tables, bullet lists, number lists, headings, > ordinary text, bold, and italic. In these features we need the browser to be > absolutely stable. Any issues there? None! You'll hardly find a browser that's more stable. And for any issue that may arise, you can email us back for support. > > We support all platforms, including Windows. One of the first things I would > intend to do is port Dillo to Windows. I saw in your archives that you had > made some effort in that direction, but it seemed to peter out. What are the > problems? If you need dillo to run on the dark side, take a look at: http://www.hyperborea.org/software/dillo/cygwin.html Cheers Jorge.-

21 years, 2 months

Re: [Dillo-dev]Viewing HTTP Headers with DPI

by Jorge Arellano Cid

On Thu, Jun 09, 2005 at 07:04:09AM +0800, Russell J. Wood wrote: > On Wed, Jun 08, 2005 at 12:46:19PM -0400, Jorge Arellano Cid wrote: > > On Wed, Jun 08, 2005 at 06:31:18AM +0800, Russell J. Wood wrote: > > > On Tue, Jun 07, 2005 at 05:13:11PM -0400, Jorge Arellano Cid wrote: > > > > On Sun, Jun 05, 2005 at 12:17:20PM +0800, Russell J. Wood wrote: > > > > > Hi all, > > > > > > > > > > Is it possible to view all request/response headers using DPI? > > > > > > > > That depends on the specific dpi. Please explain it further. > > > > > > Well, it's not for a specific DPI, I would like to know if it's possible to > > > get that information using DPI as if it is, I would like to write a plugin to > > > do it. > > > > > > It's just I didn't see much in the documentation about getting that information. > > > > Currently, dpip is not providing a dpi-command to request dillo > > for that info. Now, it can be done in a quite similar way that > > the cookies dpi (currently on testing) does. > > > > BTW, what for? (if not under NDA of course :) > > Great to hear it will be possible. just let me know when, and point me to the > documentation. =) > > I like to view HTTP Headers when I've developing web applications or, when I'm > just curious to know what's going on. Usually I use Firefox, but it's just so > damn slow! Right now, you can tell Dillo to print the headers to stdout. Go to Cache_get_header() and: - _MSG("Header [io_len=%d]\n%s", i, hdr->str); + MSG("Header [io_len=%d]\n%s", i, hdr->str); HTH. -- Cheers Jorge.-

19 years, 5 months

CAPI ignores download requests when not in cache or handled by the downloads DPI.

by p37sitdu＠lavabit.com

On Tue, Jan 01, 2013 at 10:30:04PM +0000, Jeremy Henty wrote: > > p37sitdu at lavabit.com wrote: > > > On Sun, Dec 30, 2012 at 05:23:18PM +0000, Jeremy Henty wrote: > > > > > > I wondered why "Save link as" silently failed on some of my local > > > web pages if I had not already visited the link. It turns out > > > they were "file:///" links and "Save link as" sends a download > > > request which the CAPI silently ignores if the URL is not cached > > > and is not handled by the downloads DPI. > > > [...] > > > > [...] > > Instead, Dillo could download files and pass them to downloads DPI. > > Downloads DPI then shows progress and saves files. As I understand, > > the idea is to have one window for all downloads across many copies > > of Dillo where progress can be shown and requests to cancel them can > > be passed to the right copy of Dillo. > > I wonder what is the real benefit of a separate downloads DPI. Is it > actually useful to have one downloads window for all Dillo processes? I think downloading should not be done by downloads DPI: this way it have to support all the protocols Dillo and its plugins support. But tracking of downloads can be left there so we don't see the difference between two dillo processes and two dillo windows. > The downloads DPI is rather different from all the rest: it is the > only one that links to FLTK and it doesn't send HTML back to Dillo. > Do we really benefit from putting downloading in a separate process? Cookies DPI doesn't send HTML too. Downloads and cookies are server DPIs, they are used to share resources between processes.

11 years, 10 months

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Sebastian Geerken

On Thu, Sep 25, Frank de Lange wrote: > It was in reaction to comments from Sebastian that I posed this > question to the list. He suggested removing the conditional compile, > but I want to know what the list has to say on this. As a quick look > at the list archives will show, not everyone likes these new > additions to Dillo. Its not a matter of liking or not, users may simply ignore tabs (and there may perhaps be a _user_ option for alternative presentations of frames). However, conditional compilation makes maintaining more difficult (and since that's the task of Jorge and me, the list is the wrong place to ask), so it is a question whether the reduced binary size outweighs the increased maintaining problems. > I have already removed some preferences which could be combined > (frame_blank_in_tab and tab_on_middle_click -> > tab_instead_of_window) or which should be defaulted to the new > functionality (document_title_use_url). Other suggestions Sebastian > made are: > > - Remove tab title compression/shortening (I might create a new label widget > which compresses/shortens text to a given size for this functionality) > - exchange tab_load_in_background with a UI element/choice (I think this > should be delayed until Dillo has a preference UI/plugin to avoid > unnecessary complexity and one-off solutions) What I meant is that the link menu should have to entries, "Open link in new tab", and "Open link in new background tab" (or so). Options should reflect different user's taste, while this difference depends on the situation. > - rename "DilloDoc" to something else (I do not agree, DilloDoc is > descriptive and short) In a local, experimental version of dillo, I've added a new module, representing the document in a DOM-like way, and which was this morning renamed from "doc.[ch]" to "doctree.[ch]". Your DilloDoc represents mainly the interface part of the document, there are other aspects. Sebastian

21 years, 1 month

Dillo-dev search results for query "plugin"