May 2026 - Dillo-dev - lists.mailman3.com

Re: dillo displays corrupted data using gopher protocol

by Ben Collver

Hi Rodrigo, On Wed, May 27, 2026 at 11:05:11PM +0200, Rodrigo Arias wrote: > I enabled Asan with -fsanitize=address in CFLAGS and LDFLAGS and I see what > is going on: > > There is a missing case in which we are reading a character pass the buffer > (when i == len). I pushed the fix to the git repo: > > https://git.dillo-browser.org/plugins/gopher/commit/?id=d8055639af10041cec9… > > Let me know if that fixes it for you. Thanks for the explanation and the fix. Your fix works for me. -Ben

May 28, 2026

Re: dillo displays corrupted data using gopher protocol

by Rodrigo Arias

Hi Ben, On Mon, May 25, 2026 at 04:25:24PM -0700, Ben Collver wrote: > >I tried setting a breakpoint at line 349, watching the variables, and >stepping through the code with gdb's `n` command, but in that context >the plugin no longer gives SIGSEGV. > >Any more suggestions? I enabled Asan with -fsanitize=address in CFLAGS and LDFLAGS and I see what is going on: > ================================================================= > ==136179==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7b0195ff3040 at pc 0x5627981706b2 bp 0x7ffe14825560 sp 0x7ffe14825550 > READ of size 1 at 0x7b0195ff3040 thread T0 > #0 0x5627981706b1 in read_line /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:332 > #1 0x5627981709c5 in read_response /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:355 > #2 0x562798170d95 in render_dir /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:384 > #3 0x56279817192c in respond /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:466 > #4 0x562798171b25 in main /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:490 > #5 0x7f0198027740 (/usr/lib/libc.so.6+0x27740) (BuildId: 020d6f7c33b2413f4fe10814c4729dce1387f049) > #6 0x7f0198027878 in __libc_start_main (/usr/lib/libc.so.6+0x27878) (BuildId: 020d6f7c33b2413f4fe10814c4729dce1387f049) > #7 0x56279816e384 in _start (/home/ram/.dillo/dpi/gopher/gopher.filter.dpi+0x3384) (BuildId: 2539342afa9ad468aea77caeadba0586e529a0f0) > > Address 0x7b0195ff3040 is located in stack of thread T0 at offset 4160 in frame > #0 0x562798170791 in read_response /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:340 > > This frame has 2 object(s): > [32, 40) 'len' (line 342) > [64, 4160) 'buf' (line 341) <== Memory access at offset 4160 overflows this variable > HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork > (longjmp and C++ exceptions *are* supported) > SUMMARY: AddressSanitizer: stack-buffer-overflow /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:332 in read_line > Shadow bytes around the buggy address: > 0x7b0195ff2d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7b0195ff2e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7b0195ff2e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7b0195ff2f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7b0195ff2f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > =>0x7b0195ff3000: 00 00 00 00 00 00 00 00[f3]f3 f3 f3 f3 f3 f3 f3 > 0x7b0195ff3080: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 > 0x7b0195ff3100: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 > 0x7b0195ff3180: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 > 0x7b0195ff3200: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 > 0x7b0195ff3280: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > ==136179==ABORTING There is a missing case in which we are reading a character pass the buffer (when i == len). I pushed the fix to the git repo: https://git.dillo-browser.org/plugins/gopher/commit/?id=d8055639af10041cec9… Let me know if that fixes it for you. Best, Rodrigo.

May 27, 2026

Re: dillo displays corrupted data using gopher protocol

by Ben Collver

Hi Rodrigo, On Tue, May 26, 2026 at 12:30:18AM +0200, Rodrigo Arias wrote: > I don't observe it here, which gopher plugin are you using and which commit? I am using commit a32f74522f990c46415977afcd06d0e8d162ea55 of the following gopher plugin: https://git.dillo-browser.org/plugins/gopher > You can likely invoke it manually with: > > $ dpidc stop > $ dpid & > $ key=$(cat ~/.dillo/dpid_comm_keys | cut -d " " -f2) > $ url="gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map" > $ echo "<cmd='auth' msg='$key' '><cmd='open_url' url='$url' '>\n" |\ > ~/.dillo/dpi/gopher/gopher.filter.dpi > > Perhaps using strace or gdb may help. Thanks! I built it with: CFLAGS = -std=c99 -D_POSIX_C_SOURCE=200112 -g I am including my gdb session below [1]. I tried setting a breakpoint at line 349, watching the variables, and stepping through the code with gdb's `n` command, but in that context the plugin no longer gives SIGSEGV. Any more suggestions? Thanks again, -Ben [1] gdb output: Program received signal SIGSEGV, Segmentation fault. 0x000000000040209c in read_line (buf=0x7fffffffdefb "\255\362Գ(\233G^\240Q0\335u.x86_64", len=18446744073709540501) at gopher.filter.dpi.c:331 331 for (i = 0; i < len && buf[i] != '\r' && buf[i] != '\n'; i++); (gdb) bt #0 0x000000000040209c in read_line ( buf=0x7fffffffdefb "\255\362Գ(\233G^\240Q0\335u.x86_64", len=18446744073709540501) at gopher.filter.dpi.c:331 #1 0x00000000004021e9 in read_response (s=3) at gopher.filter.dpi.c:355 #2 0x000000000040235a in render_dir (s=3, url=0x7fffffffd680 "gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map") at gopher.filter.dpi.c:384 #3 0x0000000000402823 in respond ( url=0x7fffffffd680 "gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map") at gopher.filter.dpi.c:466 #4 0x00000000004028ca in main () at gopher.filter.dpi.c:490 (gdb) up #1 0x00000000004021e9 in read_response (s=3) at gopher.filter.dpi.c:355 (gdb) p buf $3 = "i# 2026-01-04 - M1 Macro Processor Retreat\000Err\000null.host\000\061\000\000i\000Err\000null.host\000\061\000\000iI wrote a prototype gopher front-end to the Internet Archive. It was\000Err\000null.host\000\061\000\000ia single file AWK script using C"... (gdb) p start $4 = 12555

May 25, 2026

Re: dillo displays corrupted data using gopher protocol

by Rodrigo Arias

Hi, On Mon, May 25, 2026 at 02:14:27PM -0700, Ben Collver wrote: >Greetings, > >I am usuing dillo 3.3.0 on Slackware64 15.0. > >When i open the following document, dillo corrupts the content 100% of >the time. > > <gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map> > >See example screenshots linked below. > > <gopher://tilde.pink/I/~bencollver/files/dillo-1.png> > <gopher://tilde.pink/I/~bencollver/files/dillo-2.png> > >Details noticed about this corruption: > >* It never happens in lynx. >* It only happens for type 1 gopher items. >* It always begins on the line of text at offset 1500, which > happens to be the MTU for both the server and the client. > >Any suggestions for troubleshooting this further? I don't observe it here, which gopher plugin are you using and which commit? You can likely invoke it manually with: $ dpidc stop $ dpid & $ key=$(cat ~/.dillo/dpid_comm_keys | cut -d " " -f2) $ url="gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map" $ echo "<cmd='auth' msg='$key' '><cmd='open_url' url='$url' '>\n" |\ ~/.dillo/dpi/gopher/gopher.filter.dpi Perhaps using strace or gdb may help. Best, Rodrigo.

May 25, 2026

dillo displays corrupted data using gopher protocol

by Ben Collver

Greetings, I am usuing dillo 3.3.0 on Slackware64 15.0. When i open the following document, dillo corrupts the content 100% of the time. <gopher://tilde.pink/1/~bencollver/log/ 2026-01-04-m1-macro-processor-retreat/readme.map> See example screenshots linked below. <gopher://tilde.pink/I/~bencollver/files/dillo-1.png> <gopher://tilde.pink/I/~bencollver/files/dillo-2.png> Details noticed about this corruption: * It never happens in lynx. * It only happens for type 1 gopher items. * It always begins on the line of text at offset 1500, which happens to be the MTU for both the server and the client. Any suggestions for troubleshooting this further? Thanks! -Ben

May 25, 2026

Re: Save link as... silent failure on gopher protocol

by Rodrigo Arias

Hi, On Mon, May 25, 2026 at 09:25:58AM -0700, Ben Collver wrote: >Good day, > >I am using dillo 3.3.0 on Slackware64 15.0. > >If I open a gopher directory, right-click on an item, and click >Save link as..., this opens a file save dialog. If i click OK, it >dismisses the dialog. I expected it to save something, but it >creates no new files. > >Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/ >Top item: 40282-0 > >I found the following workaround: > >* Left click 40282-0 >* Click Save button in browser toolbar > >This creates a new file as expected. Yes, this is a known limitation of the downloads in Dillo. Using the "Save link as" to fetch a new resource will use wget under the hood, which only allows http(s). You can see the message in the console: > UIcmd_save: /tmp/40282-0.txt > ** WARNING **: Ignoring download request for > 'gopher://gopher.pglaf.org/0/4/0/2/8/40282/40282-0.txt': not in cache > and not downloadable. Browsing to the target file makes the gopher plugin fetch the file and place it in the Dillo cache (you can see it in about:cache). Then saving the current page (or going back and clicking the "Save link as" entry) works because it fetches it from the cache. It is planned to solve this some time in the future, but involves complex changes. In the meanwhile, you can use this workaround. Best, Rodrigo.

May 25, 2026

Save link as... silent failure on gopher protocol

by Ben Collver

Good day, I am using dillo 3.3.0 on Slackware64 15.0. If I open a gopher directory, right-click on an item, and click Save link as..., this opens a file save dialog. If i click OK, it dismisses the dialog. I expected it to save something, but it creates no new files. Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/ Top item: 40282-0 I found the following workaround: * Left click 40282-0 * Click Save button in browser toolbar This creates a new file as expected. Best regards, -Ben

May 25, 2026

Re: Dillo reporting UTF-8 bytes in URLs as bugs

by 256＠256-32.com

Thanks for the HTML4 standard link; I wasn't aware it didn't allow special characters in URLs. I have modified my static site generator to percent-encode these characters; it may be unimportant but I may as well conform to HTML4. > In HTML by the WHATWG they added exceptions for UTF-8 URLs, but I don't > think is a good idea. This breaks software that doesn't handle UTF-8 URLs > (i.e. anything that follows the RFC not what Google says). Can you name any examples of software that would break when presented with un-encoded UTF-8 URLs? Even Lynx supports them. P.S.: I know about RFC 3986; I've implemented it :^). The source of my confusion was that HTTP 1.0 (RFC 1945) defines URIs in a way that treats bytes >=0x80 as unreserved (section 3.2.1), and I falsely assumed HTML must be the same.

May 11, 2026

Re: Dillo reporting UTF-8 bytes in URLs as bugs

by Rodrigo Arias

Hi, On Sun, May 10, 2026 at 03:25:07AM +0100, 256(a)256-32.com wrote: >On my personal website <https://256-32.com/>, Dillo reports the following bug in >a link that uses special characters: >HTML warning: line 64, URL has 8 illegal bytes in {00-1F, 7F-FF} range ('/computers/důvěřivý'). Yes, we follow the RFC 3986 and the HTML 4.01 recommendation of marking illegal characters outside the unreserved set: https://www.w3.org/TR/html401/appendix/notes.html#h-B.2 In HTML by the WHATWG they added exceptions for UTF-8 URLs, but I don't think is a good idea. This breaks software that doesn't handle UTF-8 URLs (i.e. anything that follows the RFC not what Google says). My recommendation is to encode the URL with percent encoding: https://256-32.com/computers/d%C5%AFv%C4%9B%C5%99iv%C3%BD This is the URL that is used in HTTP, despite not being rendered as-is in the URL location of modern browsers. One of the problems with that is the Unicode "confusables", characters that render very similar but are different, like this: https://аpple.com See: https://www.xudongz.com/blog/2017/idn-phishing/ Best, Rodrigo.

May 10, 2026

Dillo reporting UTF-8 bytes in URLs as bugs

by 256＠256-32.com

On my personal website <https://256-32.com/>, Dillo reports the following bug in a link that uses special characters: HTML warning: line 64, URL has 8 illegal bytes in {00-1F, 7F-FF} range ('/computers/důvěřivý'). However, the HTTP response sent by my server specifies charset=utf-8 in the content type. These UTF-8 links work properly in Dillo, despite the bug message, and I believe my site is not in error here. <validator.w3.org> says my site is fine, so it seems there's nothing wrong with special characters in URLs. It doesn't report the same bytes outside of a link href as being bad. The error message seems to originate from src/html.cc:196.

May 10, 2026