Search results for "plugin" - Dillo-dev

Patch for xembed updated

by podarcis＠lavabit.com

> > 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. > Thank you for the infos. Keeping compatability is of course a main goal... Nevertheless I am still not really certain, what the current xembed protocol implementation does - or does *NOT*. 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... > 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. Sorry, but I don't feel able to do this proper. Looking at the xembed protocol specification makes me consider that as an extremely time-consuming task. One idea, which could make us both happy: I have again updated my patch, so that using the xembed protocol can be specified by the application. If using it (and that's the default of course) will run the current xembed code effectively unchanged. This way there should be no compatabiliy issues (The way I have designed that option is only an outline, maybe this can be done better). Only if running with xembed protocol disabled my patch comes into action. --> xembed_patch_xembed_protocol_set.diff --> dembed.cxx Cheers, Podarcis

13 years

Feature Request

by Beartooth＠swva.net

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. -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

17 years, 2 months

Re: RFC repository

by pastebin＠gmx.com

Rodrigo this looks pretty amazing are you thinking along the lines of a plugin that will take for example on the page https://github.com/dillo-browser/rfc the drop down box - when viewed with dillo gives Product Actions Automate any workflow Packages Host and manage packages Security Find and fix vulnerabilities Codespaces Instant dev environments GitHub Copilot Write better code with AI Code review Manage code changes Issues Plan and track work Discussions Collaborate outside of code Sun, 7 Jul 2024 20:53:34 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: and put them into a drop down box? > Hi, > > I've decided to open a RFC-like repository for Dillo here: > > https://github.com/dillo-browser/rfc > > So we can have a centralized place to propose and discuss non-arbitrary > changes or other topics regarding Dillo. For now they are just Markdown > files so they are easy to read and write from any editor and we don't > rely much on GitHub. This also allows contributions by sending patches > via email. > > I'll be collecting more thoughts about the rule-based mechanism I was > talking about in other threads in the RFC-002: Rule-based content > manipulation, here: > > https://github.com/dillo-browser/rfc/blob/rfc-002/rfc-002-rule-based-conten… > > I may also add the PEC proposal I did the other day to classify how > broken are pages when you disable JS, although it not very Dillo > specific: > > https://dillo-browser.github.io/pec/ > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

1 year, 6 months

SSL in the browser

by johannes.hofmann＠gmx.de

On Tue, Oct 21, 2014 at 04:42:24PM +0000, eocene wrote: > Jorge wrote: > > Oh, as our mailsearch doesn't work anymore, is there > > and URL to the original thread (Gmane style) or something? > > > > I'd like to remember what the main point of having SSL inside > > the browser were. I'm getting old. ;) > > Looking briefly, I couldn't find relevant discussion. Possibly it > was off list. My recollection is that, at the time, it had to do with > seeing how SSL was becoming more and more central to browsing with > things like 'HTTPS Everywhere' and 'HTTP Strict Transport Security' > coming along and the issue of privacy gaining increasing public > awareness. > > As for this effort now, I started just by wondering what it would > look like if I integrated Benjamin's code and took out the windows > stuff. It was working pretty well very quickly. And now I like how > much more respectful of servers and resources Dillo can be when > HTTPS is integrated with the http_max_conns queuing and > http_persistent_conns. I think Johannes mentioned something about > Dillo and Tor not working together so well with HTTPS in a dpi, > but I don't know the details there. There is a potential loophole if you start dillo in a torified environment and dpid is running outside. Then https connections go via the non-torified https plugin. It's a small detail, but it happened to me. I'm mostly interested in getting SSL support from unmaintained experimental state to properly supported and maintained option. Cheers, Johannes

11 years, 3 months

Re: Towards 3.2.0

by Kevin Koster

Rodrigo Arias wrote: > > actions="default Open with external tool" > actions="firefox Open with Firefox" > actions="mpv Open with MPV" > actions="mpv-audio Open with MPV (audio)" > handler="/bin/the-handler" One action which would probably complicate things, but likely be among the most used for me, would actually be something like "View as text" (in Dillo). Effectively the inverse of "Save link as...". Websites with annoying MIME settings can give links that one wants to view as text (eg. source code files), but the server assigns a MIME value to them that makes Dillo download them to file. This would force Dillo to display the link as a Text file regardless. Also the view source plugin/rendering can choke a bit performance-wise (on the modestly-powered computers I use, at least) with the multi-MB webpages that are common today. Just viewing as text might be a quicker option, eg. when looking to manually extract a URL meant to load via Javascript. This would be a separate feature to implement, but maybe it would be a good fit for the same sub-menu. > Then, your handler will be invoked using the label as: > > /bin/the-handler <URL> <action-label> > > And you do whatever you find convenient in your handler, so you have > more context to decide the proper action based on the label. I think > this would cover most of the use cases of opening URLs with other > programs without being too convoluted. What would the default behaviour be? Will Dillo install a default handler with its own separate configuration file for setting up the default 'action' behaviours? Or does the feature only appear after each user has created their own handler?

1 year, 3 months

Future of dillo2

by sgeerken＠dillo.org

Hi, just if you were courious: I'm still living and will continue working on dillo. On Sun, Apr 20, Jorge Arellano Cid wrote: > [...] > We could: > > * Attract new developers with a dillo2 release, > leveraging the excellent documentation that we have. We have: - extensive documentations on the critical parts of dillo, expecially on Dw, - a prototype for CSS, and - some more documents and prototypes on future ideas, including scripting and graphical plugins. These should be copied on the web sever, and there should be a prominent note on the web site linking to a new delevolers' section. (Since attracting developers has high priority, this is what a visitor should notice first.) For those not listening to dillo-dev, it is important to know that dillo is still an active project. > * Planning for CSS, floating objects and TABS. > (this are important features to a nice browsing experience) Just FYI: I've started a bit on floats. Jorge, I once told you that it would take a week; actually it is a bit more complicated, nevertheless it is not a big job like CSS. > * Coordinate with FLTK2, DSL (Damn small linux) and other > lightweight distros, Debian installer team, MINIX3, etc. Perhaps we can find there other "lightweight zealots". :-) Sebastian P.S. I'll soon review the changes regarding redrawing and related. When working on floats, I noticed that the redraw optimization after resizes does not work fully correctly, there are situations where only a explicit redraw (e.g. hide and show window) makes size changes visible. P.P.S. In the doxygen documentation, there are two lists, html/bug.html and html/todo.html (generated from the \bug and \todo tags), with open issues. Furthermore, some problems are described in html/fltk-problems.html.

17 years, 8 months

--xid option

by Johannes.Hofmann＠gmx.de

On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote: > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > > 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. > > This is very good. > > I'll have to dig for the sylpheed contact to let them know. > Does anybody here know the email? I already contacted them on irc (#claws on freenode). It would be good if this get's some testing as there seems to be some interaction with the WM in use. I now tested it successful on dwm, twm, and fvwm. Also there are probabely more elegant ways to do it, but for now I think it's better than nothing. Cheers, Johannes

16 years, 8 months

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

16 years

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.

1 year, 6 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.

17 years, 2 months

Dillo-dev search results for query "plugin"