Search results for "plugin" - Dillo-dev

Re: [Dillo-dev] Dillo Configuration

by Jorge Arellano Cid

Hi, On Mon, 29 Sep 2003, Ringwraith wrote: > I'd first like to say thanks for Dillo, its sooo great loading the > complete list of CPAN modules in less than 2 seconds, as compared with > the nice 5 to 10 seconds with mozilla/firebird :) Thanks. Is good to know you like it. > I do not know if this has been discussed but: (yes, to some extent...) > One thing I noticed, as Dillo matures, it will obviously need a > configuration/preferences menu. I am really starting to get pissed off > (pardon lang) at how other browsers use the standard toolkit based > widgets to do their configuration. This, IMHO, with the features of > today's browsers, clutters up the user interface and causes bloat with > the browser. I think having a PURE html interface to doing web browser > configuration would do two important things: > > 1. Gives the flexibility to have a feature rich browser while maintain > simplicity. It is a web browser, 90% of the user interface is a web > page, so why not make the GUI something the user is familiar with. > > 2. Reduces bloat. > > IMHO not so much importantly, Very important for us. > 3. Allows for nice customization (themes) of the user interface by > someone who knows HTML and vi w/o having to recompile dillo. ;) Well, the idea is very close to what you state (1 and 2, 3 as a plus). > I am considering to attempt to make a module for the configuration of > Dillo that will do this: > > 1. Configure all aspect of the browser including the (upcoming?) plugin > support. Dpi is working now. We are polishing it with Ferdi to make it ready for the next release. It has been working for some time though. For instance the bookmarks plugin ships with 0.7.3. > 2. Allow pluggable configuration. If plugins have any configurable > options (sometimes they do), they will also be configurable using the > interface. > > This module would be accessed through something like: > > config:// or about:config (i like config:// much better) As of dpi naming is now, something like: dpi:/preferences/ or dpi:/prefs/ (most probably with a shortcut from some menu) > It would obviously have some security built in so that no one can pull a > IE type trick on us and be able to do things they shouldn't. Currently, dpi checks the request to come from dpi-generated pages... > Anyhow this is just a brainstorm, what are your thoughts on doing > something like this? To me it looks as if you haven't read the dpi docs, and used the dpi framework very much, but your thoughts are quite lined with what we are-doing/want-to-do! Please read doc/Dpid.txt, and play a while with bookmarks.dpi. That will give you a lot of background. With regard to preferences, I'd suggest to start by modifying simple bits first, and then to extend to a broader range. For instance you can try with an on-the-fly change of force_my_colors and later some other simple ones. Beware that the preferences parsing code needs some changes to avoid leaks and conflicts when run twice or more (it was designed with a single pass in mind). This is not hard to change though! Cheers Jorge.-

21 years, 1 month

Re: [Dillo-dev] HTTPS Patch

by Indan Zupancic

Updated the diff, gcc 2.x should work now, link is still http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz Did anyone found the bug yet, without reading the diff? If not, then it's as harmless as I thought ;-). Still not nice of course, but it's unclear where it goes wrong exactly, doesn't seem to be easily fixed without changing Dillo a lot. It would be nice to get some feedback from the Dillo developers, I'd like to know what they think should change before the code is good enough to go into the official Dillo, and if they even consider that of course. I have plenty of ideas, but most of them aren't feasible without merging the two IOData structures (now there is one for the read part, and one for the write part, why, I don't know, doesn't make things simpler), doing that makes it much easier to do certain, more complex things that need to have all the fd related info in one place, like ssl, connection caching (currently Dillo opens and closes a connection for each action, although it seems to work well, it's still more efficient to keep connections open longer, especially with slow/bad network connections), "keep alive" (to avoid timeout problems in ssl, quite annoying when you're taking too much time typing an email), simple ftp support, etc. I know that the Dillo developers want to implement most "extra" features like https/ftp/bookmarks/etc as plugins, but I think it's beter to implement the features that are used a lot, or just very important, like https and ftp, natively in Dillo with a small implementation. The overall code is most times smaller too, can say that Dillo is just 300 K, but it would be a bit weird if the plugins together are bigger than Dillo after a while. https took around 2 Kb, I think I can implement basic FTP (and possibly ftps) in about 15 K, using no external ftp library or program (hopefully 10, worst case 20K). If you let me loose on Dillo's code then this is what I would do: # Cleanup the IO engine, one IOData per fd. # Moving the dns stuff to IO. # Add ftp support. # Add file upload support in html forms. # Add connection caching to IO. # Move all the socket stuff into IO.c, the module that wants to handle opening the connection should also close it (all non-internet sockets, like files. Unix sockets may be added to IO.c.). # Auto keep alive like behaviour for ssl connections. # Maybe always ACCEPT_SESSION for cookies when they come via a https connection. # Get rid of the ccc construction, or change it so that it behaves more logical. My opinion is that you should have either a clear unique API for each module, or one general API that is the same for each module. Something in between like the current ccc functions is only confusing (if you want a chain like behaviour, then use function pointer stuctures or something). # When changing the internal API anyway, making shared library plugins possible too, at least for the IO part (maybe ftp library plugin as proof of concept). # Get rid of the splash stuff, move it to an external html file that is opened by default when nothing else is opened. Currently the splash screen is even opened when you do "dillo http://site.org". Loading a file is almost as fast as the build in splash screen. Removing it makes Dillo smaller (about 10 K), simpler and lets people make their own startup pages (for instance a to hd saved google.com) As you could notice, I'm mainly interested in the internet/IO part, graphical stuff doesn't attract me much. If it did, I would help/start porting Dillo to FLTK. If Dillo decides to go with GTK 2 then I will probably stop using it :(. I don't have enough faith in GTK2, it's already too big (and I saw the test results). If you have GTK 2 running anyway it doesn't matter much if you run Dillo too of course, but that's the case too with all those KDE/Gnome programs. IMHO, you should look at all the code that a program uses, including the one in dependencies. I prefer a program that has it's own small and efficient implementation of something to one that is smaller but uses huge libraries. I'm also thinking about making a Dillo installer (sh script) that downloads and installs the cvs version of Dillo and applies the patches the user wants. This needs some coordination, I saw links to other Dillo patches, but I don't know if they are up to date, nor if the maker is willing to keep that so. Currently the only patches I know that are up to date are Frank's patches and my own https patch. Greetings, Indan ------------------------------------------------- This mail is written in SquirrelMail with Dillo -------------------------------------------------

21 years

Re: [Dillo-dev]Extension/plugin question...

by Jorge Arellano Cid

On Fri, Sep 17, 2004 at 05:23:35PM +0300, Daniel Fairhead wrote: > > Why isn't the magic button there then? > > > > Our main problem is lack of developers, Sebastian and I are > > covered with other works we regard as higher priority, so handy > > task as this (and several others) keep on waiting... > > > > If somebody here wants to implement this menu button in a clean > > way (not as an ad-hoc hack), it'd be very welcomed. > > > > In the same spirit, if someone here has development skills and > > wants to contribute, please let us know. We have plenty of small > > to big size tasks waiting for a developer to work them out. > > I'd be willing to have a try at it. I'm particually good at it, but I'll try. > Any hints or anything would be cool :-) Good! You can start by looking at the patch by Brian. Then look at the force_my_colors dillorc option and hook it to the menu that will pop-up from the new toolbox icon placed to the left of the bug-meter (fvwm comes with nice tiny icons to choose from). Look at the bug meter's menu for an idea of how to implement the menu. Note that the bug-meter menu also appears in the right-click over page one, so you can look at the code for the BACK button right click menu for a simpler example. Hook the menu to the left click. Start with a single menu entry. "Force my colors" in this case. A check box in the menu entry would be nice to hint the user about the current selected state. Shold you get stuck, just ask. -- Cheers Jorge.-

20 years, 1 month

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

11 years, 10 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.

3 months, 1 week

about feedback was: Re: [Dillo-dev] [patch] Cleanup of IO.c

by Andreas Schweitzer

Hi, I post this to the list, so that some other possible future contributor that might get frustrated can find it in the archive :-) > I feel sad and frustrated because of the lack of feedback from the Dillo > developers. I tried to improve Dillo, to add some extra features. Dillo is a > nice browser and I thought that spending my time on it would be appreciated, > but it seems I was wrong. I give up, I'm not going to waste my time on > improving Dillo while all efforts are just ignored or told to be useless > because of the "that mess is fine as it is now" attitude. If the neutral and > obviously (somehow I start doubting that now) improving IO cleanup patch is > ignored, then what chance do I have with cleaning up the CCC horror... I can totally understand you. I, too, sent in patches at times. Not as big as yours, some were useful, some were not. Sometimes, it took quite some time before Jorge looked at the patches and fixed or accepted (or rejected) them. The first time, I was very excited once I submitted the patch. But as time went by and I did not hear anything, I got disappointed, until I finally got feedback - life was good again ;-) ... Anyways, that's how it works here. I got used to it. Also, since Frank and you started contributing great patches, traffic went up quite a bit. I think it's ok, since I skip some threads that I'm not interested in. :-) However, the core developers probably need to read all mails and keep track with a whole lot more patches - therefore, even they may miss one or two patches/suggestions. So, please stay with the project ... hmmm ... some semi-serious suggestion ;-) : do some christmas shopping, enjoy the holidays and wait for the feedback from the developers ...:-) > To give you an idea how bad it is: Unfortunatly I am rather a happy user than a real developer. So, I just read and say "aha" ... Hence, I also could not comment on your cleanup of IO.c > Worst is, making a dpi isn't as simple as making a CGI, as it should be. And > of course the whole dpid construction makes no sense. not really anyway: you > can find all the dpi's the same way as you find the dpid... Sure, dpid has > some minor advantages, but everyhting has _some_ advantages. Currently, I'm just watching the changes to the dpi infrastructure. Sometimes, I too think "hopefully this is not getting too bloated, with two many interfaces". However, overall, I like the dpi idea. There are certain advantages: - For me, it makes it rather easy to contribute, since I need to only write a program and not to dig through dillo's code (if only I did write more than my simplistic finger plugin ;-) ...) - The concept of extra processes instead of extra code has advantages : - with the download plugin being a seperate process you can even log out of X while the download continues (e.g. over night on dial-up). - the bookmark plugin allows for a real bookark server ! This is something I am contemplating about : wouldn't it be cool if you could access the same bookamrks from different machines via a sophisticated bookmark server ? Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

20 years, 11 months

How to get dillo up to speed; was: LinuxBIOS with X Server Inside

by Justus Winter

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey folks :) I completely agree with Marc on this topic. I have been following this list for some time now and I have heard all kinds of people proposing interesting uses for dillo and I like to add one more to this list. I have done some research in web security, mostly session riding based attacks. Dillo, with its missing javascript interpreter and css engine being a feature this time, is not vulnerable against most session riding attacks. Though most session riding attacks require javascript, it has been shown, that port scanning and web server fingerprinting is possible using only html and css. So why not use dillo on workstations in your internal network to protect your intranet web applications against malicious javascript and css? Also with its small codebase (compared to geckos), some kind of auditing might be possible. But on the other hand, more and more web sites and web applications require css (which is definitively a good thing) and javascript (which may not be a good thing). The web is a moving target, and everyone developing a web browser is playing catch up with the standards and with the ever growing demands of users and developers. And I for one think, that no one of the big four is doing very well... Dillo development has stagnated. So with every day that passes, dillos practicability, the number of users and the number of developers interested in doing some work for dillo decreases. I can understand Jorges bitterness, but this wont get dillo anywhere. If its more work for a company (-> money and time) to get dillo up to speed to meet their needs than to strip down gecko or khtml until it fits into their devices (or whatever they want to do with it), they wont choose dillo. With every single day, the value of the dillo codebase decreases. And on some day it wont matter if it is ever released or not, because it is completely useless for the applications and sites out there. Maybe this day has already passed without any one noticing. By the way, I keep referring to "the code". Yes I know that the GTK branch is out there. Yes, I have taken a look at it and yes, I began to develop an plugin, but I realized that the plugin interface was lacking some important things (registering uri handlers comes to mind - it is hardly an plugin if you need to touch and recompile parts of dillo). So I stopped before I began any serious work. Dillo felt dead. No one is going to invest time in an project which was somewhat abandoned by its main developer. No offense, but this is how it feels. Most free software developers are working on these kind of projects in their leisure time, they want to have fun. If dillo wants to attract developers, developing dillo needs to be fun. There are lots and lots of free software projects that discussed how to make developing their software fun. Things like giving write access to repositories to developers interested in development, creating branches or creating a wiki could help. It is somewhat true, that one or two developers working on dillo full time would be nice, but as long as no one pays for this, I don't see how this is possible. But this all or nothing attitude will kill dillo in the long term. Jorge, consider releasing this patch of yours. You have got very little to loose (or am I missing something?) but this might spark some interest in dillo development again. Just my thoughts... Cheers, Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAHnvoPmwNWhsaZYRAoNLAJsHj2vSgz7cNRlhtm5B3YOMHMJV+ACfRt5b lJWqSxIQSwnDeilDYX4AcA8= =mCxX -----END PGP SIGNATURE-----

17 years, 7 months

Re: Some news...

by Jorge Arellano Cid

Hi! > > This has been a very busy week. I didn't anticipate how much > work the dpid (dpi daemon) integration could take. Don't panic > though!, the code that binds it all is running (to some extent) > in my machine. The time consuming problem is that while making > the integration, a lot of design matters spring in, and they take > a lot of time to solve. > > The good news is that it all starts to shape into a more clear > design (the code is still hackish at parts, but it is clear what, > where and how to fix it). > > While working the gory details of it, I realized it'd be a good > idea to make the 0.7.3 release with what we have now (plus a > little bug fix we're working on with Sebastian). That way, > there'll be less pressure on us while polishing the new dpid > implementation, and hey!, it's been a long time since our last > release. > > I'll keep the CVS free of the dpid code until the 0.7.3 release > is done. For the meanwhile, I'll provide a tarball to the new > code. (and if I can't wrap the new code before Monday, I'll > provide a link to the latest dpid testing tarball I have). First, the final code for the 0.7.3 is on the CVS (unless you find a bug in it). It will be released by Wednesday, so please give it a hard test today and tomorrow! With regard to 0.8.0-pre (aka dillo with dpid), here's the good news: * Finally I have a tarball that does bookmarks and downloads with dpid (using wget)! It can handle multiple plugins and is working smoothly. I want to add one more plugin (at least) and update the documentation before commiting it to the CVS (after releasing 0.7.3 of course). For those very interested in studying it, please review: http://dillo.org/download/dpid4.tgz (not my tarball but the dpid testing suite itself) Cheers Jorge.-

21 years, 4 months

Re: [Dillo-dev] ftp, ssl, download plugins not working

by Jorge Arellano Cid

On Sun, 18 Apr 2004, Barry Kauler wrote: > Jorge, > Below is a repeat of part of my last posting in thread "Can't start dpid". > I would like to know, is there anything further that I can do > to help chase this bug down? Yes, surely you can! Yesterday it happened to me on my machine, so today (Sunday 18), I'm going trying to chase the bug. Probably I'll add some debugging code to the dpis and try to reproduce the bug, then I'll contact you. Cheers Jorge.- > > > > First, check whether the bookmarks dpi works. If it does, then > > > the dpid launch (by dillo) and dpi launch (by dpid) are ok. If > > > this is true, test with the hello and the ftp dpis. > > > > > > If all of them work, we should be looking closer into the > > > downloads dpi. > > > > Yes, bookmarks works! > > After creating a bookmark, I then selected it, and this is the stdout: > > > > Dpi_parse_token: [<dpi cmd='start_send_page' url='dpi:/bm/'>] > > Dpi: [Dpi_process_io] IOClose > > Nav_open_url: Url=>http://www.goosee.com< > > > > However, ftp doesn't work. Here is the output: > > > > Nav_open_url: Url=>ftp://ibiblio.org/pub/Linux/distributions< > > url_str = ftp://ibiblio.org/pub/Linux/distributions > > Dpi_parse_token: [<dpi cmd='snwer' to_cmd='open_url' msg='not a directory'>] > > Dpi: [Dpi_process_io] IOClose > > > > That url is a directory. I tried another url, same thing. Putting a "/" on end of url makes no difference. > > > > Regards, > > Barry Kauler > > > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev(a)lists.auriga.wearlab.de > > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > >

20 years, 6 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, 5 months

Dillo-dev search results for query "plugin"