- Dillo-dev - lists.mailman3.com

dpi problem

by Teddi Vazquez

Hello, I'm trying to add the plugins for gopher and gemini, when i run the "make install" the next message appears in both: echo 'proto.gopher=gopher/gopher.filter.dpi' >> /root/.dillo/dpidrc dpidc stop || true ** ERROR **: [Dpi_read_comm_keys] No such file or directory ** ERROR **: main: Can't read dpid's port number mkdir -p ~/.dillo/dpi/gopher cp -f gopher.filter.dpi ~/.dillo/dpi/gopher I read the docs and thought maybe it was because the "dpi_dir" option wasn't added: "dpi_dir=~/.dillo/dpi/" but when I run dillo on the terminal this appears: prefs: {dpi_dir} is not a recognized token. paths: Cannot open file '/home/tmv/.dillo/keysrc': No such file or directory paths: Using /usr/local/etc/dillo/keysrc paths: Cannot open file '/home/tmv/.dillo/domainrc': No such file or directory paths: Using /usr/local/etc/dillo/domainrc I'm sorry if this obvious error, if possible I would like to receive some help, thanks. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GC/CS/H/IT/L/M/P/S/SS/O d- s+: a? C++++ UL++++ P+ L+++ E+ W+++ N+ o- K++ w O-- M V- PS+++ PE++ Y+ PGP++ t+ 5+ X+ R tv b++++ DI--- D+ G++ e* h! r- x* ------END GEEK CODE BLOCK------ GPG: 37219EA0D04C8D3C Keybase: tmv

June 15, 2026

[PATCH] Fix header parsing bug with malicious header fields

by 256＠256-32.com

In cache.c, Cache_parse_multiple_fields() doesn't properly skip to the end of the line after finding a match, meaning you can trick it into thinking a single field is actually multiple fields. You can test it by running this command, assuming you have netcat installed: printf $'HTTP/1.0 200\r\nWarning: .Warning: x\r\n\r\n' | nc -Nl 8080 You can then direct Dillo to <http://localhost:8080/>. Dillo's output is then: HTTP warning: .Warning: x HTTP warning: x With this patch, the second line is not produced. (I also fixed a comment that uses the wrong name for a variable; I hope you don't mind.) Sorry the patch isn't in the usual .patch format, I'm new to git. diff --git a/src/cache.c b/src/cache.c index 154bef5c..5bd8a5dc 100644 --- a/src/cache.c +++ b/src/cache.c @@ -287,7 +287,7 @@ static int Cache_bufsize(CacheEntry_t *e) * Inject full page content directly into the cache. * Used for "about:splash". May be used for "about:cache" too. * - * The @param data_ds buffer is copied into the entry buffer, so it is + * @param buf is copied into the entry buffer, so it is the * responsibility of the caller to free it. */ void a_Cache_entry_inject(const DilloUrl *Url, @@ -765,9 +765,8 @@ static Dlist *Cache_parse_multiple_fields(const char *header, j--; field = dStrndup(header + i, j); dList_append(fields, field); - } else { - while (header[i] != '\n') i++; } + while (header[i] != '\n') i++; } if (dList_length(fields) == 0) {

June 14, 2026

Re: [Issue]: Parsing empty domain attributes in cookies

by Rodrigo Arias

Hi, On Wed, Apr 29, 2026 at 09:52:40PM +0200, Rodrigo Arias wrote: >I will merge it after fixing the cookies unit test, so I can add extra >cases for empty domains. Sorry for the delay, merged here: https://git.dillo-browser.org/dillo/commit/?id=9489bacfa2d051e52f6b9b43a246… Also added a couple of test cases. Best, Rodrigo.

June 6, 2026

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

by E. C. Masloch

On at 2026-06-04 19:11:55 +0200, Rodrigo Arias <rodarima(a)gmail.com> wrote: >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. I went and fixed this in my fork. The exact changeset is available on our hgweb [1]. Regards, ecm [1]: https://hg.pushbx.org/ecm/buggy/rev/71903036f451

June 5, 2026

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