openwall / blists Goto Github PK

blists does check for errors from malloc and realloc, but it does so in its lower-level wrappers such as buffer_grow, msgs_grow, and concat. The higher-level and /indirect callers of those do not always check whether an error occurred (example: uses of concat in html_error_real) or when they do they might not make it clear to the sysadmin what the issue really is (example: msgs_grow failure in begin_inc_idx will result in non-incremental index update with no reason given as to why, which is especially unexpected to a sysadmin given that the underlying realloc can sometimes momentarily need almost 2x more memory than the requested new size).

We should review these cases and introduce reasonable error reporting.

Header lines may be wrapped for technical and standards compliance reasons. When we display message headers via the web, we currently include those technical line wraps intact. We should omit them. For example, we display:

https://www.openwall.com/lists/oss-security/2024/07/23/2

Subject: [OSSA-2024-002] OpenStack Nova: Incomplete file access fix and
 regression for QCOW2 backing files and VMDK flat descriptors
 (CVE-2024-40767)

but it should be:

Subject: [OSSA-2024-002] OpenStack Nova: Incomplete file access fix and regression for QCOW2 backing files and VMDK flat descriptors (CVE-2024-40767)

I thought this had something to do with:

                /* skip adjacent linear-white-space between previous
                 * encoded-word */
                r = --p;
                if (done != header) {
                        while (r > done && islinearwhitespace(*(--r)))
                                ;
                        if (r > done)
                                r = p;
                }
                buffer_append(dst, done, r - done);

and suspected this logic could be buggy or incomplete, but e.g. omitting if (r > done) r = p; made no difference.

We have some http URLs generated by html.c, included in README (one of them in a configuration example), and in comments in md5.[ch]. It's high time we change them to https.

We should include the Message-ID header alongside the currently displayed Date/From/To/Subject headers... or maybe below the message body? Either way, this is a bit tricky since we're obfuscating anything that looks like an e-mail address, and Message-ID strings do look like that, so we'll probably need a bypass of the obfuscation.