similar to: [PATCH] Manually cleanup OpenSSL from dovecot_openssl_common_global_unref()

Hi, This patch: On 15/11/2016 10:46 PM, Aki Tuomi wrote: > > > On 13.11.2016 20:04, Apollon Oikonomopoulos wrote: >> OpenSSL 1.1 features a cleanup function that is automatically run on shutdown >> using atexit(3). This function frees all OpenSSL-allocated resources. >> >> In dovecot, OpenSSL is loaded indirectly using dlopen(3) against the relevant >>

On 13.11.2016 20:04, Apollon Oikonomopoulos wrote: > OpenSSL 1.1 features a cleanup function that is automatically run on shutdown > using atexit(3). This function frees all OpenSSL-allocated resources. > > In dovecot, OpenSSL is loaded indirectly using dlopen(3) against the relevant > dovecot crypto module and is finally unloaded using dlclose(3). Until > OpenSSL 1.0.1c this

On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > It turns out there's a missing byte-inversion when loading the blocks > which should be addressed in getblock{32,64}. Murmurhash treats each > block as an integer expecting little-endian storage. Applying this > additional change fixes the build on s390x (and

Hi, On 12:55 Mon 26 Mar , Josef 'Jeff' Sipek wrote: > On Mon, Mar 26, 2018 at 15:57:01 +0300, Apollon Oikonomopoulos wrote: > ... > > I'd be happy to test the patch, thanks! > > Ok, try the attached patch. (It is a first pass at the issue, so it may not > be the final diff that'll end up getting committed. It'd be good to know if > it actually

Hi, I am running Dovecot 2.2.26.0 compiled against OpenSSL 1.1 and, since upgrading to OpenSSL 1.1.0c, the "lmtp" process has been crashing with SIGSEGV whenever it receives SIGINT. This always happens a minute or so after the lmtp process handles a message. It can also be manually reproduced by sending SIGINT to one of the running lmtp processes. I am compiling and running on an

If the standard way works, I am happy to include the original patch I sent, amended so that it checks for presence of LIBRESSL_VERSION_NUMBER. If they keep this promise, then we should have no worries about things breaking up. Aki On 02.11.2016 14:24, Michael A. Peters wrote: > Indeed, which is why I use it. > > But it also is in the minority which is why I find it acceptable for

Hi, Apparently the "kick" doveadm_cmd_ver2 struct lacks a .mail_cmd member pointing to an appropriate allocation function, causing a NULL pointer dereference when used via `doveadm batch`. (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000555555585882 in doveadm_mail_cmd_init (cmd=cmd at entry=0x7fffffffe680, set=0x5555555f2440) at doveadm-mail.c:596 #2 0x0000555555586f68 in

This is driven by the fact that OpenSSL 1.1 does not know about SSLv2 at all and dovecot's defaults simply make OpenSSL error out with "Unknown protocol 'SSLv2'"[1]. So we change the defaults to refer to SSLv2 iff OpenSSL seems to know something about it. While at it, it's also a good idea to disable SSLv3 by default as well. [1] https://bugs.debian.org/844347

Hi, The dovecot 2.3.0.1 Debian package currently fails to build on all big-endian architectures[1], due to murmurhash3 tests failing. The relevant output from e.g. s390x is: test-murmurhash3.c:22: Assert(#8) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 test-murmurhash3.c:22: Assert(#11) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 test-murmurhash3.c:22:

Hi Aki, On 15:55 Mon 26 Mar , Aki Tuomi wrote: > On 26.03.2018 15:49, Apollon Oikonomopoulos wrote: > > Hi, > > > > The dovecot 2.3.0.1 Debian package currently fails to build on all > > big-endian architectures[1], due to murmurhash3 tests failing. The > > relevant output from e.g. s390x is: > > > > test-murmurhash3.c:22: Assert(#8) failed:

Hi, I'm seeing the following segfault when I run `doveadm search mailbox inbox` with the zlib module enabled with dovecot 2.18 and glibc 2.22 on Arch Linux. It does not happen with glibc 2.21. I've noticed that when I remove "zlib" from the mail_plugins line at the beginning of the config file the segfault goes away. I've also tested hg tip and the problem does not appear

Hi, I came up with the following patch while trying to figure out a good solution for the situation described in Debian bug #871987[1]. In short, OpenSSL in Debian unstable has disabled TLSv1.0 and TLSv1.1 *by default*. That means that unless an application requests otherwise, only TLSv1.2 is supported. In the world of e-mail this is seemingly an issue, as there are still way too many old clients

Hello all, I've been trying to use a Samba3 fileserver with security = ADS in a domain where the DC is Samba4. It all seems to work, except for users with long names. What happens is that users can log in to the domain with their userPrincipalName as well as the sAMAccountName. Unfortunately, if the username is longer than 20 characters (which, because of our username =

Control: tags -1 + moreinfo upstream [Forwarding this to the Dovecot mailing list, just in case someone can help] Hi, Thanks for the report! See my comments inline. On 11:56 Thu 21 Sep , Thurgood Angelou wrote: > Package: dovecot-core > Version: 1:2.2.32-2 > > I've just discovered a bug where the sieve plugin (especially IMAP) > will not work with a virtual mailbox. I

On 2016-11-02, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > If the standard way works, I am happy to include the original patch I > sent, amended so that it checks for presence of LIBRESSL_VERSION_NUMBER. > If they keep this promise, then we should have no worries about things > breaking up. Diff below is what I've added to OpenBSD ports. The libressl API is not cast in

On Tue, Mar 27, 2018 at 13:15:31 +0300, Apollon Oikonomopoulos wrote: > On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > It turns out there's a missing byte-inversion when loading the blocks > > which should be addressed in getblock{32,64}. Murmurhash treats each > > block as an integer

On Tue, Mar 27, 2018 at 08:46:20 -0400, Josef 'Jeff' Sipek wrote: > On Tue, Mar 27, 2018 at 13:15:31 +0300, Apollon Oikonomopoulos wrote: > > On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > > It turns out there's a missing byte-inversion when loading the blocks > > > which

Hi all, Ok, I have a strange problem after updating both dovecot and openssl... OpenSSL was 1.0.0j, now updated to 1.0.1c Dovecot was 2.1.13, now updated to 2.1.15 I'm getting a bunch of lines like the following: Feb 23 10:48:01 myhost dovecot: imap-login: Disconnected (no auth attempts in 29 secs): user=<>, rip=#.#.#.#, lport=993, TLS handshaking: SSL_accept() syscall failed:

I''m working on Michael Hartl''s ruby on rails tutorial http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#sec-development_tools . I installed Git, updated my OS to 10.8.2 and downloaded XCode 4.5.2. when I type in rvm install 1.9.3 this long thing comes up... Ruby (and needed base gems) for your selection will be installed shortly. Before it happens, please read and

On 15.11.2016 13:27, Michael Marley wrote: > Hi, > > I am running Dovecot 2.2.26.0 compiled against OpenSSL 1.1 and, since > upgrading to OpenSSL 1.1.0c, the "lmtp" process has been crashing with > SIGSEGV whenever it receives SIGINT. This always happens a minute or so > after the lmtp process handles a message. It can also be manually > reproduced by sending