- Dillo-dev - lists.mailman3.com

Re: "Buggy" bugtracker doesn't copy or symlink additional files

by Rodrigo Arias

Hi, >However, it appears that the "out" subdirectories of the program named >buggy do not receive symlinks nor copies of the "extra attachments" >files. Yeah, I'm aware. I have some fixes but I don't like any of them yet. I'll fix it eventually. Best, Rodrigo.

June 4, 2026

"Buggy" bugtracker doesn't copy or symlink additional files

by E. C. Masloch

Hello! In the bugtracker sources [1] it states: > This repository contains the issues for the Dillo web browser. Each issue is contained in a directory named with the issue number. The text of the issue is stored in the index.md markdown file and any extra attachments are placed inside the issue directory. However, it appears that the "out" subdirectories of the program named buggy do not receive symlinks nor copies of the "extra attachments" files. Here's how to find attachment files in the repo named bugtracker: ~/proj/buggy/bugtracker/git$ find -mindepth 2 -a \! -iname index.md | grep -E '^\.\/[0-9]+\/' ./521/repro.sh ./429/meta ./520/log.txt Example is in ticket 520 [2]. The link titled "Full trace log" leads to a 404 page [3]. Regards, ecm [1]: https://git.dillo-browser.org/bugtracker/tree/README.md?id=0239b970b60b6ea6… [2]: https://bug.dillo-browser.org/520/ [3]: https://bug.dillo-browser.org/520/log.txt

June 4, 2026

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