Search results for "plugin" - Dillo-dev

https plugin status

by jcid＠dillo.org

Hi, Just a follow up on https dpi: > [place wrote] > It appears that Capi_dpi_build_cmd() needs to test for "proto.https" instead > of "https"... Yes this is a bug from the latest big dpi upgrade (generic dpi protos). > [Jeremey wrote] > Or maybe Capi_url_uses_dpi() should be checking for "https" and *not* > adding the "proto." prefix? "proto.https" is the right patch. > [Christian wrote] > But what is supposed to be working atm? Really basic, if you can see: https://www.rapidssl.com/test/rapidssl.htm that's all. BTW, with place's patch, I can also see: https://www.ccc.de > [Jeremey wrote] > Getting https working would greatly reduce the number of times I run > Firefox! I thought many https sites needed javascript to work. _Please_ correct me if I'm wrong. :-) > [...] With regard to the missing dialog function, you may get a very good idea by looking at its implementation in dillo-0.8.6. That's what I'd do to answer if I had the time now. -- Cheers Jorge.-

March 15, 2008

Garbage chars added

by sandshrew＠gmail.com

On Thu, 23 Oct 2008 15:41:40 +0000 "corvid" <corvid(a)lavabit.com> wrote: > In fltk/src/TextEditor.cxx, you could try replacing the kf_backspace > with: > > int TextEditor::kf_backspace(int, TextEditor* e) { > int oldpos = e->insert_position(); > if (!e->buffer()->selected() && e->move_left()) > e->buffer()->select(e->insert_position(), oldpos); > kill_selection(e); > e->show_insert_position(); > e->maybe_do_callback(); > return 1; > } > > Looks like their kf_delete is broken as well... > Seems to work now. Maybe you should send them a patch? > Tomas wrote: > > X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.0; i486-pc-linux-gnu) > > Just noticed this. Is claws able to make much use of dillo2? > Jorge put in a special-case workaround for "dillo -l -f -x XID URL" > right before release, but I don't know whether anyone's using it > (or if any claws users even know it's there) With claws I use Gtkhtml2Viewer ( http://www.claws-mail.org/plugin.php?plugin=gtkhtml2 ) -- Brain: an apparatus with which we think we think. - A. Bierce

Oct. 23, 2008

Re: [PATCH v2] Unveil patch

by a1ex＠dismail.de

Hi Rodrigo, On Fri, 2 Aug 2024 01:23:56 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > I'll be doing some tests with your patch when I have a moment. I'll > need to get an OpenBSD VM for testing probably. Sounds great! Let me know if you need any help getting OpenBSD set up. > In the meanwhile, I just wanted to link this compatibility unveil() > function for Linux, so I don't forget the link: > > https://github.com/rpki-client/rpki-client-portable/blob/master/compat/unve… Nice find. Not sure if this will be an issue: /* * This is by no means a proper implementation of unveil() but it is * good enough for rpki-client which uses only a few features. * rpki-client only uses 'r', 'rwc' and 'x' and for 'x' we need to do * some horrible hacks. */ > 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 saw that the OpenBSD developers have placed an "uploads" directory > to place files to be available to be read from the browser, and only > that directory is allowed (along with the downloads dir). It doesn't > sound a bad idea to me. This way we can avoid leaving ~/ unprotected > in the file plugin. What do you think? I believe the approach OpenBSD takes with Firefox and Chromium is to only give the browser access to '~/Downloads', which can be used for both downloads and uploads. Basically, users on OpenBSD are already used to this restriction, most likely already have a ~/Downloads directory, and don't think they would be too troubled to have this restriction in Dillo, especially if it is well documented. > >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. > We can probably put the dUnveil() wrapper into dlib/ so it is > available in all the other parts. Thats a good point, I agree, and will work on it. > >+ dUnveil(prefs.save_dir, "rwc"); > > 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. Regards, Alex

Aug. 2, 2024

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by Christian.Kellermann＠nefkom.net

Hi Jorge, * Jorge Arellano Cid <jcid(a)dillo.org> [080315 18:58]: > Sorry for the late answer, but I've had little spare time, > and several topics to answer. > > Probably you have already read: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… > > an got some info from there. Yes, thanks for the hint, it was insightful. I have spend a few thoughts on the SSL issue and I'd like to hear your opinion on it. The most work that still needs to be done is to handle certificates and the user interaction required to make it usable. The user needs to add trust values to certificates and to add or remove them offline. I think this can fit well into a server dpi. Adding and deleting bookmarks could be done similar to handling bookmarks. Which might be a bit rough but is independent on fltk widgets. I do think that we already have enough dialog types in dillo. Hard coding the certificate handling would not make the situation any better. Also I can imagine this plugin to handle client certificates which I do believe will become a more common requirement for certain applications in the future. Adding secure storage capabilities will be easy. Also people will have the chance to write some "bridging" plugin that extracts the needed data from existing storage sources elsewhere, i.e. certificate servers,... Handling this all internally means that we put functionality into dillo that are needed for, but basically have nothing to do with browsing. As I have grasped the spirit of this project this may not be the way to go. A nice thing about handling https internally is the opportunity to reuse an established connection for more than one request, which might speed up transfers significantly. But on the other hand couldn't this be done by dpid for all filter plugins? Dpid can keep them alive as long as the following requests belong to the same URL, then closing the connection after a timeout? I am sorry if this has been already decided on before. These thoughts were rumaging aroung my head all day now... Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 15, 2008

Dillo + Partial Javascript Support

by matopoftheworld＠live.co.uk

Justus wrote: There are several free ecmascript interpreters available, choosing one of them and putting it into a dillo plugin is the easy part. But in order to be useful the script needs the ability to manipulate the page content. And designing that part right is hard... ... Thanks Justus, corvid also sent an email. I found another thread about Javascript support in the dillo archives: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2005-March/002614.html As I mentioned, I am not interested in the parts of Javascript that does dynamic HTML but the ones that allow logins which I assume is network based (sorry for lack of knowledge, I had done some basic Javascript a year or two ago). Hopefully this will not require too much change to Dillo as my C skills are a bit rusty and would like to concentrate on something small like a plugin while I get up to speed. I've got some time off work so if I don't get distracted I'll have a look how you could go about it. _________________________________________________________________ View your Twitter and Flickr updates from one place ? Learn more! http://clk.atdmt.com/UKM/go/137984870/direct/01/

April 9, 2009

IPv6 and HTTPS (Re: release candidate for dillo-3.0.2)

by Johannes.Hofmann＠gmx.de

On Sun, Dec 04, 2011 at 11:05:15AM -0500, Benjamin Johnson wrote: > Johannes wrote: > > >I doubt it's worth making the current experimental HTTPS plugin > >IPv6 ready. > >We will need a more robust HTTPS solution at some point. > > Cheers, > >Johannes > > Why not just reuse the existing HTTP code? > > *cough* > > http://dillo-win32.sourceforge.net/patches/07-dfcntl.diff > http://dillo-win32.sourceforge.net/patches/08-dsock.diff > http://dillo-win32.sourceforge.net/patches/17-https.diff > > Just add some warning dialogs and you've got everything the plugin > offers, plus greater efficiency, code reuse, IPv6, etc. > > (Not to mention, it's thoroughly tested and quite stable on Linux, > BSD, that other OS with 99% market share, etc. I use it myself > every day.) > > Anyway, all my code's still there if you're interested. Thanks for the offer. Currently the patches don't seem to apply cleanly and they also mix in WIN32 compatibility code. So integration work is needed and also an in depth review of the certificate handling. Cheers, Johannes

Dec. 4, 2011

claws? (Re: [Dillo-dev] Garbage chars added)

by paul＠claws-mail.org

Henri Salo <fgeek at hack.fi> wrote: > > > Tomas wrote: > > > > X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.0; i486-pc-linux-gnu) > > > > > > Just noticed this. Is claws able to make much use of dillo2? > > > Jorge put in a special-case workaround for "dillo -l -f -x XID URL" > > > right before release, but I don't know whether anyone's using it > > > (or if any claws users even know it's there) > > > > > > Hmm...a moment of searching and the first hit I get is > > > http://www.nabble.com/Using-of-Dillo2-td20014194.html > > > which suggests that, no, they don't know. > > > > Athur F. Ucksayke from #claws is interested what command: "dillo -l -f > > -x XID URL" is supposed to do? Is this documented? > > It seems to be so that I didn't really understood or even think about > the name (or more more closely the joke) and this should show to the > community how well people in some projects would like to get contacts > and help things to work. It doesn't show anything like that. It is possible to be serious and mix that with humour, just as it is possible to tell a joke but make a serious point. Mr Ucksayke has been part of the Claws Mail team since day 1, and you don't give up that much of your time over so many years just in order to make low-brow jokes. Since this is seeming way off-topic, I'll bring it back... "dillo -l -f -x XID URL" these options are known by the Claws Mail team, they are built into the Claws Mail Dillo Browser plugin - iirc, they first appeared in Dillo as a result of a discussion between Melvin, the developer of the plugin, and the Dillo team. The Claws Mail users do know these options, at least through the plugins preferences page, and, I would imagine, the majority of them do use these options. imo, having the option to avoid loading of remote content is crucial in an email app's html message display. > Minus points to Athur U. as in claws. Athur U.'s points reset to zero. regards Paul -- "Thanks to his green candle, the 'Pataphysician can lighten our darkness."

Oct. 24, 2008

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

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). > 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.-

May 27, 2011

Latest round of Win32 patches

by Johannes.Hofmann＠gmx.de

Hi Benjamin, On Sat, Jul 02, 2011 at 01:12:51PM -0400, Benjamin Johnson wrote: > In case anyone's still interested, I've got the latest round of > Win32 patches up: > http://dillo-win32.sourceforge.net/dillo/patches.php > > It's still based on dillo2, but since most of the patches are > "behind the scenes" (network code, etc.), they should work fine with > dillo3. (I'm planning to switch over eventually.) Apart from the > portability code, most of it isn't even Windows-specific; I've > personally been using it quite a bit lately on OpenBSD. > > Some highlights: > - Cleaned up sockets portability layer (dsock) > - Transparent SSL support (through dsock) using OpenSSL/CyaSSL I haven't looked at the code yet, but if this could be extended to get proper SSL support it would be really great. > - Built-in libcurl-based downloader with glitch-free user interface ;-) > - Built-in preferences GUI (no manual dillorc editing needed) This is the old plugin or not-plugin discussion, I guess. > - Sane in-memory cookies implementation (no cookies.txt needed) But that means it doesn't support persistent cookies, right? > - Various small tweaks, usability improvements, and bugfixes > > Just thought I'd share, > ~Benjamin That's always appreciated. Cheers, Johannes

July 3, 2011

Patch for xembed updated

by Johannes.Hofmann＠gmx.de

On Fri, Jan 11, 2013 at 06:17:08PM +0100, podarcis wrote: > > > 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.. I know that it works partly with just simple reparenting, but it has problems. We went through all this see the thread starting with: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-May/006453.html and the final success messages from claws-mail people here: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-June/006533.html I don't know if the claws plugin is still used by anyone, but I don't want to remove the code, that proved to be working. Cheers, Johannes

Jan. 13, 2013

Dillo-dev search results for query "plugin"