similar to: [RFC master-2.2 0/1] Support OpenSSL 1.1 API for setting allowed TLS versions

The openssl library in Debian unstable (targeting Buster) supports TLS1.2 by default. The library itself supports also TLS1.1 and TLS1.0. If the admin decides to also support TLS1.[01] users he can then enable the lower protocol version in case the users can't update their system. Signed-off-by: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> --- src/config/all-settings.c

Sorry to bump up an old thread. 2.3.11.3 already contains this patch and the error still gets generated.? Anything else we could try ? Scott On Wednesday, 19/08/2020 at 11:37 Josef 'Jeff' Sipek wrote: On Wed, Aug 19, 2020 at 17:03:57 +0200, Alessio Cecchi wrote: > Hi, > > after the upgrade to Dovecot 2.3.11.3, from 2.3.10.1, I see frequently > these errors from

Q1) I can't get ssl_verify_client_cert=yes working. The ssl key and cert are signed using our CA. Also the ssl_ca_file has a CRL appended (no revokes yet). Expected behavior: Stop the SSL (the client doesn't have a cert installed) Current behavior: Mail clients accepts SSL and login succeeds. (both Evolution and Thunderbird). My bad? Please advise. Q2) The next step, if dovecot blocks

Hi, after the upgrade to Dovecot 2.3.11.3, from 2.3.10.1, I see frequently these errors from different users: Aug 18 11:02:35 Panic: indexer-worker(info at domain.com) session=<g71KISOttvS5LNVj:O3ahCyuZO18cYAAAEPCW+w>: file http-client-request.c: line 1232 (http_client_request_send_more): assertion failed: (req->payload_input != NULL) Aug 18 11:02:35 Error: indexer-worker(info at

On 19/08/2020 17:37, Josef 'Jeff' Sipek wrote: > On Wed, Aug 19, 2020 at 17:03:57 +0200, Alessio Cecchi wrote: >> Hi, >> >> after the upgrade to Dovecot 2.3.11.3, from 2.3.10.1, I see frequently >> these errors from different users: > It looks like this has been around for a while and you just got unlucky and > started seeing this now. Here's a quick

Sorry about that. My FreeBSD system automatically applied your patches and I assumed they were already part of the master. Unfortunately it still means the bug isn't resolved with these changes. On Wednesday, 02/09/2020 at 15:34 Josef 'Jeff' Sipek wrote: On Wed, Sep 02, 2020 at 15:07:37 -0400, Scott Q. wrote: > Sorry to bump up an old thread. > > 2.3.11.3 already

On 19.08.20 17:37, Josef 'Jeff' Sipek wrote: > On Wed, Aug 19, 2020 at 17:03:57 +0200, Alessio Cecchi wrote: >> Hi, >> >> after the upgrade to Dovecot 2.3.11.3, from 2.3.10.1, I see frequently >> these errors from different users: > It looks like this has been around for a while and you just got unlucky and > started seeing this now. Here's a quick

https://www.lerctr.org/~ler/dovecot/doveadm-index-fts-debug.txt https://www.lerctr.org/~ler/dovecot/doveadm-index-fts-bt.txt I wish there was a way to set plugins {fts_solr = <blah>} from the command line :( but I turned it on globally for that run. On Wed, Jan 2, 2019 at 3:40 PM Stephan Bosch <stephan at rename-it.nl> wrote: > Oh, d'oh. I was looking for some solr debug

On 16.10.20 18:00, Scott Q. wrote: > This reminds me, the way I was able to reproduce this consistently was > by having large headers ( 100+ lines ). > > > On Friday, 16/10/2020 at 11:49 Patrik Peng wrote: > > On 19.08.20 17:37, Josef 'Jeff' Sipek wrote: > >> On Wed, Aug 19, 2020 at 17:03:57 +0200, Alessio Cecchi wrote: >>> Hi,

Hi all, As I reported earlier (with a typo in the work [BUG]) client certification validation *does not* work even if you do everything exactly according to all documentation and attempts at helpful advice. I have seen this issue with both startssl.com and self-signed certificates, and based on what I've seen from searching the web, this is a problem that has gotten little attention because

On 27 August 2017 08:32:06 CEST, Timo Sirainen <tss at iki.fi> wrote: >> DEF(SET_STR, ssl_protocols), >> DEF(SET_STR, ssl_cert_username_field), >> DEF(SET_STR, ssl_crypto_device), >> + DEF(SET_STR, ssl_lowest_version), > >Does it really require a new setting? Couldn't it use the existing >ssl_protocols setting? You need to set a minimal version.

On 21/10/2020 16:44, Patrik Peng wrote: > On 16.10.20 18:34, Patrik Peng wrote: >> On 16.10.20 18:00, Scott Q. wrote: >>> This reminds me, the way I was able to reproduce this consistently >>> was by having large headers ( 100+ lines ). >>> >>> >>> On Friday, 16/10/2020 at 11:49 Patrik Peng wrote: >>> >>> On 19.08.20

# HG changeset patch # User David Hicks <david at hicks.id.au> # Date 1373085976 -36000 # Sat Jul 06 14:46:16 2013 +1000 # Node ID ccd83f38e4b484ae18f69ea08631eefcaf6a4a4e # Parent 1fbac590b9d4dc05d81247515477bfe6192c262c login-common: Add support for ECDH/ECDHE cipher suites ECDH temporary key parameter selection must be performed during OpenSSL context initialisation before ECDH and

On 22/10/2020 10:23, John Fawcett wrote: > On 21/10/2020 19:00, John Fawcett wrote: >> On 21/10/2020 16:44, Patrik Peng wrote: >>> On 16.10.20 18:34, Patrik Peng wrote: >>>> On 16.10.20 18:00, Scott Q. wrote: >>>>> This reminds me, the way I was able to reproduce this consistently >>>>> was by having large headers ( 100+ lines ).

Hello, When running multiple instances of dovecot on the same host (or running multiple docker container), it is hard to distinguish logs from different processes: the syslog entries are all prefixed with the same identifier "dovecot" It is hardcoded here: https://github.com/dovecot/core/blob/master/src/lib-master/master-service.c#L420 Would it make sense to use the already implemented

On 15/11/2020 15:49, PGNet Dev wrote: > On 11/15/20 6:33 AM, John Fawcett wrote: >> I've configured a tika server behind an apache proxy which enforces >> basic auth, but sending basic auth credentials for a tika server is not >> currently supported by Dovecot. > > i was _just_ setting up a tika instance behind a nginx proxy with > basicauth in place. > >

I went from a nightly of about 20051117 or so (about alpha4 generation) to 1.0beta1 yesterday, and dovecot is now spinning the CPU furiously apparently every ~10 minutes per: Jan 18 13:04:36 server dovecot: SSL parameters regeneration completed Jan 18 13:14:14 server dovecot: SSL parameters regeneration completed Jan 18 13:24:00 server dovecot: SSL parameters regeneration completed Jan 18

I've installed grep PRETTY /etc/os-release PRETTY_NAME="Fedora 32 (Server Edition)" dovecot --version 2.3.10.1 (a3d0e1171) openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 iiuc, Dovecot has apparently had support for setting TLS 1.3 ciphersuites since v2.3.9, per this commit lib-ssl-iostream: Support TLSv1.3 ciphersuites

Today I've been trying to get dovecot (1.0 rc2) to use certificates for client side authentication. If my memory serves right, beta8 had no problems with it (although it was some time ago and on different machine). Similar setup works perfectly well for postfix (for authentication that is, on the same machine). Originally I thought I overdid some certificate settings (keyUsage, nsCertType,

I pulled the recent dovecot-2.0-pigeonhole and dovecot 2.0.x trees and rebuild, got this error today: ... make[3]: Leaving directory /usr/src/dovecot-2.0/dovecot-2.0-pigeonhole/src/managesieve' make[2]: Leaving directory /usr/src/dovecot-2.0/dovecot-2.0-pigeonhole/src/managesieve' Making install in managesieve-login make[2]: Entering directory