- Dillo-dev - lists.mailman3.com

patches #4634 and #4635
by jcid＠dillo.org July 9, 2016

July 9, 2016

Hi corvid, Some comments: ----------------- Patch #4635: rm IO flags, as they are never used Yes, those linger from a time when shutdown() was used for handling sockets in dillo. Not necessary now since we use read() write() close(). ------------------ Patch #4634: freeing http socket, close FD that's being connected Why did you do this? (i.e. Is there a specific bug?). Beware the FD is closed inside IO.c (OpEnd|OpAbort). If you close it in Http_socket_free(), you are opening race conditions on file descriptors, and coding outside the design. Http_socket_free() is used with the CCC chains, that's why it doesn't close the FD, IO will do it by means of CCC; avoiding race conditions. I haven't tested the code yet, but I'd be amazed if resources don't stop to load at random. For instance, Http_socket_reuse(int Skey) would be activating and reporting success on a socket that's just been closed. Please review all the related patches and be more careful before committing. PD: IIRC I used lsof to check for FD leaks long ago. -- Cheers Jorge.-

1 0

an experiment using mbed TLS
by eocene＠gmx.com July 8, 2016

July 8, 2016

I wanted to see what it would take to use mbed tls with dillo. I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff and I mention it here in case someone should want that one day. That said, it looks like netsurf uses curl, and curl can use any tls library you care to mention. And I'm pretty sure netsurf does javascript.

5 17

URL field / Loading page images / Refreshing DNS cache
by jgaffney＠lawrenceville.org July 8, 2016

July 8, 2016

Jorge Arellano Cid <jcid at dillo.org> writes: [...] >> As far as I can see, one can use the context menu to download >> individual images on a page, or use the panel to toggle image >> loading. But if one wants not to download images in general, but to >> download all the images for some one page (e.g., a weather forecast >> page), then one has to toggle downloading of images on and then off >> again. Maybe a command could be added to KeysCommand_t in keys.hh, >> bound by default to something like Ctrl-i in keys.cc, with a >> corresponding call to a_Html_load_images() in handle() in ui.cc? > > This is interesting. > >> To make the switch to the current snapshot, I had, sadly, to terminate >> an instance of 3.0.5 that had been running continuously for 90 days >> without any issues. > > Wow, it's good to know it can last that long. > > What you describe here is very interesting, in a way I've > come to suspect most users don't have the slightest clue. > > I mean, everyone of us (as dillo users) have *different* use cases. > There's no way we can guess what other people are doing outside of > our awareness realm. > > Now, you're not only a casual user, but one that uses dillo *a lot*, > and appreciate it as an everyday tool. > > That being stated, we are very interested in knowing your use case, > and all the details of it. There's potentially a lot we can learn from it, > and also improve yours/and-the-generic user experience as a result of > this learning. > > So please elaborate on why you like to have it running for that long time, > what do you do with it, how you do it, what problem does it solve that other > tools don't, why is it your choice. What you'd wish it had. I had been using Firefox (and still do, for trusted sites that require javascript), but looked around for another browser when the option to turn off javascript was removed from the preferences dialog -- when javascript is so often the vulnerability behind exploits, I didn't want a browser hoisting in javascript from all over the Internet at its own discretion. (It is still possible to turn javascript off in Firefox if one starts from a script that invokes a prefs.js with a legacy `user_pref("javascript.enabled", false);', or from the internal about:config page, but:) Dillo was one of the few browsers without javascript, and when I checked it out, I found that I agreed very much with Dillo's stated philosophy. And it has been my principal browser ever since. In fact, along with an xterm and Emacs, it's one of the three apps always running on my machine. Things I like about Dillo: Dillo doesn't even include javascript. (I cringe a bit when there is talk on the list about the possibility of including it -- if it is included at some point, I hope that there will be a #define to exclude that code at compile time.) Dillo is small and fast, which is nice not only for general browsing, but when invoking it through, e.g., Emacs to open a link. Dillo let's me configure things the way I like, and when it doesn't do something I want, the code base is accessible enough that I can modify it to do so. (I had in fact already implemented the suggestions I made, but didn't share any patches because, even beyond being an amateur, my hacks tend to be on the ugly side -- the loading of images per page, for example, required adding #include "html.hh" to ui.cc, indicating that I am certainly violating some logic of organization and encapsulation.) Dillo isn't phoning home or doing anything else behind my back, and it let's me easily block ad and other such sites in domainrc. Dillo doesn't try to do all sorts of exotic things, or invoke external apps to do them, with all of the potential security risks. With other browsers, you have to do a lot of work to try to prevent this sort of automagical behavior, and even if it's possible, you aren't left feeling at all confident about having prevented it. Like you, I like that Dillo caches DNS lookups, but of course IP addresses change from time to time for legitimate reasons, so there does need to be a way to flush the cache. Johannes's patch is a good one, but I also still like the idea of using the cache until I need it to refresh. Of course, one could simply start a new instance of Dillo, but I also like that it caches pages in a way that allows me to open a link to a previously visited page off-line, without trying to reconnect and reload it. And -- possibly a unique personal idiosyncrasy -- I like to see links I have visited displayed as visited. Other than that, there really isn't any reason not to be firing up a fresh instance of Dillo whenever it is needed. And probably a lot of other virtues in Dillo that just aren't coming to mind right now. > Some things may be possible, others not, a few may be solved in different > ways, etc. Just learning about those key tasks, or improving a single one, > would be a big gain for all of us. > > Your feedback as a dillo power-user is not only welcomed, it's asked for! > > >> Thanks again for all your hard work! > > Ack! > > > @all: if you're a dillo power-user, let us know about it!

1 0

CSS files downloaded only after reloading page
by Hole.destructor＠gmx.de July 8, 2016

July 8, 2016

Hi Dillo developers, the dillo version from the repository seems to have problems downloading some CSS files the first time some pages are loaded. Though, the remaining CSS files are downloaded when the page is re-loaded using CTRL-r. Example page: https://netzpolitik.org/ Reproduce: 1) dillo https://netzpolitik.org/ -> styles from some CSS files seem to be missing 2) press CTRL-r -> some new CSS file is downloaded and styles are applied 3) press CTRL-r -> some new CSS file is downloaded and styles are applied Best regards, Alex

3 2

URL field / Loading page images / Refreshing DNS cache
by jgaffney＠lawrenceville.org July 8, 2016

July 8, 2016

Johannes Hofmann <johannes.hofmann at gmx.de> writes: [...] >> > To make the switch to the current snapshot, I had, sadly, to terminate >> > an instance of 3.0.5 that had been running continuously for 90 days >> > without any issues. But to get that much up time it was necessary to >> > add a little code so that SIGUSR1 would call a_Dns_freeall() and >> > a_Dns_init(), otherwise (unless I am missing something) Dillo will >> > persist in using the cached lookup indefinitely and not detect when >> > the IP address has changed. So maybe some sort of key binding could >> > be added that would flush the cache when needed? >> >> good point. However I'd like to avoid another key-binding and rather >> do the right thing automatically. >> I could think of a general DNS entry timeout of a couple of seconds. >> In many cases DNS responses are cached at OS-level too respecting >> lifetime values given by the server. > > Firefox has an option to configure the DNS cache expiration > (network.dnsCacheExpiration). > Attached patch implements a similar feature for Dillo. > > Cheers, > Johannes That was fast! Thanks for this; I will try it out.

1 0

URL field / Loading page images / Refreshing DNS cache: Correction
by jgaffney＠lawrenceville.org July 8, 2016

July 8, 2016

Jorge Arellano Cid <jcid at dillo.org> writes: > Hi John, > > On Thu, Jul 07, 2016 at 05:16:04PM -0400, John Gaffney wrote: >> [...] >> > In the current snapshot, the navigation bar has changed, and the URL >> > field does not seem to be taking into account font_factor -- with the >> > result that the window is smaller than the font height. You can test >> > this by setting, e.g., font_factor=2.0 in your dillorc (most >> > dramatically for a tiny panel with small icons). The issue seems to >> > be with this factor not being taken into account when bh and lh are >> > set in make_panel() in ui.cc. >> [...] >> >> I meant what is actually called the "location box," and on comparing >> the code for 3.0.5 to the snapshot of a few days ago, I see that there >> has been no change in the section of make_panel() in ui.cc that sets >> the values of bh, lh, etc. The change that has caused the problem is >> the addition of line 466 of ui.cc: >> >> i->textsize((int) rint(14.0 * prefs.font_factor)); >> >> But the height of the CustInput i is still set to lh, which does not >> take into account prefs.font_factor. > > Yes man. > > That was a quick patch (#4222 in Hg) for a larger font. > > I'll look at it after I finish a general rendering algorithm bug > I'm working in. > > Please be patient. > > BTW, do you really need a font size that enlarges the location box? or > would it be enough to clamp the font size to fit in? The second case is > a much simpler patch. No rush! I was just pointing out the issue; for myself, just commenting out the above line works just fine by reverting to the old behavior and smaller font size in the location bar.

1 0

URL field / Loading page images / Refreshing DNS cache: Correction
by jgaffney＠lawrenceville.org July 8, 2016

July 8, 2016

[...] > In the current snapshot, the navigation bar has changed, and the URL > field does not seem to be taking into account font_factor -- with the > result that the window is smaller than the font height. You can test > this by setting, e.g., font_factor=2.0 in your dillorc (most > dramatically for a tiny panel with small icons). The issue seems to > be with this factor not being taken into account when bh and lh are > set in make_panel() in ui.cc. [...] I meant what is actually called the "location box," and on comparing the code for 3.0.5 to the snapshot of a few days ago, I see that there has been no change in the section of make_panel() in ui.cc that sets the values of bh, lh, etc. The change that has caused the problem is the addition of line 466 of ui.cc: i->textsize((int) rint(14.0 * prefs.font_factor)); But the height of the CustInput i is still set to lh, which does not take into account prefs.font_factor.

3 2

CSS parser bug
by sgeerken＠dillo.org July 5, 2016

July 5, 2016

Hi! The CSS parser seems to have a bug handling shorthand properties. This example works well, both properties are handled correctly: <body style="background: url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> Adding "transparent" (for "background-color"), however, causes the other parts not to be parsed: <body style="background: transparent url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> Not a regression, dillo 3.0.5 shows the same behaviour. Sebastian

2 2

trustworthiness of dillo's TLS code at present
by eocene＠gmx.com July 4, 2016

July 4, 2016

Currently I'd trust dillo for https about as much as I'd trust wget for https. (Not that I've really examined wget, but just as a sort of gauge here...) Back in the DPI days, dillo didn't check hostnames on certificates because that was an impossible nightmare with openssl unless you found the code somewhere to modify for your own project. [By the way, there was outrage a couple of years ago when people realized that lots and lots of tools out there, and tls libraries for popular languages, were using OpenSSL and not doing any hostname validation.] It was only with 3.0.5 that I had looked into TLS myself and learned enough about what's insecure at present to disable old ciphers, disable ssl3, disable tls compression. When TLS moved into the browser with the OpenSSL version, I integrated hostname checking code adapted from wget source. And now mbed TLS does the checking itself. At present, our weakness relative to something like chrome or firefox would be in the area of certificate revocation. Dillo has never had a way to know when a certificate has been revoked. For a while, there were certificate revocation lists (CRLs) that are generally published by the assorted certificate authorities, although sometimes you have to click on agreements to get them. The other problem is that those grow _huge_, and distributions don't generally have packages for them (unlike ca-certificates for root certificates). I wouldn't be surprised if the agreements bar distribution. And there was OCSP, which stands for.... Online Certificate Status Protocol. Every time you get a certificate, you query some server, often a third-party server, and ask it whether this certificate is still valid. But those OCSP servers were/are nowhere near reliable enough, and browsers couldn't very well fail everything when the OCSP servers were being flaky.. So OCSP stapling has been coming along, where the OCSP data comes from the original server along with the certificate. OpenSSL has had OCSP code for a little while, but it's very buggy and not documented, and maybe you could get it to work if your application is exceedingly similar to the sample client, but good luck. mbed TLS has OCSP on their roadmap, but it's not implemented yet. As for what the firefoxes and chromes of the world are up to, firefox ripped out their CRL code a while back and they have some other mechanism where certificate authorities notify them of revocations and they push it out. Because they're still big enough to get certificate authorities to do things for them. And they have 'public key pinning' where a server sends keys to certificates, and the client checks that, when certificates are presented in the future, they continue to use one or more of those keys. My understanding is that this is not at all widely used currently. Like if you go to google while claiming that you're chrome, maybe.

1 0

valgrind errors
by eocene＠gmx.com June 26, 2016

June 26, 2016

Was just having a look at the valgrind errors, and I think the main one is in textblock.cc: int leftBorder = boxOffsetX () + leftInnerPadding + (lines->size () == 0 ? line1OffsetEff : 0); leftBorder being set to line1OffsetEff when line1OffsetEff has not been initialized.

2 4