- Dillo-dev - lists.mailman3.com

Re: Release 3.3.0

by Xavier Del Campo Romero

Congratulations and thanks for the hard work, team! Best regards, Xavi On 4/26/26 18:42, Rodrigo Arias wrote: > Hi, > > I'm happy to announce that the Dillo 3.3.0 release is finally out: > > https://dillo-browser.org/release/3.3.0/ > > It follows the FLTK 1.4.5 release made yesterday, which contains some > bug fixes for font rendering with Pango/Cairo. > > Enjoy!, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

April 26, 2026

Release 3.3.0

by Rodrigo Arias

Hi, I'm happy to announce that the Dillo 3.3.0 release is finally out: https://dillo-browser.org/release/3.3.0/ It follows the FLTK 1.4.5 release made yesterday, which contains some bug fixes for font rendering with Pango/Cairo. Enjoy!, Rodrigo.

April 26, 2026

A new SearXNG search randomizer for Dillo

by a1ex＠dismail.de

Hi, I have created a directory and search redirector for unofficial SearXNG instances. These are instances which do not appear on 'searx.space' or 'farside.link'. They usually seem to work better than the official ones, due to the fact that they aren't as highly publicized and have less load. The directory is here: https://alex.envs.net/searxng.html This link will automatically send you to a random instance: https://alex.envs.net/searx-rand.sh Finally, you can search directly from Dillo using a random instance by putting the following line into your dillorc: search_url="us UnScripted https://alex.envs.net/search.sh?%s" If anyone has links to additional SearXNG instances which I have not covered, and are not present on the official list, please let me know! Keep in mind that the instance must work without JavaScript! Regards, Alex

April 25, 2026

[PATCH] Add user-controllable Sec-GPC header

by a1ex＠dismail.de

Hi, The attached patch adds a Sec-GPC header to Dillo. It defaults to ON, and is controllable through a dillorc setting of 'http_sec_gpc'. Also, I changed DNT to be user-controllable with a dillorc setting of 'http_dnt', also defaults to ON. I know that this is too late to get in for the 3.3.0 release, but I'm sending it for review now, and if there are any issues it should allow plenty of time to fix. Regards, Alex

April 15, 2026

Re: [PATCH] Remove deprecated DNT header

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > I think sending the Sec-GPC header by default may be good idea. I > suggest adding these two options to control the headers (NO = no > header is sent): > > http_dnt=YES > http_sec_gpc=YES > > However, I don't want to introduce any new features or changes in the > HTTP headers for this release as we are already closing the 3.3.0. Sounds reasonable, I agree that allowing the user to control these settings is the right way to go. There was a timely article just yesterday which claims that big-tech is outright ignoring GPC signals: https://www.404media.co/google-microsoft-meta-all-tracking-you-even-when-yo… Even though some fines have already been issued based on GPC, they seem too small to be a real deterrent, and it just amounts to the 'cost of doing business' for these large corporations. It appears that often they don't even bother to pay the fines, and just tie up the courts for years: https://www.irishtimes.com/business/2026/01/12/data-protection-commission-o… So, this will remain an uphill battle, and just sending anti-tracking signals will never be a replacement for aggressive privacy-preserving tactics. Thankfully Dillo has one of the best privacy-preserving features available: no javascript! Rembember people, this is a feature, not a bug! Regards, Alex

April 15, 2026

Re: [PATCH] Remove deprecated DNT header

by Rodrigo Arias

Hi, On Tue, Apr 14, 2026 at 09:59:56PM +0200, Rodrigo Arias wrote: >I reached out to the EFF to ask if they still recommend the DNT header, >and see if they can provide more data or details as to why. The EFF seem to still encourage it, at least for the Privacy Badger extension: >From Privacy Badger's perspective, the benefits appear to continue to >outweigh the costs. Here is the relevant issue: > > https://github.com/EFForg/privacybadger/issues/2950 Best, Rodrigo.

April 14, 2026

Re: [PATCH] Remove deprecated DNT header

by Rodrigo Arias

Hi, On Tue, Apr 14, 2026 at 08:11:14AM +0000, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> >The 'Do Not Track' header has been abandoned by W3C and most major >> >browsers. Very few advertising companies actually supported DNT. >> >> Yes, that was the case already when it was merged in 2013, but there was >> the idea that it won't cause harm: >> >> commit b2be12828a20c54b325a4f31ca62959ea12f642b >> Author: corvid <corvid(a)dillo.org> >> Date: Sun Sep 15 18:48:13 2013 +0000 >> >> DNT will at least do no harm >> >> The whole situation is a manifestation of corporate rule, but >> - it seems that the EU has some data protection laws that could make it >> worth something in principle there. >> - some large corporations have been shamed into claiming that they will do >> a tiny bit of something based on the header value. > >At this point I don't think it's reasonable to expect that any >corporation will honor it "out of the goodness of their hearts". > >The industry has moved on to Sec-GPC, which appears to at least have >some legal backing to it. Maybe it makes more sense to simply change >the DNT header to Sec-GPC? > >https://en.wikipedia.org/wiki/Global_Privacy_Control I think sending the Sec-GPC header by default may be good idea. I suggest adding these two options to control the headers (NO = no header is sent): http_dnt=YES http_sec_gpc=YES However, I don't want to introduce any new features or changes in the HTTP headers for this release as we are already closing the 3.3.0. I reached out to the EFF to ask if they still recommend the DNT header, and see if they can provide more data or details as to why. If there is enough evidence that we should not send DNT, then I don't have any opposition to remove it by default. But I would like to keep it as an option for those users that still want to enable it. Best, Rodrigo.

April 14, 2026

Re: [PATCH] Remove deprecated DNT header

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > >The 'Do Not Track' header has been abandoned by W3C and most major > >browsers. Very few advertising companies actually supported DNT. > > Yes, that was the case already when it was merged in 2013, but there was > the idea that it won't cause harm: > > commit b2be12828a20c54b325a4f31ca62959ea12f642b > Author: corvid <corvid(a)dillo.org> > Date: Sun Sep 15 18:48:13 2013 +0000 > > DNT will at least do no harm > > The whole situation is a manifestation of corporate rule, but > - it seems that the EU has some data protection laws that could make it > worth something in principle there. > - some large corporations have been shamed into claiming that they will do > a tiny bit of something based on the header value. At this point I don't think it's reasonable to expect that any corporation will honor it "out of the goodness of their hearts". The industry has moved on to Sec-GPC, which appears to at least have some legal backing to it. Maybe it makes more sense to simply change the DNT header to Sec-GPC? https://en.wikipedia.org/wiki/Global_Privacy_Control Regards, Alex

April 14, 2026

Re: [PATCH] Remove deprecated DNT header

by Rodrigo Arias

Hi Alex, On Mon, Apr 13, 2026 at 09:09:29AM +0000, a1ex(a)dismail.de wrote: >Hi, > >The 'Do Not Track' header has been abandoned by W3C and most major >browsers. Very few advertising companies actually supported DNT. Yes, that was the case already when it was merged in 2013, but there was the idea that it won't cause harm: commit b2be12828a20c54b325a4f31ca62959ea12f642b Author: corvid <corvid(a)dillo.org> Date: Sun Sep 15 18:48:13 2013 +0000 DNT will at least do no harm The whole situation is a manifestation of corporate rule, but - it seems that the EU has some data protection laws that could make it worth something in principle there. - some large corporations have been shamed into claiming that they will do a tiny bit of something based on the header value. >https://en.wikipedia.org/wiki/Do_Not_Track > >Sending this header may actually make Dillo MORE trackable. What situation do you have in mind?, is it something that can be measured experimentally? Best, Rodrigo.

April 13, 2026

[PATCH] Remove deprecated DNT header

by a1ex＠dismail.de

Hi, The 'Do Not Track' header has been abandoned by W3C and most major browsers. Very few advertising companies actually supported DNT. https://en.wikipedia.org/wiki/Do_Not_Track Sending this header may actually make Dillo MORE trackable. The attached patch removes it. Regards, Alex

April 13, 2026

Re: [Feat. req.?]: Diacritic-sensitive search (Ctrl+Find)

by Juan M Sevilla

Hi, 7 Apr 2026 20:30:01 +0200 Rodrigo Arias: > I don't think the matching algorithm would be trivial. For example, > should "una" match both "una" and "uña" in Spanish? What about other > languages? That's fair. I would say that's the reason why it would have to be an optional filter, so users could disable it on those cases. > The current search algorithm matches bytes as-is. Trying to do > something clever would require us to iterate by glyphs instead, which > would be harder to implement and require more computational cost. > > I would wait until we have strong evidence that this feature is > needed and the cost of the implementation is worth it. I agree. Thank you for considering it! For now, it's not so difficult to type the variations of words one want to find. Even for misspelled words: I can omit the accentuated character; on some cases, I may look for another related word, etc. > Thanks for testing! Be sure to use the latest commit of FLTK from > their master branch in GitHub, as they contain recent fixes (few > weeks ago) for font rendering. I'll certainly check it out! I was using the Debian stable version: FLTK 1.4.3 Kind regards!

April 13, 2026

Released 3.3.0-rc1

by Rodrigo Arias

Hi, The release candidate 3.3.0-rc1 is available here: https://dillo-browser.org/release/3.3.0-rc1/ Let me know if you encounter any issues so I can fix them before the 3.3.0 release. Best, Rodrigo.

April 12, 2026

Re: [Feat. req.?]: Diacritic-sensitive search (Ctrl+Find)

by Rodrigo Arias

Hi Juan, On Sun, Apr 05, 2026 at 11:53:03AM -0300, Juan M Sevilla wrote: >Hi, > >It would be great if, as there is a case-sensitive search, there >were a diacritic-sensitive option. In fact, I would expect by default >that if I search for "esta", Dillo would also find "ésta". Another >example would be searching for "accion" that matches both singular >"acción" (with accent) and plural "acciones" (without accent). That's >Spanish specific, but we may want that for any language, i.e. several >diactritical marks: ` ^ ´ ¸ ¨ I don't think the matching algorithm would be trivial. For example, should "una" match both "una" and "uña" in Spanish? What about other languages? Firefox for example matches both but I wouldn't see it as the correct behavior (they are two unrelated words in Spanish). >I don't know how hard it would be to implement, just wanted to mention >it as a useful feature. The current search algorithm matches bytes as-is. Trying to do something clever would require us to iterate by glyphs instead, which would be harder to implement and require more computational cost. I would wait until we have strong evidence that this feature is needed and the cost of the implementation is worth it. >As a good news, I wanted to say that, with the experimental fltk-1.4 >flavor, I can use my preferred font (Atkinson Hyperlegible Next) and all >absent glyphs are displayed accordingly —a bit off the line I should >say, but I knew graphical glitches are to be expected. Thanks for testing! Be sure to use the latest commit of FLTK from their master branch in GitHub, as they contain recent fixes (few weeks ago) for font rendering. Best, Rodrigo.

April 7, 2026

[Feat. req.?]: Diacritic-sensitive search (Ctrl+Find)

by Juan M Sevilla

Hi, It would be great if, as there is a case-sensitive search, there were a diacritic-sensitive option. In fact, I would expect by default that if I search for "esta", Dillo would also find "ésta". Another example would be searching for "accion" that matches both singular "acción" (with accent) and plural "acciones" (without accent). That's Spanish specific, but we may want that for any language, i.e. several diactritical marks: ` ^ ´ ¸ ¨ I don't know how hard it would be to implement, just wanted to mention it as a useful feature. As a good news, I wanted to say that, with the experimental fltk-1.4 flavor, I can use my preferred font (Atkinson Hyperlegible Next) and all absent glyphs are displayed accordingly —a bit off the line I should say, but I knew graphical glitches are to be expected. Best regards!

April 5, 2026

Re: [PATCH] Fix display of disabled options in configure.ac

by Rodrigo Arias

Hi, On Mon, Mar 23, 2026 at 10:57:40AM +0000, a1ex(a)dismail.de wrote: >Hi, > >There are a couple of missing variables in configure.ac which result >in missing info when disabling some options via configure: > >Features: > > Cookies enabled: no > XEmbed enabled : no > JPEG enabled : no > PNG enabled : no > GIF enabled : no > SVG enabled : no > WEBP enabled : > Brotli enabled : > IPv6 enabled : no > Control socket : no (experimental) > >We are missing variables for WEBP and Brotli. > >The attached patch fixes this. Thanks Alex, merged: https://git.dillo-browser.org/dillo/commit/?id=70bdaca96a05e207848a0f6b30c0… Best, Rodrigo.

March 23, 2026

[PATCH] Fix display of disabled options in configure.ac

by a1ex＠dismail.de

Hi, There are a couple of missing variables in configure.ac which result in missing info when disabling some options via configure: Features: Cookies enabled: no XEmbed enabled : no JPEG enabled : no PNG enabled : no GIF enabled : no SVG enabled : no WEBP enabled : Brotli enabled : IPv6 enabled : no Control socket : no (experimental) We are missing variables for WEBP and Brotli. The attached patch fixes this. Regards, Alex

March 23, 2026

Re: "Segmentation fault" after pressing a button on a website

by Juan M Sevilla

Hi, On Sun, 22 Mar 2026 21:53:11 +0100, Rodrigo Arias wrote:: > I did some more tests and didn't saw any problems, including the page > that you reported, so I merged the fix here: > https://git.dillo-browser.org/dillo/commit/?id=8401530407bfc4adc545e1b6a344… > > If you still find any problem please let me know :) Great, thank you! It works as expected. I've found no issues with my tests. Kind regards

March 23, 2026

Preparation for Dillo 3.3.0 release

by Rodrigo Arias

Hi, As most blockers for the release are now solved, I would like to start preparing the 3.3.0 release, which will be the first to include experimental support for FLTK 1.4. It must be manually enabled with the --enable-experimental-fltk configure flag and is only recommended for early testers or developers. Please, let me know if there is any patch that you have planned to get merged before the release. Best, Rodrigo.

March 22, 2026

Re: "Segmentation fault" after pressing a button on a website

by Rodrigo Arias

Hi, On Sat, Mar 21, 2026 at 11:31:44PM +0100, Rodrigo Arias wrote: >I pushed a patch that hopefully fixes it: > >https://git.dillo-browser.org/dillo/log/?h=fix-hidden-form > >Let me know if you encounter any other page that segfaults when >submitting a form, so far it seems to be working fine in my tests. I did some more tests and didn't saw any problems, including the page that you reported, so I merged the fix here: https://git.dillo-browser.org/dillo/commit/?id=8401530407bfc4adc545e1b6a344… If you still find any problem please let me know :) Best, Rodrigo.

March 22, 2026

Re: "Segmentation fault" after pressing a button on a website

by Rodrigo Arias

Hi, On Mon, Mar 09, 2026 at 04:19:27PM -0300, Juan M Sevilla wrote: >Hi, > >9 mar. 2026 11:50:34 a1ex(a)dismail.de: >>I believe the problem is related to this known issue: >> >>https://bug.dillo-browser.org/506/ >> >>It is possible to work around it for now by putting something like >>this in your ~/.dillo/style.css file: >> >>select { display: inline !important; } > >Oh, I see, thank you! I should've checked the bug tracker —it was >quite late last night. > >I'll try that workaround meanwhile, thanks! I pushed a patch that hopefully fixes it: https://git.dillo-browser.org/dillo/log/?h=fix-hidden-form Let me know if you encounter any other page that segfaults when submitting a form, so far it seems to be working fine in my tests. Best, Rodrigo.

March 21, 2026

Re: [Issue]: Web search prefix lenght

by Rodrigo Arias

Hi Juan, On Mon, Mar 09, 2026 at 12:07:49AM -0300, Juan M Sevilla wrote: >Hi, apologies for the delay and thanks for the clarification. The patch >works as expected! I tested with more than 20 search engines and >everything behaves correctly. Thank you very much! > >Luckily, I started learning more about using git last weekend, so >learning to change branch to compile was like a good exercise :) Thanks for the tests. Merged: https://git.dillo-browser.org/dillo/commit/?id=da1819ce6e2efb71f71c753cddf6… Best, Rodrigo.

March 16, 2026

Re: "Segmentation fault" after pressing a button on a website

by Juan M Sevilla

Hi, 9 mar. 2026 11:50:34 a1ex(a)dismail.de: > I believe the problem is related to this known issue: > > https://bug.dillo-browser.org/506/ > > It is possible to work around it for now by putting something like > this in your ~/.dillo/style.css file: > > select { display: inline !important; } Oh, I see, thank you! I should've checked the bug tracker —it was quite late last night. I'll try that workaround meanwhile, thanks! Kind regards

March 9, 2026

Re: "Segmentation fault" after pressing a button on a website

by a1ex＠dismail.de

Hi, Juan M Sevilla <jumase+dillo(a)disroot.org> wrote: > Hi, while testing search engines, I found that on this particular site > https://paulina.toolforge.org/, when you press the button to submit > your search, Dillo crashes with the following message on the terminal: > "Violación de segmento". I believe the problem is related to this known issue: https://bug.dillo-browser.org/506/ It is possible to work around it for now by putting something like this in your ~/.dillo/style.css file: select { display: inline !important; } Regards, Alex

March 9, 2026

"Segmentation fault" after pressing a button on a website

by Juan M Sevilla

Hi, while testing search engines, I found that on this particular site https://paulina.toolforge.org/, when you press the button to submit your search, Dillo crashes with the following message on the terminal: "Violación de segmento". Here are the logs I get: > Nav_open_url: new url='https://paulina.toolforge.org/' > Dns_server [0]: paulina.toolforge.org is 2a02:ec80:a000:1::2bc > 185.15.56.88 Connecting to [2a02:ec80:a000:1::2bc]:443 > paulina.toolforge.org: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 > 0: ecdsa-with-SHA384 256-bit EC: /CN=toolforge.org > 1: sha256 384-bit EC: /C=US/O=Let's Encrypt/CN=E8 > root: /C=US/O=Internet Security Research Group/CN=ISRG Root X1 > NumPendingStyleSheets=1 > NumPendingStyleSheets=2 > NumPendingStyleSheets=3 > Dns_server [0]: tools-static.wmflabs.org is 2a02:ec80:a000:1::1d > 185.15.56.49 tools-static.wmflabs.org: TLSv1.3, cipher > TLS_AES_256_GCM_SHA384 0: ecdsa-with-SHA384 256-bit EC: > /CN=wmcloud.org 1: sha256 384-bit EC: /C=US/O=Let's Encrypt/CN=E8 > root: /C=US/O=Internet Security Research Group/CN=ISRG Root X1 > >>>> a_Nav_repush <<<< > Nav_open_url: new url='https://paulina.toolforge.org/' > a_Nav_expect_done: repush! > Violación de segmento It happens on both Dillo branches "master" and "match-prefix-exactly" $ dillo -v Dillo Libraries: fltk/1.3.11 jpeg/2.1.5 png/1.6.48 webp/1.5.0 zlib/1.3.1 OpenSSL/3.5.4 Features: +GIF +JPEG +PNG +SVG +WEBP -BROTLI +XEMBED +TLS +IPV6 -CTL

March 9, 2026

Re: [Issue]: Web search prefix lenght

by Juan M Sevilla

On Mon, 2 Mar 2026 20:25:54 +0100 Rodrigo Arias wrote: > There is no character limit but Dillo matches the first search entry > that starts with the prefix. So "wi" will match both "wi" and "wien". > The first match is used. > > One option is to use prefixes that are not substrings of other > prefixes (like wes and wen). > > I think it makes sense to change the behavior to match only the > complete prefix, as the user can write the shortened version > manually. So that "wi" won't match "wien", but only "wi". > > I uploaded the patch here: > > https://git.dillo-browser.org/dillo/log/?h=match-prefix-exactly > > Let me know if that works for your. Hi, apologies for the delay and thanks for the clarification. The patch works as expected! I tested with more than 20 search engines and everything behaves correctly. Thank you very much! Luckily, I started learning more about using git last weekend, so learning to change branch to compile was like a good exercise :) Best regards

March 9, 2026

Always show tab-bar

by a1ex＠dismail.de

Hi, I have added a section to my Dillo patches blog post about modding the tab-bar: https://alex.envs.net/blog/dillo/ Basically, I think it would be nice to have an option to always show the tab-bar. Is there any interest in such a feature? Regards, Alex

March 5, 2026

Re: [Issue]: Web search prefix lenght

by Rodrigo Arias

Hi, On Sun, Mar 01, 2026 at 06:47:12PM -0300, Juan M Sevilla wrote: >Hi, I'm using prefixes to search using different websites, but noticed >that this prefix cannot be 1 nor more than 2 characters long. > >For example, I configured Wikipedia in English and Spanish, the former >with prefix "wien" and the latter just "wi". In my dillorc, the English >version is first, so Dillo always uses this one to search, whether I >type "wi hola" or "wien hola". > >I've also set a dictionary with prefix "d", but Dillo always searches >on DuckDuckGo, which has the prefix "dd". > >I wonder if prefixes could be longer or shorter. On Firefox, I'm using >from 1 to 4 characters, the longer ones mainly to differentiate the >English from the Spanish version (Wikipedia; Wiktionary; WordReference >Translate, Dictionaries, Synonim). There is no character limit but Dillo matches the first search entry that starts with the prefix. So "wi" will match both "wi" and "wien". The first match is used. One option is to use prefixes that are not substrings of other prefixes (like wes and wen). I think it makes sense to change the behavior to match only the complete prefix, as the user can write the shortened version manually. So that "wi" won't match "wien", but only "wi". I uploaded the patch here: https://git.dillo-browser.org/dillo/log/?h=match-prefix-exactly Let me know if that works for your. >Otherwise, I can live with the 2-character length, but it would be >great if it was stated on the dillorc file, something like: > >> (the prefix serves to search from the Location Bar. e.g. "dd dillo >> image" and it must be 2 characters long) > >Thank you! I've been using Dillo for six months and I like it very >much :D Glad to read that :) Best, Rodrigo.

March 2, 2026

[Issue]: Web search prefix lenght

by Juan M Sevilla

Hi, I'm using prefixes to search using different websites, but noticed that this prefix cannot be 1 nor more than 2 characters long. For example, I configured Wikipedia in English and Spanish, the former with prefix "wien" and the latter just "wi". In my dillorc, the English version is first, so Dillo always uses this one to search, whether I type "wi hola" or "wien hola". I've also set a dictionary with prefix "d", but Dillo always searches on DuckDuckGo, which has the prefix "dd". I wonder if prefixes could be longer or shorter. On Firefox, I'm using from 1 to 4 characters, the longer ones mainly to differentiate the English from the Spanish version (Wikipedia; Wiktionary; WordReference Translate, Dictionaries, Synonim). Otherwise, I can live with the 2-character length, but it would be great if it was stated on the dillorc file, something like: > (the prefix serves to search from the Location Bar. e.g. "dd dillo > image" and it must be 2 characters long) Thank you! I've been using Dillo for six months and I like it very much :D

March 1, 2026

FLTK 1.4 experimental support

by Rodrigo Arias

Hi, I pushed the fltk-1.4 branch to support building dillo with FLTK >= 1.4. It needs the configure flag --enable-experimental-fltk: https://git.dillo-browser.org/dillo/log/?h=fltk-1.4 The objective is to allow early adopters to build dillo so we can unblock the next 3.3.0 release. There are known problems with scrolling and with font hinting and antialiasing which I will be focusing later. For know I'm interested in testing that dillo can build correctly with FLTK 1.4 on different platforms. To build, use this with the path to fltk-config binary of FLTK 1.4: % ../configure --enable-experimental-fltk FLTK_CONFIG=/.../fltk-config Or manually specify the flags with FLTK_CFLAGS, FLTK_CXXFLAGS and FLTK_LIBS variables. Dillo should report the FLTK version: % dillo -v Dillo v3.2.0-162-g6142b99f Libraries: fltk/1.4.4 jpeg/3.1.2 png/1.6.53 webp/1.6.0 zlib/1.3.1 brotli/1.1.0 OpenSSL/3.6.0 Features: +GIF +JPEG +PNG +SVG +WEBP +BROTLI +XEMBED +TLS +IPV6 +CTL Let me know if you encounter any problems during the build. Patches that solve rendering problems are very much welcome. Best, Rodrigo.

Feb. 22, 2026

Re: [PATCH] Use FL_FOREGROUND_COLOR for widget selection color

by Rodrigo Arias

Hi, On Fri, Feb 20, 2026 at 01:14:33PM +0000, a1ex(a)dismail.de wrote: >Hi, > >Currently Dillo uses a fixed color (black) for the widget selection >color, which includes checkmarks and radio buttons. When using a dark >color scheme, these selections can be invisible or hard to see. Instead, >use the foreground color from dillorc to ensure visibility. > >Patch is attached. Thanks!, merged. >Also, I put up a little blog post with some other Dillo patches, >hopefully someone here will find it interesting! I welcome any feedback. >https://alex.envs.net/blog/dillo Cool! Best, Rodrigo.

Feb. 20, 2026

[PATCH] Use FL_FOREGROUND_COLOR for widget selection color

by a1ex＠dismail.de

Hi, Currently Dillo uses a fixed color (black) for the widget selection color, which includes checkmarks and radio buttons. When using a dark color scheme, these selections can be invisible or hard to see. Instead, use the foreground color from dillorc to ensure visibility. Patch is attached. Also, I put up a little blog post with some other Dillo patches, hopefully someone here will find it interesting! I welcome any feedback. https://alex.envs.net/blog/dillo Regards, Alex

Feb. 20, 2026

Re: Patches for two use-after-free bugs

by Rodrigo Arias

Hi, >I will test it a bit with ASan enabled and merge it if nothing breaks. Merged in 9562d30a: https://git.dillo-browser.org/dillo/log/ Best, Rodrigo.

Feb. 1, 2026

Re: Patches for two use-after-free bugs

by Rodrigo Arias

Hi Magnus, On Sun, Jan 25, 2026 at 11:53:08AM -0700, Nopey Nope wrote: >Thanks for the guidance, Rodrigo! > >Had a better idea on how to fix the socketdata use-after-free; new >attached patch 0002 fixes the bug by only freeing the queued sockdata >if it's exclusively owned by the server queue. > >I've added information in the commit summaries as suggested. > >I also added an assert in Http_socket_enqueue, which makes explicit >the precondition that socketdata can only be queued to one server at a >time. >This assert has not tripped, and hopefully never will; I thought it >helped illustrate the relation between servers and socketdatas. Thanks a lot!, they both look good. I'll leave the assert in Http_socket_enqueue but remove the message string as it causes a warning in gcc and I don't think is needed for this case. https://git.dillo-browser.org/dillo/log/?h=fix-uaf I will test it a bit with ASan enabled and merge it if nothing breaks. Best, Rodrigo.

Jan. 31, 2026

Re: Patches for two use-after-free bugs

by Nopey Nope

Thanks for the guidance, Rodrigo! Had a better idea on how to fix the socketdata use-after-free; new attached patch 0002 fixes the bug by only freeing the queued sockdata if it's exclusively owned by the server queue. I've added information in the commit summaries as suggested. I also added an assert in Http_socket_enqueue, which makes explicit the precondition that socketdata can only be queued to one server at a time. This assert has not tripped, and hopefully never will; I thought it helped illustrate the relation between servers and socketdatas. Magnus On Sat, Jan 24, 2026 at 2:10 PM Rodrigo Arias <rodarima(a)gmail.com> wrote: > > Hi Magnus, > > On Sat, Jan 24, 2026 at 11:13:25AM -0800, Nopey Nope wrote: > >Hello! > > > >Find attached two patches, which each fix a use-after-free bug. > > > >I've also attached a crashing html document for each, but please be > >aware that these reproducer documents link urls from external web > >servers. > >The reproducers crash reliably on my x86_64 Void Linux laptop, but > >I've not tested them elsewhere. I've also attached a crash log with > >asan reporting of each. > > > >Thank you > >-Magnus L > > > >p.s. I've also opened github PR 449 with these same changes, but > >figured I should send the patches via email as well-- if only for > >practice :) > > Thanks a lot for the patches and reproducers! > > I saw the PR but I only had time to look at the "Fix use-after-free in > openssl cert popup" commit which seems good. We are moving away from > GitHub so it would be nice to send future patches here (or a link to a > git repo/branch to fetch with git). > > It would help to describe what is the condition that triggers the UAF in > the Http_server patch and why the change helps, so that it is easier to > review. > > Perhaps it would be a good idea to put that information it in the commit > summary of both patches so we can see it via git blame. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Jan. 25, 2026

Re: Patches for two use-after-free bugs

by Rodrigo Arias

Hi Magnus, On Sat, Jan 24, 2026 at 11:13:25AM -0800, Nopey Nope wrote: >Hello! > >Find attached two patches, which each fix a use-after-free bug. > >I've also attached a crashing html document for each, but please be >aware that these reproducer documents link urls from external web >servers. >The reproducers crash reliably on my x86_64 Void Linux laptop, but >I've not tested them elsewhere. I've also attached a crash log with >asan reporting of each. > >Thank you >-Magnus L > >p.s. I've also opened github PR 449 with these same changes, but >figured I should send the patches via email as well-- if only for >practice :) Thanks a lot for the patches and reproducers! I saw the PR but I only had time to look at the "Fix use-after-free in openssl cert popup" commit which seems good. We are moving away from GitHub so it would be nice to send future patches here (or a link to a git repo/branch to fetch with git). It would help to describe what is the condition that triggers the UAF in the Http_server patch and why the change helps, so that it is easier to review. Perhaps it would be a good idea to put that information it in the commit summary of both patches so we can see it via git blame. Best, Rodrigo.

Jan. 24, 2026

Patches for two use-after-free bugs

by Nopey Nope

Hello! Find attached two patches, which each fix a use-after-free bug. I've also attached a crashing html document for each, but please be aware that these reproducer documents link urls from external web servers. The reproducers crash reliably on my x86_64 Void Linux laptop, but I've not tested them elsewhere. I've also attached a crash log with asan reporting of each. Thank you -Magnus L p.s. I've also opened github PR 449 with these same changes, but figured I should send the patches via email as well-- if only for practice :)

Jan. 24, 2026

Re: Segfault while running SSL Labs CurveBall test

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > This patch should get rid of the segfault, but I need to take a closer > look and see if we are handling it well for LibreSSL, as they expose > headers from version 2 from OpenSSL. > > ---8<--- > diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c > index 3345a0dc..d1df2315 100644 > --- a/src/IO/tls_openssl.c > +++ b/src/IO/tls_openssl.c > @@ -471,14 +471,12 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) > char buf[buflen]; > int rc, i, n = sk_X509_num(sk); > X509 *cert = NULL; > - EVP_PKEY *public_key; > int key_type, key_bits; > const char *type_str; > BIO *b; > > for (i = 0; i < n; i++) { > cert = sk_X509_value(sk, i); > - public_key = X509_get_pubkey(cert); > > /* We are trying to find a way to get the hash function used > * with a certificate. This way, which is not very pleasant, puts > @@ -521,6 +519,10 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) > if (print_chain) > MSG("%s ", buf); > > + EVP_PKEY *public_key = X509_get_pubkey(cert); > + if (public_key == NULL) > + continue; > + > #if OPENSSL_VERSION_NUMBER < 0x30000000L > key_type = EVP_PKEY_type(EVP_PKEY_id(public_key)); > #else > ---8<--- Thanks! Now the segfault is gone: Nav_open_url: new url='https://www.ssllabs.com:10446/' Dns_server [0]: www.ssllabs.com is 69.67.183.100 Connecting to 69.67.183.100:10446 www.ssllabs.com:10446: TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384 ecdsa-with-SHA256 384-bit EC: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs CurveBall Leaf/CN=www.ssllabs.com ecdsa-with-SHA256 root: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs/CN=SSLLabs CurveBall CA SSL_read() failed: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib SSL_read() failed: error:10FFF07F:elliptic curve routines:CRYPTO_internal:pkparameters2group failure SSL_read() failed: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib SSL_read() failed: error:10FFF08E:elliptic curve routines:CRYPTO_internal:decode error SSL_read() failed: error:0BFFF07D:x509 certificate routines:CRYPTO_internal:public key decode error Tls_close_by_key: Avoiding SSL shutdown for: https://www.ssllabs.com:10446/ Premature close for https://www.ssllabs.com:10446/ Regards, Alex

Jan. 16, 2026

Re: Avoid ctype(3) abuses

by Leonardo Taccari

Rodrigo Arias writes: > Hi, > > >Updated patches modified as required attached in this email. > > > >Now ctype(3) usage is only via d*() helper ctype(3) functions. > > Thanks!, it looks good. I will test it a bit and merge it if nothing > breaks. I will also add src/commit.h to .gitignore so we prevent this: > > >diff --git a/src/commit.h b/src/commit.h > >new file mode 100644 > >index 00000000..7c4f940d > >--- /dev/null > >+++ b/src/commit.h > >@@ -0,0 +1 @@ > >+#define GIT_COMMIT "v3.2.0-143-gabad1053-dirty" > [...] Whoops, sorry for that extra hunk! I was focused on double-checking the ctype(3) -> d*() helper transformations that I have completely missed that. :\ Thank you very much Rodrigo!

Jan. 16, 2026

Re: Avoid ctype(3) abuses

by Rodrigo Arias

>Thanks!, it looks good. I will test it a bit and merge it if nothing >breaks. I will also add src/commit.h to .gitignore so we prevent this: Merged.

Jan. 15, 2026

Re: Avoid ctype(3) abuses

by Rodrigo Arias

Hi, >Updated patches modified as required attached in this email. > >Now ctype(3) usage is only via d*() helper ctype(3) functions. Thanks!, it looks good. I will test it a bit and merge it if nothing breaks. I will also add src/commit.h to .gitignore so we prevent this: >diff --git a/src/commit.h b/src/commit.h >new file mode 100644 >index 00000000..7c4f940d >--- /dev/null >+++ b/src/commit.h >@@ -0,0 +1 @@ >+#define GIT_COMMIT "v3.2.0-143-gabad1053-dirty" Best, Rodrigo.

Jan. 15, 2026

Segfault while running SSL Labs CurveBall test

by a1ex＠dismail.de

Hi, I was running some tests from ssllabs.com and ran into a segfault. I used the "CurveBall" manual test link from this page: https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html Which points to: https://www.ssllabs.com:10446/ Nav_open_url: new url='https://www.ssllabs.com:10446/' Connecting to 69.67.183.100:10446 www.ssllabs.com:10446: TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384 ecdsa-with-SHA256 384-bit EC: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs CurveBall Leaf/CN=www.ssllabs.com ecdsa-with-SHA256 Program received signal SIGSEGV, Segmentation fault. _lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 793 return pkey->type; (gdb) bt #0 _lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 #1 0x000001f9ee7da2b0 in Tls_check_cert_strength (ssl=<optimized out>, srv=<optimized out>, choice=0x6faff21f66f8) at tls_openssl.c:526 #2 0x000001f9ee7d8fd3 in Tls_examine_certificate (ssl=0x1fca8ddac80, srv=0x1fc1b4056a0) at tls_openssl.c:865 #3 Tls_connect (fd=7, connkey=4) at tls_openssl.c:1208 #4 0x000001fce9a7a7f0 in fl_wait(double) () from /usr/local/lib/libfltk.so.9.0 #5 0x000001fce9a0777f in Fl::wait(double) () from /usr/local/lib/libfltk.so.9.0 #6 0x000001fce9a079a1 in Fl::wait() () from /usr/local/lib/libfltk.so.9.0 #7 0x000001f9ee77e774 in main (argc=1, argv=0x6faff21f6a48) at dillo.cc:621 When I try to open it with curl, this is the result: curl: (35) TLS connect error: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib This is on OpenBSD, using LibreSSL. I did a curl test on a Linux box and didn't get that error, so it may be LibreSSL specific. Happy to do further testing if you have any ideas. Regards, Alex

Jan. 15, 2026

Re: Segfault while running SSL Labs CurveBall test

by Rodrigo Arias

Hi, On Thu, Jan 15, 2026 at 09:44:50PM +0000, a1ex(a)dismail.de wrote: >Hi, > >I was running some tests from ssllabs.com and ran into a segfault. > >I used the "CurveBall" manual test link from this page: >https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html > >Which points to: https://www.ssllabs.com:10446/ > >Nav_open_url: new url='https://www.ssllabs.com:10446/' >Connecting to 69.67.183.100:10446 >www.ssllabs.com:10446: TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384 >ecdsa-with-SHA256 384-bit EC: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs CurveBall Leaf/CN=www.ssllabs.com >ecdsa-with-SHA256 >Program received signal SIGSEGV, Segmentation fault. >_lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 >793 return pkey->type; >(gdb) bt >#0 _lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 >#1 0x000001f9ee7da2b0 in Tls_check_cert_strength (ssl=<optimized out>, > srv=<optimized out>, choice=0x6faff21f66f8) at tls_openssl.c:526 >#2 0x000001f9ee7d8fd3 in Tls_examine_certificate (ssl=0x1fca8ddac80, srv=0x1fc1b4056a0) > at tls_openssl.c:865 >#3 Tls_connect (fd=7, connkey=4) at tls_openssl.c:1208 >#4 0x000001fce9a7a7f0 in fl_wait(double) () from /usr/local/lib/libfltk.so.9.0 >#5 0x000001fce9a0777f in Fl::wait(double) () from /usr/local/lib/libfltk.so.9.0 >#6 0x000001fce9a079a1 in Fl::wait() () from /usr/local/lib/libfltk.so.9.0 >#7 0x000001f9ee77e774 in main (argc=1, argv=0x6faff21f6a48) at dillo.cc:621 > >When I try to open it with curl, this is the result: >curl: (35) TLS connect error: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib > >This is on OpenBSD, using LibreSSL. > >I did a curl test on a Linux box and didn't get that error, so it may >be LibreSSL specific. Thanks, I can reproduce it on Linux with LibreSSL 4.2.1 and ASan enabled: ==1123582==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f31c4d0b3a4 bp 0x7ffc3dc12070 sp 0x7ffc3dc10eb8 T0) ==1123582==The signal is caused by a READ memory access. ==1123582==Hint: address points to the zero page. #0 0x7f31c4d0b3a4 in EVP_PKEY_id (/usr/lib/libressl/libcrypto.so.57+0xae3a4) (BuildId: 15f17022dc7dbd5298bf906f2ef4e53d12c52015) #1 0x55c7110c71cf in Tls_check_cert_strength ../../../src/IO/tls_openssl.c:525 #2 0x55c7110c87d1 in Tls_examine_certificate ../../../src/IO/tls_openssl.c:864 #3 0x55c7110ca507 in Tls_connect ../../../src/IO/tls_openssl.c:1207 #4 0x55c7110ca6e0 in Tls_connect_cb ../../../src/IO/tls_openssl.c:1239 #5 0x7f31c4ab06ec in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa66ec) (BuildId: 35d154011fe6e73efbad51f873a8c4e488e91451) #6 0x7f31c4a4e0fd in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x440fd) (BuildId: 35d154011fe6e73efbad51f873a8c4e488e91451) #7 0x7f31c4a4e232 in Fl::wait() (/usr/lib/libfltk.so.1.3+0x44232) (BuildId: 35d154011fe6e73efbad51f873a8c4e488e91451) #8 0x55c710fd9009 in main ../../src/dillo.cc:621 #9 0x7f31c4227634 (/usr/lib/libc.so.6+0x27634) (BuildId: 2f722da304c0a508c891285e6840199c35019c8d) #10 0x7f31c42276e8 in __libc_start_main (/usr/lib/libc.so.6+0x276e8) (BuildId: 2f722da304c0a508c891285e6840199c35019c8d) #11 0x55c710fd5f74 in _start (/home/ram/dev/dillo/git/build-asan/src/dillo+0x12f74) (BuildId: 850e3f88a121a05841fca5389243b0482d69b6b0) This patch should get rid of the segfault, but I need to take a closer look and see if we are handling it well for LibreSSL, as they expose headers from version 2 from OpenSSL. ---8<--- diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c index 3345a0dc..d1df2315 100644 --- a/src/IO/tls_openssl.c +++ b/src/IO/tls_openssl.c @@ -471,14 +471,12 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) char buf[buflen]; int rc, i, n = sk_X509_num(sk); X509 *cert = NULL; - EVP_PKEY *public_key; int key_type, key_bits; const char *type_str; BIO *b; for (i = 0; i < n; i++) { cert = sk_X509_value(sk, i); - public_key = X509_get_pubkey(cert); /* We are trying to find a way to get the hash function used * with a certificate. This way, which is not very pleasant, puts @@ -521,6 +519,10 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) if (print_chain) MSG("%s ", buf); + EVP_PKEY *public_key = X509_get_pubkey(cert); + if (public_key == NULL) + continue; + #if OPENSSL_VERSION_NUMBER < 0x30000000L key_type = EVP_PKEY_type(EVP_PKEY_id(public_key)); #else ---8<--- Best, Rodrigo.

Jan. 15, 2026

Re: Avoid ctype(3) abuses

by Leonardo Taccari

Leonardo Taccari writes: > [...] > Good idea! > > I will then add possible missing d*() helper ctype(3) functions and > adapt all direct ctype(3) users to switch to such d*() helper > functions. > > I hope to be able to share possible patches for that in 48 hours or so! > [...] Updated patches modified as required attached in this email. Now ctype(3) usage is only via d*() helper ctype(3) functions. Thanks!

Jan. 15, 2026

Re: Segfault on form submit / CSS display:none

by Rodrigo Arias

Hi, On Wed, Jan 14, 2026 at 11:40:34AM +0100, Thomas Rudolph wrote: > Hi, > > the following html code causes Dillo to segfault in the latest git > versions when clicking the button. I stripped the html down to the > problem: > > <form> > > <span style="display:none;"> > <input type="checkbox" name="x"> > </span> > > <input type=submit name="submit" value="Crash"> > > </form> > > This is reproducible on my Raspberry Pi OS (Debian 13) machine as well > as on my laptop (Debian 13). > > Removing either "display:none;", or the name attribute of the input, > or disabling embedded CSS results in Dillo not crashing. > Input type text crashes as well as checkbox. > Older versions of Dillo such as the 3.2.0 release do not crash on this > code, too. Thanks for the report. Yes, is a known problem: https://bug.dillo-browser.org/506/ The fix is in progress. As a workaround you can disable CSS for that page to submit the form or use 3.2.0. > Thanks for resurrecting this awesome browser. It has become my default > browser for 60-70 percent of the web. Glad to read that :) Best, Rodrigo.

Jan. 15, 2026

Segfault on form submit / CSS display:none

by Thomas Rudolph

Hi, the following html code causes Dillo to segfault in the latest git versions when clicking the button. I stripped the html down to the problem: <form> <span style="display:none;"> <input type="checkbox" name="x"> </span> <input type=submit name="submit" value="Crash"> </form> This is reproducible on my Raspberry Pi OS (Debian 13) machine as well as on my laptop (Debian 13). Removing either "display:none;", or the name attribute of the input, or disabling embedded CSS results in Dillo not crashing. Input type text crashes as well as checkbox. Older versions of Dillo such as the 3.2.0 release do not crash on this code, too. Thanks for resurrecting this awesome browser. It has become my default browser for 60-70 percent of the web. All the best, Thomas

Jan. 14, 2026

Re: Avoid ctype(3) abuses

by Leonardo Taccari

Hello Rodrigo, Rodrigo Arias writes: > Hi, > > On Mon, Jan 12, 2026 at 11:05:17AM +0100, Leonardo Taccari wrote: > >Hello! > > > >Most ctype(3) functions usage abuses an undefined behavior of passing > >values outside integers outside EOF or the range representable as > >unsigned char. > > > >On NetBSD 11 and newer such incorrect behaviors crashes applications > >violating that and due that Dillo easily crash by just visiting, e.g. > ><https://www.NetBSD.org/>. > > > >For possible further information please give a look to > ><https://man.NetBSD.org/ctype.3#CAVEATS>. > > Interesting! > > >I have grep-ed all such uses and added the relevant cast to uchar_t > >similar to other ctype(3) calls already present and in that way I can > >also confirm that Dillo no longer crashes. > > Thanks for the patch and tests. > > We have wrappers that do just that for isspace() and isalnum() in > dlib/dlib.h: > > https://git.dillo-browser.org/dillo/tree/dlib/dlib.h?id=7c6ccebe61077902160… > > I would be inclined to add the extra wrappers there and use the > dIsspace, dIsalnum... macros instead of doing the explicit casting. > > Additionally, I think it would be safer to also switch all these ctype > macros to static inline functions so we cover accidental castings from > unexpected types with an error instead of a warning: > > static inline int dIsalnum(unsigned char c) { return isalnum(c); } > > Example: > > % cat foo.c > #include <ctype.h> > static inline int dIsalnum(unsigned char c) { return isalnum(c); } > #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) > > int main(void) > { > char *a = "a"; > dIsalnum(a); > dIsalnum_unsafe(a); > > return 0; > } > > % gcc foo.c -o foo > foo.c: In function ‘main’: > foo.c:8:18: error: passing argument 1 of ‘dIsalnum’ makes integer from pointer without a cast [-Wint-conversion] > 8 | dIsalnum(a); > | ^ > | | > | char * > foo.c:2:42: note: expected ‘unsigned char’ but argument is of type ‘char *’ > 2 | static inline int dIsalnum(unsigned char c) { return isalnum(c); } > | ~~~~~~~~~~~~~~^ > In file included from foo.c:1: > foo.c:3:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > 3 | #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) > | ^ > foo.c:9:9: note: in expansion of macro ‘dIsalnum_unsafe’ > 9 | dIsalnum_unsafe(a); > | ^~~~~~~~~~~~~~~ > [...] Good idea! I will then add possible missing d*() helper ctype(3) functions and adapt all direct ctype(3) users to switch to such d*() helper functions. I hope to be able to share possible patches for that in 48 hours or so! Thank you!

Jan. 12, 2026

Re: Include missing <stdlib.h> for calloc(3) and exit(3)

by Leonardo Taccari

Hello Rodrigo, Rodrigo Arias writes: > Hi, > > On Mon, Jan 12, 2026 at 11:04:07AM +0100, Leonardo Taccari wrote: > >Hello! > > > >When trying to build current HEAD of dillo in NetBSD the build fails > >with: > > > > [...] > > g++ ... -o dialog.o dialog.cc > > [...] > > dialog.cc:38:1: note: 'calloc' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > > 37 | #include "dlib/dlib.h" > > +++ |+#include <cstdlib> > > 38 | > > dialog.cc:192:11: error: 'exit' was not declared in this scope > > 192 | exit(1); > > | ^~~~ > > dialog.cc:192:11: note: 'exit' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > > *** [dialog.o] Error code 1 > > [...] > > > >Including <stdlib.h> fixes that and the attached patch does that. > > Thanks!, merged in: > > https://git.dillo-browser.org/dillo/commit/?id=7c6ccebe61077902160798e5af46… > [...] Thank you very much for quickly applying it!

Jan. 12, 2026

Re: Avoid ctype(3) abuses

by Rodrigo Arias

Hi, On Mon, Jan 12, 2026 at 11:05:17AM +0100, Leonardo Taccari wrote: >Hello! > >Most ctype(3) functions usage abuses an undefined behavior of passing >values outside integers outside EOF or the range representable as >unsigned char. > >On NetBSD 11 and newer such incorrect behaviors crashes applications >violating that and due that Dillo easily crash by just visiting, e.g. ><https://www.NetBSD.org/>. > >For possible further information please give a look to ><https://man.NetBSD.org/ctype.3#CAVEATS>. Interesting! >I have grep-ed all such uses and added the relevant cast to uchar_t >similar to other ctype(3) calls already present and in that way I can >also confirm that Dillo no longer crashes. Thanks for the patch and tests. We have wrappers that do just that for isspace() and isalnum() in dlib/dlib.h: https://git.dillo-browser.org/dillo/tree/dlib/dlib.h?id=7c6ccebe61077902160… I would be inclined to add the extra wrappers there and use the dIsspace, dIsalnum... macros instead of doing the explicit casting. Additionally, I think it would be safer to also switch all these ctype macros to static inline functions so we cover accidental castings from unexpected types with an error instead of a warning: static inline int dIsalnum(unsigned char c) { return isalnum(c); } Example: % cat foo.c #include <ctype.h> static inline int dIsalnum(unsigned char c) { return isalnum(c); } #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) int main(void) { char *a = "a"; dIsalnum(a); dIsalnum_unsafe(a); return 0; } % gcc foo.c -o foo foo.c: In function ‘main’: foo.c:8:18: error: passing argument 1 of ‘dIsalnum’ makes integer from pointer without a cast [-Wint-conversion] 8 | dIsalnum(a); | ^ | | | char * foo.c:2:42: note: expected ‘unsigned char’ but argument is of type ‘char *’ 2 | static inline int dIsalnum(unsigned char c) { return isalnum(c); } | ~~~~~~~~~~~~~~^ In file included from foo.c:1: foo.c:3:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 3 | #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) | ^ foo.c:9:9: note: in expansion of macro ‘dIsalnum_unsafe’ 9 | dIsalnum_unsafe(a); | ^~~~~~~~~~~~~~~ Best, Rodrigo.

Jan. 12, 2026

Re: Include missing <stdlib.h> for calloc(3) and exit(3)

by Rodrigo Arias

Hi, On Mon, Jan 12, 2026 at 11:04:07AM +0100, Leonardo Taccari wrote: >Hello! > >When trying to build current HEAD of dillo in NetBSD the build fails >with: > > [...] > g++ ... -o dialog.o dialog.cc > [...] > dialog.cc:38:1: note: 'calloc' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > 37 | #include "dlib/dlib.h" > +++ |+#include <cstdlib> > 38 | > dialog.cc:192:11: error: 'exit' was not declared in this scope > 192 | exit(1); > | ^~~~ > dialog.cc:192:11: note: 'exit' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > *** [dialog.o] Error code 1 > [...] > >Including <stdlib.h> fixes that and the attached patch does that. Thanks!, merged in: https://git.dillo-browser.org/dillo/commit/?id=7c6ccebe61077902160798e5af46… Best, Rodrigo

Jan. 12, 2026

Avoid ctype(3) abuses

by Leonardo Taccari

Hello! Most ctype(3) functions usage abuses an undefined behavior of passing values outside integers outside EOF or the range representable as unsigned char. On NetBSD 11 and newer such incorrect behaviors crashes applications violating that and due that Dillo easily crash by just visiting, e.g. <https://www.NetBSD.org/>. For possible further information please give a look to <https://man.NetBSD.org/ctype.3#CAVEATS>. I have grep-ed all such uses and added the relevant cast to uchar_t similar to other ctype(3) calls already present and in that way I can also confirm that Dillo no longer crashes. Attached in this email you can find a patch to address that. Thank you!

Jan. 12, 2026