Search results for "plugin" - Dillo-dev

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

3 months, 2 weeks

Re: [Dillo-dev] Very close to a new release!

by Jorge Arellano Cid

On Mon, 3 Feb 2003, TheStar wrote: > > > > > Note to all/self: Dillo will *not* work with autoconf-2.13. > > > > > > Please test our latest CVS. It should work with the old autoconf. > > > > Works fine now, thanks. :) I've been using 0.7.0-pre since last night; > > it works beautifully so far. Can't wait for the release! > > > > Same here, although I'd much prefer having the plugins in some generic place > such as /usr/share/dillo so that I don't have to make sure that each user has > the correct plugin, etc... (Can I do that already?) You can place them anywhere in your PATH or in ~/.dillo/ > I'd also _really_ like to have a "open link with..." dialog/menu/etc... ;) Dpi is the gateway to those extensions. > Great job, Once the cut & paste and downloading are finished, it will > be better than the graphical links! Thanks. Cheers Jorge.-

21 years, 9 months

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

16 years

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

16 years, 8 months

Some thoughts

by Jorge Arellano Cid

On Thu, 17 Apr 2003, Nikita V. Borodikhin wrote: > Hi, All ! > > There is an updated patch (against CVS) to save input values in memory > when form is posted. > > http://tkk.ru/~eliterr/dillo/saving_values.diff Thanks Nikita, both for the patch and for making it a link. I know it needs another revision and the only reason I haven't done it, is because I have a lot of things to sort in the project at this time. The Dillo project is slowly entering into what can be stated as a second stage in its development cycle. We're a single step away from https, Downloads and FTP. The funding initiative also has taken a lot of my time, but its yields is what has made my continued work possible. Now I have to plan for the future: after 0.7.2 is released (with Copy&Paste), most probably the pressure for adding new features will increase (it already had internally!). People will start thinking of using sourceforge an other sites with dillo, and I want the impression that lingers from using the browser there, is of a fast, stable and reliable tool. We're not far from there, and I owe a more detailed planning email to dillo-dev. For now, I'm on 0.7.2 release, then I'll focus on the SSL plugin (asking for the cooperation of all of those that had showed interest and code to make https work). I already have a guy working on the downloads plugin (as his thesis), and as I made the FTP plugin, I know exactly how to integrate it with downloads. Appart from that, I still have to finish the design of dpi initialization, addition, managing etc. (needed to support several dpis at the same time). Add generic patch-reviewing/correcting/integrating, answering the mailing list, keeping the web site updated and you'll have an idea of my duties. Ah, we even hold some nice patches for Linear History, Image menu popup, cache size, speedups and so on, just because we haven't got them stable or polished enough to integrate (within the limited time of our prioritized schedules). Finally I want to send a big thank and my sincere recognition to all of you who have kept following and cooperating (patches, testing, informed comments, documentation, icons, etc) with this project for all (or scattered periods) of its lifespan. Without you, it wouldn't have become what it is today. Sincerely Jorge.-

21 years, 6 months

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/

15 years, 7 months

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

by Jorge Arellano Cid

On Sun, 18 Apr 2004, Jorge Arellano Cid wrote: > > 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. After quickly studying the problem, there's some new code in our CVS for downloads.c (removes a buffer corruption because of improper error message handling). Please test it and tell us how it works. At least is solves the problem in my machine. Cheers Jorge.- PS: Please confirm me you're not using a proxy to go out. If so, maybe the PROXY environment var may help wget to gets it way out.

20 years, 6 months

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

16 years

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

12 years, 11 months

Re: [Dillo-dev] HTTPS support

by CHEE BIN HOH

On Sat, 2003-06-07 at 21:51, Madis Janson wrote: > > On Fri, 6 Jun 2003, Jorge Arellano Cid wrote: > > > The "http to https proxy" is what I call dpi! > > > > I'm working very hard with Ferdi extending the dpi1 design with > > a general plugin manager. We have working code and it had gone > > great on tests. I hope to commit the first version in a week or > > so. > > > Great! > > > > This will ease the process of understanding and developing a > > dpi. I hoped all the concepts and internal working to be clear > > from the dpi1 spec and the bookmarks server code, but it is > > certainly very complex to understand it fully (inside and outside > > of dillo and inside the dpi and within the CCC for dpi). > > It would be useful, if you could put some of the basic dpi server > functionality into a simple library (so dpi tag parsing does not have > to be reimplemented in every dpi server written in C). > > > > Now, as I'm not an HTTPS expert, I don't know what interactions > > will be required to support https fully. That is what data > > exchanges/questions/ are required for each operation. > > > > For instance, when the server's certificate can't be verified > > (by the https dpi in this case), the user must be asked whether > > to accept it under this doubt. This will traduce into a dpi > > command sent to dillo, something like: > > > > <dpi cmd='question' srv='https' > > text='Accept unverified connection from this server?' > > options='YES|NO'> > > > > Then dillo will make the window, ask the user, and send the > > answer back: > > > > <dpi cmd='answer' srv='https' answer='YES'> > > > > ...and the https dpi can resume. > > It would be nice, if some certificate fields (issuer, dates) and > certificate MD5/SHA1 hashes would be also shown to the user. This > allows user to verify the certificate hash in a rare case, when > (s)he has got the hash previously using some trusted channel > (printed to paper for example). > > > > Appart from this one, what else is required? > > That I don't know in detail. <-- (this is a question!) > > On the connection side, nothing. Some way for adding trusted certificates > is needed. This could be achieved by coping these certificate files to > certain directory (like .dillo/certificates), although it is _maybe_ > easier for user, when this can be done using some file open dialog (which > will tell the dpi plugin to get the file from specified location). I think > the dialog way of adding certificates is not essential (notably, because > its a very rare activity). > how about adding client side certificate into the https proxy (dpi plugin), certain website might requires a client certificate (which user can obtain from them), it is good if we can allow the user to add a file certificate so or allow another level of plugin to retrieve the client certificate from like smartcard, or other entity, so the https proxy can verify the client with the server. But this happen very rare. -- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chee Bin HOH (cbhoh) iVEST Department, Mimos Bhd, Technology Park Malaysia, 57000, Kuala Lumpur, Malaysia. http://www.mimos.my http://www.ivest.com.my -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+JkDQAlAFlqwDyl4RAqrhAKClZ50SvSMPeMWYEHbGKQDnfN5FQwCg4JGH u4FBpHbJTKfskuJiS9BjP2o= =pnCn -----END PGP SIGNATURE-----

21 years, 5 months

Dillo-dev search results for query "plugin"