Search results for "plugin" - Dillo-dev

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?

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

12 years, 5 months

patch: close windows from menubar

by Johannes.Hofmann＠gmx.de

On Thu, Oct 09, 2008 at 04:26:02PM -0400, Jorge Arellano Cid wrote: > On Wed, Oct 08, 2008 at 05:04:29PM +0200, Joerg Sonnenberger wrote: > > On Wed, Oct 08, 2008 at 03:32:42PM +0100, Jeremy Henty wrote: > > > On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote: > > > > > > > ... why would you want dillo1 and dillo2 at the same time. > > > > > > I don't know. But when you start saying "No-one could *possibly* want > > > to do that, so let's stop supporting it" then you are riding for a > > > fall. Why make ourselves hostages to fortune? Why not make *sure* we > > > avoid the problem rather than gambling that we've second-guessed our > > > entire user base? Murphy's law applies, so play it safe unless > > > there's a compelling reason not to. > > > > You are adding the overhead of changing user behavior though. The claws > > backend might be a good reason, frankly it is the only one I see so far. > > OK, just checked Debian and Ubuntu and both have the dillo > viewer plugin for sylpheed with a dependency on the plain "dillo" > package. > > Looking around in the FLTK docs, there's this function: > > CreatedWindow::set_xid() > > It looks promising. Unfortunately I haven't found a full > code example to make it work. > > If somebody knows how to use it, it'd be simple to make a "drop > in" replacement for dillo1, and avoid the problems discussed in > this thread. I think it's supposed to work more or less like in attached test program. When called with a (decimal) window id (from xlsclients) it draws a small but visible frame on that window. I don't know why it doesn't work correctly. Probabely some more setup necessary... Cheers, Johannes

16 years, 8 months

Re: dns over tls or dns over https

by pastebin＠gmx.com

Thanks - good information are you getting my emails to your gmail email? suggestion add 'to search for mbed TLS only' to '--disable-openssl' switch :) why don't you like dnssec? On Sat, 1 Jun 2024 21:58:42 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Sat, Jun 01, 2024 at 01:27:07PM -0600, pastebin(a)gmx.com wrote: > >Hi > > > >could someone give me an idea about dillo using 'dns over tls' or 'dns > >over https'? or using dnssec? > > The mobilized fork has added support for it, as it is provided by > libcurl (which they have switched to): > > > 20240522: New tarball. To enable DNS-over-HTTPS (DoH), you can now set > > the preference dns_over_https_url. > > https://www.toomanyatoms.com/software/mobilized_dillo.html > > My recommendation is to setup a local resolver on your machine, so all > name resolution is handled by it, not just Dillo. Then you can use > whatever mechanism you want (DoH, DoT, DNSSEC...). > > This would be especially useful if you download a file with Dillo, as it > would launch an external wget process. Or if you use any plugin that > performs network operations on its own. > > Here are some docs (even if you don't use Arch): > > https://wiki.archlinux.org/title/DNS-over-HTTPS > https://wiki.archlinux.org/title/DNSSEC > > I didn't check on my own how well that works, but I would rather keep it > out of Dillo if posible. > > >what about dillo using mbed-tls vs openssl? > >the configuration only shows a --disable-mbedtls > > The DNS resolution is done prior to interacting with any TLS library. > There is also a --disable-openssl switch to search for mbed TLS only, > see ./configure --help. > > 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

Future of dillo2

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Diego wrote: >> With my recent patch (dpid-cleanup-and-DPIPATH.dillo2) one can use the >> attached script to run dillo in-tree which is nice if you just want to >> try it out but should also be useful for development purposes (easily >> manage different branches without the need to install them somewhere). > > The patch seems good to me, but i have not look it very deep or test it. Some more testing turned out that it's not enough to add another path to search for dpis. With no dpidrc fill_services_list fails: [dpid]: dpid.c:467: fill_services_list: Fatal error [dpid]: - Can't find the directory for dpis. This seems very non-plugin-like to me. What's the point in being able to have dpis in ~/.dillo/... but to actually use them you have to add them to your ~/.dillo/dpidrc. I mean it's okay up to this point, but consider you have one custom dpi in ~/.dillo/... : * in order to use it you have to create a custom dpidrc too * judging by a quick look at dpid.c/register_service I'd say that you have to copy the content of the system wide dpidrc file too since your custom one takes preference over the system wide one * now there's a package installed containing one more dpi. It might be doable to update the system wide dpidrc via a post-install script within the package (though thats error prone, you have to remove your entries on package removal etc.) * but what about the custom dpircs? You cannot have the post-install script modify those as well (well, you could, but naaa) > The idea is that each dpi can have its own files in its directory > (preferences, data, cache files ... ). I could go with preferences and data files, but caching feels like a no-no to me since on most installations the user is unable to write into those directories. Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKgZ9oPmwNWhsaZYRAjL+AJ9SjhWBUNh5WcO51GkJLaqtDyjFEwCeMQkz jkTcvl8xIbP3EedZP8T72fc= =xAX5 -----END PGP SIGNATURE-----

17 years, 1 month

web bug save?

by Johannes.Hofmann＠gmx.de

On Fri, Dec 25, 2009 at 05:46:22PM +0000, corvid wrote: > bb wrote: > > *On http://www.dillo.org/ I found the item News and a remark: > > > > 03-Jul-2009 Dillo-2.1.1 has been released to provide a security fix for > > malicious images. I am not shure what is meant with **malicious images? > > Are this so called Web bugs? If yes - how is the blocking done? > > Here's the advisory about the image size problem: > http://www.ocert.org/advisories/ocert-2009-008.html > > > I think there are some strategies possible to prevent a browser from a > > Web Bug attack: > > > > 1. Dont allow to load gifs or pngs from another URL as the actual page > > comes from. (I think to remember that firefox **originally **had such an > > option - not available in the actual version.) > > Here's the beginning of a thread and a patch experimenting with this: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.ht… > (the "same host" option was found to be useless, but I'm still interested in > "same domain") > > > 2. I think one might prepare HTML/CSS not to load such gifs or pngs > > smaller than say about 5x5. Do you think such a measure is feasible in > > Dillo and could that really stop Web Bugs? But I think that there should > > not be a problem to make Web Bugs larger than 1x1pixel as long as they > > are transparent - may be I am wrong, I am just a simple minded user, not > > a web professional. So such a limit might be useless? > > Here's a post and patch experimenting with rejecting images with a dimension > of 0: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007101.html > > > Are there other ideas? I am highly interested in that Web Bug problem. > > I'm glad to hear this, since user interest may encourage things to happen... > Absolutely. We really need to address this. Maybe we can do some more research again about what other browsers or plugins do about this. Cheers, Johannes

15 years, 6 months

SSL in the browser

by james.from.wellington＠gmail.com

I've got gmail going, using the ~/.dillo/certs certificate store. It took a bit of poking around, so I'm attaching my notes to myself in case they're useful for someone else. On 10/23/14, Johannes Hofmann <johannes.hofmann at gmx.de> wrote: > 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 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

10 years, 8 months

Re: Does :hover work in 3.1.1?

by Steinar Bang

>>>>> Rodrigo Arias <rodarima(a)gmail.com>: > You may want to check: > https://dillo-browser.github.io/dillo.org.html > And: > https://dillo-browser.github.io/release/3.1.0/ Right! I knew that actually, from the mastodon post that brought dillo back into my attention. But when looking for stuff I am lazy and I google rather than remembering, and google still throw up the old pages. I'll link to the updated dillo doc from the oldalbum README when I release the non-javascript version. That should help the teensiest bit, at least (also it's a place I can click to to get there). >> If :hover doesn't work I will have to do it a different way: maybe with >> a separate settings page containing a form...? > I recommend you just don't use a drop down, just an static navigation > menu which would work fine with CSS disabled. Yup, the simplest way would be to have just two links in the <nav> one for each locale/language. But that would be too much clutter, I think...? > You could also use a <select> input with a form but it looks more > complicated. Yes, it is. But it's the road I've started to travel. :-) (remains to see if I will travel it to the end or cut my losses and do something simpler...:-) ) I have some copy-pastable code. I did the authservice login and basic self-service pages non-javascript (authservice started as a forms based login plugin for nginx, using apache shiro), and I have stuff I can copy paste from there: https://github.com/steinarb/authservice I don't like JSP or JSF (feels complicated and cluttered) so I did a simple DIY templating with jersey and jsoup (I write HTML pages and read them into jersey resources with jsoup and replace elment content and fill forms). I was looking for sort of the same feel I had when using CGI.pm back in the day: the state is contained in the form data and used to populate the form in the returned HTML, and jsoup gave me that. The use of jersey is because JAX-RS gives a convenient API to tailor responses (HTTP headers and stuff).

11 months

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > 1) detect_libiconv.diff > > > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > > is not in the default linker path, making the build abort. Add > > > > > > a simple test to configure.in to check for libiconv's presence > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > but it turned out that the problem was caused by a libiconv > > > package that was no longer needed. The iconv stuff is now handled > > > in libc on DragonFly... > > > > I have attached the log. Seems like the function signature differs > > on OpenBSD a bit. The testcase modified as such that it includes > > <iconv.h> and calling iconv_open("",""); works for me when doint > > it manually. > > > > I don't know what happens here... > > > > Kind regards, > > Does it fail with current CVS? Sorry, from the log it's clear it doesn't. This page seems to have good info: http://synflood.at/blog/index.php?/plugin/tag/bsd (my understanding of German is barely for survival. ;). -- Cheers Jorge.-

17 years, 5 months

dillo-2.1.tar.bz2

by jcid＠dillo.org

Hi, Working on: 1.- Solve the OpenSSL license issue and upload rc3. On Thu, Jun 18, 2009 at 05:24:25PM +0200, Devid Antonio Filoni wrote: > On Wed, Jun 17, 2009 at 11:45 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > > On Wed, Jun 17, 2009 at 10:01:12PM +0200, Devid Antonio Filoni wrote: > > [...] > > ?Devid: please send me the .deb and its directions when done. > DONE! You can find it at https://launchpad.net/~d.filoni/+archive/ppa > . However I found an error checking my package using lintian: > > E: dillo: possible-gpl-code-linked-with-openssl > N: > N: This package appears to be covered by the GNU GPL but depends on the > N: OpenSSL libssl package and does not mention a license exemption or > N: exception for OpenSSL in its copyright file. The GPL (including version > N: 3) is incompatible with some terms of the OpenSSL license, and therefore > N: Debian does not allow GPL-licensed code linked with OpenSSL libraries > N: unless there is a license exception explicitly permitting this. > N: > N: If only the Debian packaging, or some other part of the package not > N: linked with OpenSSL, is covered by the GNU GPL, please add a lintian > N: override for this tag. Lintian currently has no good way of > N: distinguishing between that case and problematic packages. > N: > N: Severity: serious, Certainty: wild-guess > > Can you please fix it? AFAIS, the only program that links to OpenSSL is the https dpi. i.e. The ssl-enabled dillo binary doesn't link to it. https.filter.dpi links to it. IANAL, but it looks like giving permission for this dpi is enough, and it's already done in its sources (dpi/https.c): * [...] * As a special exception permission is granted to link the code of * the https dillo plugin with the OpenSSL project's "OpenSSL" * library, and distribute the linked executables, without including * the source code for OpenSSL in the source distribution. You must * obey the GNU General Public License, version 3, in all respects * for all of the code used other than "OpenSSL". * */ Please let me know if this is _really_ enough or if some extra legal formula must be added somewhere else. TIA. -- Cheers Jorge.-

16 years

Dillo-dev search results for query "plugin"