Stephan Bosch [Thu, 6 Sep 2018 00:51:09 +0000 (02:51 +0200)]
lib-http: client: peer: Determine number of pending peers in http_client_peer_shared_connection_failure() itself.
Before, the number of pending peers was a parameter, but that was only for a
single peer pool. This is wrong, since the one peer can have many different
pools (depending on how many clients with incompatible configs share this
peer).
Timo Sirainen [Thu, 23 Aug 2018 11:33:59 +0000 (14:33 +0300)]
fts: Fix indexing mails with NULs in headers
After the first NUL all the rest of the string was converted to spaces.
This was broken already in the initial commit that attempted to fix this: 4d27f95c76bd008bb38f9c442567046da2b6ce14
Timo Sirainen [Fri, 17 Aug 2018 11:39:41 +0000 (14:39 +0300)]
lib-storage: Fix NUL handling in mail_get_first_header*(), mail_get_headers*()
These functions return NUL-terminated values, so they got truncated whenever
a header value contained a NUL. Fix this by converting NULs to unicode
replacement characters in the output.
Timo Sirainen [Wed, 25 Apr 2018 11:19:27 +0000 (14:19 +0300)]
lib-mail: Remove MESSAGE_HEADER_REPLACE_NULS_WITH_0x80 flag
As mentioned in previous commit, 0x80 isn't valid UTF-8 and we shouldn't
encourage using it. This implementation also can't be easily changed to
use unicode replacement character without larger changes to istream-nonuls.
Timo Sirainen [Wed, 25 Apr 2018 11:17:34 +0000 (14:17 +0300)]
lib-mail: Change NUL -> 0x80 replacement to use unicode replacement char instead
Using 0x80 produces invalid UTF-8 output, which we should avoid. Some places
in Dovecot code already requires that input is valid UTF-8, so it's also
safer and easier to use the unicode replacement character.
Timo Sirainen [Tue, 24 Apr 2018 15:01:03 +0000 (18:01 +0300)]
lib-mail: message_part_*_parse_from_header() - Replace NULs with 0x80
This avoids truncation of Content-*, Subject, Message-ID, In-Reply-To and
Date headers in IMAP ENVELOPE, BODY and BODYSTRUCTURE replies. Of course,
NULs in headers are violating RFCs already, so the previous behavior wasn't
really wrong either.
Timo Sirainen [Sat, 21 Apr 2018 13:07:21 +0000 (16:07 +0300)]
lib-fts: fts-tokenizer-address - Cleanup NUL handling in parent_data
The end result is anyway that the token will be truncated at the first NUL.
This change just makes the code a bit more understandable on where the
truncation will happen.
Timo Sirainen [Sat, 21 Apr 2018 13:11:48 +0000 (16:11 +0300)]
lib: Add str_append_max()
It's otherwise the same as str_append_n(), except it takes const char* as
input instead of const void*. This, as well as its name, should make it
less likely to be used wrong when the input may legitimately have NULs.
The unit test is changed from str_append_n() to str_append_max(), because
str_append_n() will be deprecated.
It's not valid to have "\<CR>" or "\<LF>", so the old behavior isn't really
wrong either. However, rfc822_parse_quoted_string() callers are more likely
to expect that the output won't contain any [CR]LF so this new behavior is
a bit better.
Timo Sirainen [Sat, 21 Apr 2018 09:47:22 +0000 (12:47 +0300)]
lib-mail: Change rfc822_parse_content_param() API to allow NULs in value
This was the only function in rfc822-parser.h that wasn't NUL-safe.
This won't fix anything, but it makes the rfc822-parser.h API fully
consistent with the NUL handling.
Normally rfc2231_parse() should be called instead of calling
rfc822_parse_content_param() directly, so this shouldn't break any plugins.
Timo Sirainen [Sat, 21 Apr 2018 13:03:42 +0000 (16:03 +0300)]
login-common: Consistently truncate client SASL input at first NUL
The input is supposed to be base64-encoded, so there's no need to support
actual NUL characters. The previous code truncated at NULs, but could have
kept appending more data to the value. This could have produced somewhat
random results.
Timo Sirainen [Sat, 21 Apr 2018 12:58:15 +0000 (15:58 +0300)]
lib-master, util: Consistently truncate tabescaped input at the first NUL
The NULs are supposed to come tab-escaped, so there's no need to support
actual NUL characters. The previous code truncated at NULs, but could
have kept appending more data to the value. This could have produced
somewhat random results.
Timo Sirainen [Sat, 21 Apr 2018 12:53:42 +0000 (15:53 +0300)]
config: Consistently truncate value at the first NUL in value input file
When value contained "<file", the file was added as a value. The setting
values don't currently support NULs, so the value gets truncated at the
first NUL. However, the previous code could have appended more data to
the value. This could have produced somewhat confusing results.
Timo Sirainen [Sat, 21 Apr 2018 12:50:08 +0000 (15:50 +0300)]
dict-fs/memcached-ascii/redis: Consistently truncate value at NULs
The dict API currently doesn't support NULs in values, so they have to be
truncated. However, previously they were truncated at NULs, but more data
may have still been appended to the value. This could have produced
somewhat random results.
Timo Sirainen [Sat, 21 Apr 2018 11:31:08 +0000 (14:31 +0300)]
lib-storage: Fix truncating header values at NUL when adding to cache
For example FETCH BODY.PEEK[HEADER.FIELDS (Subject)] could have returned
the NUL on the first fetch when the mail wasn't in dovecot.index.cache,
but the second FETCH would have returned it truncated at the NUL.
The delay (previously 100ms, now 1s) is intended to delay our exit enough so
that the child processes have a chance to receive & handle the SIGQUITs we
just sent. If we don't wait long enough, it is possible that we'll get
restarted before our children had the chance to stop listening on their
sockets and we'll hit "address already in use" type errors.
Increasing the delay does not fix the issue, but it masks it better.
Timo Sirainen [Wed, 13 Jun 2018 17:09:32 +0000 (20:09 +0300)]
doveadm dump: Fix dumping "vsize" header in dovecot.index
It was trying to print it as the "vsize" header in dovecot.list.index.
This caused confusing output, as well as potentially accessing memory
out of bounds.
Timo Sirainen [Tue, 12 Jun 2018 14:08:04 +0000 (17:08 +0300)]
lib-dcrypt, mail-crypt: Fix leaking memory when using non-global keys
The users' private keys had one reference too much. Because of key cache,
most likely the keys were leaked only once at deinit.
Changed the i_stream_create_decrypt_callback() API so that it allows the
callback to create the key itself without having to store it anywhere.
In this case the key was already added to cache, which increased its
refcount. So an alternative fix would have been to simply unreferenced the
key before returning it. It's a bit ugly though to rely on such caches,
since without the cache the code would be buggy.