- Dillo-dev - lists.mailman3.com

Re: [PATCH] Prevent DilloPlain::write() from reading past end of buffer

by 256＠256-32.com

I don't have a whole redesign of the function in mind, but I thought about it some more and now I have a more elegant patch that I think fixes the problem. I made the second `++i` unconditional because I think `i` is now guaranteed to be less than MaxBytes at that point: diff --git a/src/plain.cc b/src/plain.cc index 0f5d6a48..0770af92 100644 --- a/src/plain.cc +++ b/src/plain.cc @@ -176,6 +176,14 @@ void DilloPlain::write(void *Buf, uint_t BufSize, int Eof) _MSG("DilloPlain::write Eof=%d\n", Eof); Start = (char*)Buf + Start_Ofs; + + if (Start_Ofs > 0 && Start_Ofs < BufSize && + Start[-1] == '\r' && Start[0] == '\n'){ + // Prevent \r\n from resulting in 2 line breaks. + ++Start_Ofs; + ++Start; + } + MaxBytes = BufSize - Start_Ofs; i = len = 0; while ( i < MaxBytes ) { @@ -189,8 +197,8 @@ void DilloPlain::write(void *Buf, uint_t BufSize, int Eof) break; case ST_Eol: addLine(Start + i - len, len); - if (Start[i] == '\r' && Start[i + 1] == '\n') ++i; - if (i < MaxBytes) ++i; + if (Start[i] == '\r' && i + 1 < MaxBytes && Start[i + 1] == '\n') ++i; + ++i; state = ST_SeekingEol; len = 0; break;

Oct. 21, 2026

Re: HTTP caching tests

by Rodrigo Arias

Hi, > I've had a quick look through the WPT repository. It has some > caching-related HTTP tests, but seemingly not that many that are > relevant to Dillo. I'm tempted to write my own HTTP testing system; > I've already done so before, although that was for a server rather > than a client. Maybe I'll adapt some things from WPT. Thanks!, I also saw https://github.com/http-tests/cache-tests by Mark Nottingham (results at https://cache-tests.fyi/) but it seems he joined the vibe coding club some time ago [1,2,3], so I wouldn't like to depend on this. Perhaps older content could be reused to make a test harness that doesn't need NPM and works on something else than a Mac (!!). [1]: https://mnot.net/blog/2025/using_ai [2]: https://mnot.net/blog/2026/using_ai [3]: https://github.com/http-tests/cache-tests/pull/171 Best, Rodrigo.

Oct. 17, 2026

Re: [PATCH] Prevent DilloPlain::write() from reading past end of buffer

by Rodrigo Arias

Hi, On Mon, Oct 12, 2026 at 05:55:08PM +0100, 256(a)256-32.com wrote: >DilloPlain:write() is written in such a way that it can receive a file one part >at a time, rather than all at once. As such, it might receive "line 1\r" and >then "\nline 2". I'm not sure if that actually happens in practise, and I >haven't been able to provoke this behaviour to test it (piping bytes into netcat >with a sleep delay didn't do it), but I think the old code would turn that \r\n >into 2 line breaks instead of 1, because the function is called separately for >both parts. > >I hope that makes sense. Oh, I see. Thanks for the clarification! >Most of the complexity of my patch consists of dealing with that. Maybe there's >still a simpler way to deal with it, though. Yeah, I don't like that much how this function is designed, is trying to do too many things at once. Do you have something in mind to try to make it simpler? I opened https://bug.dillo-browser.org/536/ to track it. Thanks!, Rodrigo.

Oct. 17, 2026

Re: [PATCH] Prevent DilloPlain::write() from reading past end of buffer

by 256＠256-32.com

DilloPlain:write() is written in such a way that it can receive a file one part at a time, rather than all at once. As such, it might receive "line 1\r" and then "\nline 2". I'm not sure if that actually happens in practise, and I haven't been able to provoke this behaviour to test it (piping bytes into netcat with a sleep delay didn't do it), but I think the old code would turn that \r\n into 2 line breaks instead of 1, because the function is called separately for both parts. I hope that makes sense. Most of the complexity of my patch consists of dealing with that. Maybe there's still a simpler way to deal with it, though.

Oct. 12, 2026

Re: [PATCH] Prevent DilloPlain::write() from reading past end of buffer

by Rodrigo Arias

Hi, On Thu, Sep 10, 2026 at 02:21:53PM +0100, 256(a)256-32.com wrote: >In src/plain.cc, \r\n sequences are handled with these lines: > >while ( i < MaxBytes ) { > ... > addLine(Start + i - len, len); > if (Start[i] == '\r' && Start[i + 1] == '\n') ++i; > if (i < MaxBytes) ++i; > ... > >So if a \r occurs, skip over the \n if present. But if i + 1 == MaxBytes, >Start[i + 1] is one past the end of the buffer, which is an out-of-bounds read. >This happens if a file ends in \r, or I suppose if a file gets broken up and >parsed with multiple invocations of the function. I think this could >theoretically add a redundant line break to the rendered page. > >My diff fixes this. I have tested it with \r, \r\n, and \n line endings. I >haven't been able to test how it behaves with plaintext pages that are parsed in >multiple invocations, though. > >(Also, and this is unrelated but it bothers me: prefsparser.cc has a comment >saying the `symbols` array is sorted, but it isn't.) > > >diff --git a/src/plain.cc b/src/plain.cc >index 0f5d6a48..e085ab19 100644 >--- a/src/plain.cc >+++ b/src/plain.cc >@@ -142,7 +142,10 @@ void DilloPlain::addLine(char *Buf, uint_t BufSize) > { > int len; > char buf[129]; >- char *end = Buf + BufSize; >+ char *end; >+ >+ if (BufSize > 0 && Buf[BufSize - 1] == '\r') --BufSize; >+ end = Buf + BufSize; > > currentLine++; /* Start at 1 */ > sprintf(buf, "L%ld", currentLine); /* Always fits */ >@@ -181,7 +184,8 @@ void DilloPlain::write(void *Buf, uint_t BufSize, int Eof) > while ( i < MaxBytes ) { > switch ( state ) { > case ST_SeekingEol: >- if (Start[i] == '\n' || Start[i] == '\r') >+ if (Start[i] == '\n' || (Start[i] == '\r' && i + 1 < MaxBytes >+ && Start[i + 1] != '\n')) > state = ST_Eol; > else { > ++i; ++len; >@@ -189,8 +193,7 @@ void DilloPlain::write(void *Buf, uint_t BufSize, int Eof) > break; > case ST_Eol: > addLine(Start + i - len, len); >- if (Start[i] == '\r' && Start[i + 1] == '\n') ++i; >- if (i < MaxBytes) ++i; >+ ++i; Why not just this? diff --git a/src/plain.cc b/src/plain.cc index 0f5d6a48..343cc05c 100644 --- a/src/plain.cc +++ b/src/plain.cc @@ -189,7 +189,8 @@ void DilloPlain::write(void *Buf, uint_t BufSize, int Eof) break; case ST_Eol: addLine(Start + i - len, len); - if (Start[i] == '\r' && Start[i + 1] == '\n') ++i; + if (Start[i] == '\r' && i + 1 < MaxBytes && Start[i + 1] == '\n') + ++i; if (i < MaxBytes) ++i; state = ST_SeekingEol; len = 0; Best, Rodrigo.

Oct. 11, 2026

Re: [PATCH 2/2] form input: try to find defaults for buttons without a value

by Rodrigo Arias

Hi, Sorry for the delay. On Sat, Aug 22, 2026 at 09:24:22AM +0200, Andreas Kemnade wrote: >This also prevents crashes due to resource == NULL >Examples can be found at https://www.pythontutorial.net/python-oop/ >--- > src/form.cc | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > >diff --git a/src/form.cc b/src/form.cc >index 038b94f3..e9b9c984 100644 >--- a/src/form.cc >+++ b/src/form.cc >@@ -538,7 +538,8 @@ void Html_tag_open_input(DilloHtml *html, const char *tag, int tagsize) > } else if (!dStrAsciiCasecmp(type, "button")) { > inp_type = DILLO_HTML_INPUT_BUTTON; > if (value) { We want to always create the button even with no value, so we need the resource. >- init_str = value; >+ label = value ? value : name ? name : "Submit"; From <https://html.spec.whatwg.org/multipage/input.html#button-state-(type=button)>: >If the element has a value attribute, the button's label must be the >value of that attribute; otherwise, it must be the empty string. I would also prefer to leave it empty to make it visible that the value is missing, otherwise you may not realize it has no value. I ended up merging the patch I wrote a while ago when the HTML fuzzer I'm testing triggered the same bug: https://git.dillo-browser.org/dillo/commit/?id=0a5e76decf21b042e6829a3616fe… For the same reason, I want to avoid this: >- if (inp_type != DILLO_HTML_INPUT_UNKNOWN) { >+ if ((inp_type != DILLO_HTML_INPUT_UNKNOWN) && (resource || embed)) { So it crashes when there is not resource and no embed. I added an assert: https://git.dillo-browser.org/dillo/commit/?id=784bedf88b37d70e283dd0490e3b… There should be not more cases left in which we arrive with no resource or embed, but let me know otherwise. Thanks!, Rodrigo.

Oct. 11, 2026

Re: Pasta Market: Changing Consumer Preferences and New Opportunities

by Jesse Lawton

Uhh don't really think this has anything to do with dillo lol On Wed, Oct 07, 2026 at 09:07:55AM +0000, riyaj.reed(a)gmail.com wrote: > The global pasta market is evolving as consumers increasingly seek convenient, versatile, and affordable food options that fit modern lifestyles. Pasta remains a staple across households and foodservice establishments because of its ease of preparation, long shelf life, and ability to complement a wide range of sauces and ingredients. From traditional wheat pasta to whole-grain, gluten-free, organic, and plant-based varieties, manufacturers are expanding their product portfolios to meet changing dietary preferences. > > The pasta market is benefiting from the growing popularity of convenient meal solutions. Busy consumers often prefer foods that can be prepared quickly without compromising taste or versatility. Pasta can be incorporated into numerous cuisines, making it attractive to consumers across different regions. Product innovation is also contributing to market opportunities, with companies introducing new shapes, flavors, ingredients, and packaging formats designed to improve convenience and appeal to health-conscious shoppers. > > Source: https://www.marketresearchfuture.com/reports/pasta-market-2428 > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com -- Thanks Jesse Lawton

Oct. 7, 2026

Pasta Market: Changing Consumer Preferences and New Opportunities

by riyaj.reed＠gmail.com

The global pasta market is evolving as consumers increasingly seek convenient, versatile, and affordable food options that fit modern lifestyles. Pasta remains a staple across households and foodservice establishments because of its ease of preparation, long shelf life, and ability to complement a wide range of sauces and ingredients. From traditional wheat pasta to whole-grain, gluten-free, organic, and plant-based varieties, manufacturers are expanding their product portfolios to meet changing dietary preferences. The pasta market is benefiting from the growing popularity of convenient meal solutions. Busy consumers often prefer foods that can be prepared quickly without compromising taste or versatility. Pasta can be incorporated into numerous cuisines, making it attractive to consumers across different regions. Product innovation is also contributing to market opportunities, with companies introducing new shapes, flavors, ingredients, and packaging formats designed to improve convenience and appeal to health-conscious shoppers. Source: https://www.marketresearchfuture.com/reports/pasta-market-2428

Oct. 7, 2026

Re: How minimalist should Dillo be?

by 256＠256-32.com

Thank you for replying. I'm aware you're busy, so please don't feel obligated to respond immediately; this thread will still be here in October. On Sat, Sep 26, 2026 at 02:05:34PM +0200, Rodrigo Arias wrote: > I'll suggest implementing first the tests that fail due to unsupported cache > support. Take a look at https://github.com/dillo-browser/testsuite (pending > to be moved to our server) and see if there is something in WPT that we can > reuse to test dillo (without JS). I've had a quick look through the WPT repository. It has some caching-related HTTP tests, but seemingly not that many that are relevant to Dillo. I'm tempted to write my own HTTP testing system; I've already done so before, although that was for a server rather than a client. Maybe I'll adapt some things from WPT. > The layout engine has nothing to do with expires. I'm aware, I mentioned it as a separate thing.

Sept. 26, 2026

Re: How minimalist should Dillo be?

by Rodrigo Arias

Hi, I will be unable to work on Dillo or reply for the next weeks, probably around mid-October I can come back. On Fri, Sep 25, 2026 at 05:09:47PM +0100, 256(a)256-32.com wrote: >I want to improve Dillo in a bunch of ways, most urgently by adding support for >the "expires" HTTP header field, and improving the HTML/CSS rendering. I'm >worried, though, that if I submit a huge patch to do one of these things it'd >get rejected for not being minimalist enough. The current blocker from implementing this is the infrastructure to test that new features work fine. I wrote dilloc with this kind of tests in mind so we can do more complicated HTTP tests and see if it works properly. Until we don't have the tests I don't think I want to implement new features we cannot test (other than manually). I'll suggest implementing first the tests that fail due to unsupported cache support. Take a look at https://github.com/dillo-browser/testsuite (pending to be moved to our server) and see if there is something in WPT that we can reuse to test dillo (without JS). We can merge the failing tests first, then focus on the implementation in dillo for expires and other headers and check that the test pass. In the testsuite we can use python or other high-level tools that make writing tests easier than C (that is why it is separated from the dillo code). >My question is, would substantially fleshing out the layout and style >engines be seen as going against the spirit of Dillo? The layout engine has nothing to do with expires. I would recommend not touching the layout engine for now (mostly for the same reason, lack of tests). >Would it push too far against the 1.44MB limit? It is unlikely that you will pass that limit with handwritten code, as gzip will compress your code with the current codebase. Don't worry too much about that, there are stuff pending to be removed that will make some room and I have some provisions to make more room if that limit is reached. Thanks!, Rodrigo.

Sept. 26, 2026