Re: regarding ssl certificates

[Michael A. Peters via dovecot]

With PKIX validation the certificate should match the hostname.

With SMTP, the hostname should match the reverse IP though often it does 
not.


Using subdomains gives you flexibility.

with DANE validation, it is DNSSEC that validates the fingerprint to the 
hostname so I do not believe there is a need for the hostname in the 
cert to match anything, but DANE validation is currently not used by any 
mail user agents, only PKIX validation is used by mail user agents.


DANE is used to MTA to MX quite frequently however, so it may come to 
mail user agents in the near future (near being within a decade or so).


On 3/14/19 10:03 PM, Gary via dovecot wrote:

Is there some reason to use a mail.domain.com cert for mail rarher than just 
using domain.com for everything?

Historically the subdomain were used because they were on different hardware. 
That is www was on one machine and mail was on another.





  Original Message



From: dovecot@dovecot.org
Sent: March 14, 2019 3:56 PM
To: dovecot@dovecot.org
Reply-to: jtam.h...@gmail.com
Subject: Re: regarding ssl certificates


mick crane wrote:


Apache2 default install has this snake oil certificate
Can make a new one for apache


I won't go over some of the excellent points in previous posts,
but I will mention SAN as a third type of certificate you can make.
LetsEncrypt supports this type of certificate.

This is halfway between single CN and wildcard certificate where you can
combine many hostnames (up to 1000?) into one certificate.  This may
be useful if you want the convenience of handling fewer certificates,
without having an unbounded wildcard certificate (the latter also requires
control over your DNS).  I use this for SMTPAUTH, POP3, IMAP and webmail
services since they are all on one server.

Then Stephan von Krawczynski wrote:


Sorry I have to write this, but this is again pointing people in a fake
security direction.
The only valid authority for a certificate is the party using it. Any third
party with unknown participants cannot be a "Certificate Authority" in its
true sense. This is why you should see "Let's Encrypt" simply as a cheap way
to fake security. It is a US entity, which means it _must_ hand out all
necessary keys to fake certificates to the US authorities _by law_.
Now probably you can imagine why they are giving the certificates out for
free. US authorities can compromise all of them - without any "open knowledge".


Wow, you packed a lot of fear, uncertainty and doubt (and some
misinformation) into one paragraph.  I'll leave it at that.

Joseph Tam 

Re: offtopic: rant about thoughtless enabling DMARC checks

[Michael A. Peters via dovecot]

On 2/10/19 3:46 PM, Michael A. Peters via dovecot wrote:

On 2/10/19 3:42 PM, Noel Butler via dovecot wrote:

On 10/02/2019 12:49, Benny Pedersen via dovecot wrote:



fixing mailman will be the fail, solve it by letting opendkim and 
opendmarc not reject detected maillist will be solution,



A general broad mailing list whitelist will be problematic, do work it 
needs to look for specific list type hidden headers,  spammers and 
nasties will incorporate those headers into their trash that 
impersonates mailing lists and voila, they pass.


However the majority of spammers do not spam with a properly configured 
Reverse DNS - so detect the list header and skip DMARC if list headers 
are present AND Reverse DNS matched the HELO/EHLO




Also, DMARC isn't really anti-spam technology, it's anti-spoof technology.

Rather than fake mail list headers, spammers will just use domains w/o a 
DMARC policy. Much easier.

Re: offtopic: rant about thoughtless enabling DMARC checks

[Michael A. Peters via dovecot]

On 2/10/19 3:42 PM, Noel Butler via dovecot wrote:

On 10/02/2019 12:49, Benny Pedersen via dovecot wrote:



fixing mailman will be the fail, solve it by letting opendkim and 
opendmarc not reject detected maillist will be solution,



A general broad mailing list whitelist will be problematic, do work it 
needs to look for specific list type hidden headers,  spammers and 
nasties will incorporate those headers into their trash that 
impersonates mailing lists and voila, they pass.


However the majority of spammers do not spam with a properly configured 
Reverse DNS - so detect the list header and skip DMARC if list headers 
are present AND Reverse DNS matched the HELO/EHLO

Re: offtopic: rant about thoughtless enabling DMARC checks [was: Re: Bounces?]

[Michael A. Peters via dovecot]

On 2/9/19 11:13 AM, Michael A. Peters via dovecot wrote:

On 2/9/19 10:48 AM, Juri Haberland via dovecot wrote:

*snip*


Honestly I was sort of tempted to try and create my own DMARC validator 
(I was thinking one daemon that does both DKIM and DMARC - for postfix, 
Exim has DKIM native but I only use Exim for submission) that tried to 
sniff Mailman and not enforce it but it looks like it would be very time 
consuming.




What I wanted to do, was sniff mailman in headers and if it was sent by 
mail, reject if reverse DNS didn't match HELO/EHLO and white list from 
OpenDMARC enforcement if it did. That would prevent most spoofed that 
tried to look like Mailman since spoofed mail rarely has reverseDNS 
properly set up but Mailman admins tend to.

Re: offtopic: rant about thoughtless enabling DMARC checks [was: Re: Bounces?]

[Michael A. Peters via dovecot]

On 2/9/19 10:48 AM, Juri Haberland via dovecot wrote:

On 09/02/2019 10:44, Aki Tuomi via dovecot wrote:

For some reason mailman failed to "munge from" for senders with dmarc policy ;(

It's now configured to always munge to avoid this again.


I'd say, let Mailman throw all people off the list that have enabled DMARC
checking without using exceptions for the lists they are on. It's a known
fact that DMARC does not cope well with mailing lists. Blindly enabling
DMARC checks without thinking about the consequences for themselves should
not be the problem of other well behaving participants.

Most people use OpenDMARC and there are patches to mark certain hosts as
mailing lists senders, so it is possible.


can you please let me know where to find those patches?

I ran DMARC in testing on one domain and had to disable it because over 
95% of the reports were false positives from mailing lists, and the few 
that were genuine spoofed would have easily been caught by spam/malware 
filters anyway.


However a project I am working on, DMARC is highly desired. Designing a 
white-list for known mailing lists is something I want to do.


Honestly I was sort of tempted to try and create my own DMARC validator 
(I was thinking one daemon that does both DKIM and DMARC - for postfix, 
Exim has DKIM native but I only use Exim for submission) that tried to 
sniff Mailman and not enforce it but it looks like it would be very time 
consuming.

Re: Changing the imaps port #

[Michael A. Peters]

Another possible thing, I don't know what the bug is or if it is fixed, 
but few years ago Thunderbird (on CentOS 7) for me refused to connect to 
Port 993 or Port 465 if I used a self-signed certificate even though the 
same certificate worked when using STARTTLS and port 143 and 587. The 
error wasn't an SSL error, it just would act like it was not connecting.


With CA signed certificates it did work on 993 and 465.

On 1/22/19 1:25 AM, Michael A. Peters wrote:
Comcast DNS servers enforce dnssec, AT does not (last I checked). If 
by chance your zone has DNSSEC enabled but mis-configured then it is 
possible the domain name you use for the dovecot server is not resolving 
because of a dnssec validation failure.


I have never heard of comcast or any ISP blocking port 993. That would 
seem to be a violation of net neutrality rules. I use comcast (consumer, 
not business) and it does not block 993 (does block 25 but that it 
should block for dynamic issued addresses)


Look at the domain name used in your e-mail client and make sure it 
actually resolves. If it does not, check to see if DNSSEC validation is 
the issue.


On 1/21/19 8:58 PM, Patrick Mahan wrote:
Yes, I am pretty sure about that.  I originally was connected via AT 
DSL but wanted the fast access of cable modem.  I need permanent IPs 
which required me to contract with Comcast buisness.  Once I switched 
over, I was no longer able to access my imap server, which was as I 
mentioned, stunnel listening on the imaps port and forwarding to 
dovecot listening on the imap port.


I was getting connection refused on my laptop (thunderbird) email 
client when I was not at home.  I validated that it was not because it 
was reaching my email server.  So who ever was rejecting it, I assumed 
it was somewhere inside the comcast network.  Once I switch to a 
non-standard port, I was able to connect again.


Re needing to say ssl = yes, I thought that was implied for imaps?

I can go back to stunnel, just thought it was an unnecessary layer.

Thanks,

Patrick


On Mon, Jan 21, 2019 at 8:46 PM @lbutlr <mailto:krem...@kreme.com>> wrote:


    On 21 Jan 2019, at 20:17, Patrick Mahan mailto:plma...@gmail.com>> wrote:
 > Due to comcast buisness ISP intercepting imaps

    At you sure about that? I've been using comcast business for 7 years
    and the do not block 143, 993 587 or 25. they do block 110, but
    that's fine, I stopped supporting POP around 2001.

    Other than 110, they block DHCP, NETBIOS, SNMP, and ports 445, 520,
    and 1080. They will block port 25 on a individual basis, but I've no
    idea what their criteria is for that.

 > I need to have my clients connect to non-standard port (). 
    Previously I had been using stunnel to receive the imaps connection

    and forward it to the imap port over 127.0.0.1.  But I would like to
    retire stunnel and have my imap clients connect remotely.

    An stunnel or a reverse proxy is the best way to do this, honestly.

    As for why your config isn't working, my only guess is maybe you
    need to specify ssl?

  inet_listener imaps {
       port = 999
       ssl = yes
    }

    ?


    --     If you write the word "monkey" a million times, do you 
start to

    think you're
    Shakespeare? -- Steven Wright

Re: Changing the imaps port #

[Michael A. Peters]

Comcast DNS servers enforce dnssec, AT does not (last I checked). If 
by chance your zone has DNSSEC enabled but mis-configured then it is 
possible the domain name you use for the dovecot server is not resolving 
because of a dnssec validation failure.


I have never heard of comcast or any ISP blocking port 993. That would 
seem to be a violation of net neutrality rules. I use comcast (consumer, 
not business) and it does not block 993 (does block 25 but that it 
should block for dynamic issued addresses)


Look at the domain name used in your e-mail client and make sure it 
actually resolves. If it does not, check to see if DNSSEC validation is 
the issue.


On 1/21/19 8:58 PM, Patrick Mahan wrote:
Yes, I am pretty sure about that.  I originally was connected via AT 
DSL but wanted the fast access of cable modem.  I need permanent IPs 
which required me to contract with Comcast buisness.  Once I switched 
over, I was no longer able to access my imap server, which was as I 
mentioned, stunnel listening on the imaps port and forwarding to dovecot 
listening on the imap port.


I was getting connection refused on my laptop (thunderbird) email client 
when I was not at home.  I validated that it was not because it was 
reaching my email server.  So who ever was rejecting it, I assumed it 
was somewhere inside the comcast network.  Once I switch to a 
non-standard port, I was able to connect again.


Re needing to say ssl = yes, I thought that was implied for imaps?

I can go back to stunnel, just thought it was an unnecessary layer.

Thanks,

Patrick


On Mon, Jan 21, 2019 at 8:46 PM @lbutlr > wrote:


On 21 Jan 2019, at 20:17, Patrick Mahan mailto:plma...@gmail.com>> wrote:
 > Due to comcast buisness ISP intercepting imaps

At you sure about that? I've been using comcast business for 7 years
and the do not block 143, 993 587 or 25. they do block 110, but
that's fine, I stopped supporting POP around 2001.

Other than 110, they block DHCP, NETBIOS, SNMP, and ports 445, 520,
and 1080. They will block port 25 on a individual basis, but I've no
idea what their criteria is for that.

 > I need to have my clients connect to non-standard port (). 
Previously I had been using stunnel to receive the imaps connection

and forward it to the imap port over 127.0.0.1.  But I would like to
retire stunnel and have my imap clients connect remotely.

An stunnel or a reverse proxy is the best way to do this, honestly.

As for why your config isn't working, my only guess is maybe you
need to specify ssl?

  inet_listener imaps {
       port = 999
       ssl = yes
    }

?


-- 
If you write the word "monkey" a million times, do you start to

think you're
Shakespeare? -- Steven Wright

Re: ECDSA client question

[Michael A. Peters]

On 12/16/18 7:52 AM, Tributh via dovecot wrote:



Am 16.12.18 um 12:13 schrieb Michael A. Peters:

Hi, for those who have adopted ECDSA,

Are there still any commonly used IMAPS/POP3S clients that still can not
handle ECDSA certificates?

I know you can set up Dovecot dor dual cert, I am just trying to
determine if there still is a real world need to.


Nearly every client can handle ECDSA, but it depends on the size of the
certificate.
I used years ago ECDSA-384bit certificates, which covered most of the
clients. It came to the point to disable RSA in that time, but than came
Android7.0. This Version can only handle ECDSA-256bit certificates or RSA.

The coverage of Android7.0 is still over 20%. Google reacted fast and
repaired this bug in 7.1, which is still not coming to most of the phones.

Cheers
Torsten



Wow - My phone is running Android 6, I just checked with Dad - his phone 
(Motorola) is running Android 7.0 - the version with the bug.


We don't replace phones just because new versions are available, we 
replace them when they stop working, and when we do we usually get 
refurbished because we hate how much electronic waste is in the world.


I have to admit, the tin foil hat of mine just got an alert.

We know there are unexplained constants in the NIST curves including 
P-256 - what if NSA was partially responsible for this bug (back room 
deal to avoid anti-trust prosecution, similar deal with IBM was made in 
the 70s I believe also involving cryptography) so that Android apps that 
use ECDSA (beyond just the mail client, e.g. chat apps) would use P-256 
for compatibility and are maybe vulnerable to MITM for the key exchange.


I want Ed25519 now.

ECDSA client question

[Michael A. Peters]

Hi, for those who have adopted ECDSA,

Are there still any commonly used IMAPS/POP3S clients that still can not 
handle ECDSA certificates?


I know you can set up Dovecot dor dual cert, I am just trying to 
determine if there still is a real world need to.

Re: Mailing list address harvested for spamming

[Michael A. Peters]

On 12/02/2018 08:42 AM, Hendrik Boom wrote:

On Sun, Dec 02, 2018 at 04:22:52PM +0100, Ralph Seichter wrote:

* Ruben Safir:


On Sun, Dec 02, 2018 at 03:58:53AM +0100, Bernd Petrovitsch wrote:


Let's hope that people who do not know how to use a tool - e.g.
like a hammer - doesn't use that tool in the first place 


that is pretty unrealistic and I don't agree with it anyway.


The tool metaphor is realistic. In my experience (which dates back to
the 1980s), email ist a powerful tool, and people need to learn how to
use it properly, with the appropriate software set. Especially in the
area of technical mailing lists I see no reason to cater to dumb MUA
software.


Especially in a technical mailing list about email software!

-- hendrik



Well netiquette lists are not an RFC. They are some person saying "This 
is others should do things because I think it is best"


But yes, on technical lists more people do follow netiquette, possibly 
because those who have different way of thinking are driven off for 
being different in how their mind works.

Re: Mailing list address harvested for spamming

[Michael A. Peters]

On 12/01/2018 05:49 PM, Ralph Seichter wrote:

* Michael A. Peters:


Netiquette posts are just someone's opinion, and they often don't take
into account the vastly different way different types of minds work.


Mailing list netiquette has been around for decades, for good reasons.
If Joe User's mind "works differently", Joe needs to make the effort to
adapt to existing conventions instead of expecting conventions (and
thereby other people) to change.

-Ralph



That is the opinion of some.

But - I would wager that over 95% of the time when someone hits the 
reply button on a list post, their intent is to reply to the list.


If netiquette is why that sometimes fails, then netiquette does not 
match common usage and is the problem.


I would wager that most people are clueless to how mail headers work, 
not should most people need to.

Re: Mailing list address harvested for spamming

[Michael A. Peters]

On 12/01/2018 05:00 PM, Hendrik Boom wrote:



There's an extensive email etiquette post somewhere on the net
explaining why setting 'reply-to' to the list is a bad idea.

Reply-to is intended for the sender to explain that replies shouldn't
be sent to the obvious sending address, but to another address.
This is essential if, say, the sender is temporarily away from home and s using 
a friend's email service.

It is unfortunate that there are user-agents that do not provide the
reply-to-list' option.  And that there are mailing list programs that
do not provide the proper list-headers to indicate the mailing list
address.



The problem though is that then muscle memory with keyboard shortcuts 
result in reply going to the user instead of list.


Netiquette posts are just someone's opinion, and they often don't take 
into account the vastly different way different types of minds work.


Just as an example, I have a deaf friend who hates bottom posting 
because the way captions always work is equivalent to top posting - new 
content pops up above the old content, so the flow she expects is 
opposite but netiquette nazis scream at her when she top posts.

Re: Mailing list address harvested for spamming

[Michael A. Peters]

On 12/01/2018 04:22 PM, Noel Butler wrote:

On 02/12/2018 10:16, Michael A. Peters wrote:


On 12/01/2018 04:09 PM, Noel Butler wrote:



Which is why it annoys me that some people on mailing lists feel the 
need to reply directly, rather than through mailing list.


Sometimes it is the MUA that is poorly designed that causes this.

I could have sworn I said that, oh yes, I see I did


Also, some lists set the "reply to" with the sender rather than the list.

Also covered (poorly configured)


Further, some user agents have a separate "reply" for replying to list 
instead of original sender but human error results in wrong being 
clicked. That's happened to me - causing me to accidentally reply to 
wrong address.





My apologies, I honestly did not see it but I just looked and it is 
there. Maybe the bracket in parenthesis resulted in my mind mentally 
skipping it or something.

Re: Mailing list address harvested for spamming

[Michael A. Peters]

On 12/01/2018 04:09 PM, Noel Butler wrote:



Which is why it annoys me that some people on mailing lists feel the 
need to reply directly, rather than through mailing list.


Sometimes it is the MUA that is poorly designed that causes this.

Also, some lists set the "reply to" with the sender rather than the list.

Further, some user agents have a separate "reply" for replying to list 
instead of original sender but human error results in wrong being 
clicked. That's happened to me - causing me to accidentally reply to 
wrong address.

Re: DMARC policies

[Michael A. Peters]

On 11/29/2018 11:13 PM, Aki Tuomi wrote:

Hi!

It seems we accidentically had a high amount of subscribers temporarily
disabled due to DMARC on some sender's host. We have now taken actions
to prevent this in the future and all temporarily disabled members have
been restored.

Aki




I've seen that happen on several lists.

I disabled DMARC on my mail servers. I really like the concept but way 
way way too many false positives.


Mostly lists, but also what sometimes happens - primary MX for 
whatever.com is down so mail goes to their backup with then relays it to 
their primary when primary back up, but their backup MX obviously isn't 
in my SPF record and they have things mis-configured causing a DMARC 
trigger.


I like the concept but it seems to have too many problems in implementation.

Re: different TLS protocols on different ports

[Michael A. Peters]

On 11/14/2018 01:46 PM, Joseph Tam wrote:

On Wed, 14 Nov 2018, Aki Tuomi wrote:


I'm providing IMAP+Starttls on port 143 for users with legacy MUA.  So
I've to enable TLS1.0 up to TLS1.3 For IMAPS / port 993 I like to
enable TLS1.2 and TLS1.3 only.

Is this possible with dovecot-2.2.36 / how to setup this?


Not possible I'm afraid.


("Not possible" = challenge!)

Couldn't you run two different instances (with 2 separate run-time
directories), each listening on a different port with their own SSL
configuration?  Or would it clash somewhere?

If only a single running instance of dovecot is required, I guess you
can run dovecot on the localhost interface, and use 2 stunnel proxies.

Joseph Tam 


Honestly that violates the concept of KISS.

Given that TLS 1.2 is now a decade old, do you really need to still 
allow clients not capable of TLS 1.0/1.1 ???


I still do but only allow cipher suites with Forward Secrecy.

I don't run huge mail server, but from quick look at my logs I don't 
even see any clients connecting that aren't TLS 1.2 anymore.


Might be easier to just give a six month notice that clients running TLS 
more than a decade old will no longer be supported.

Re: New install - getting error: "Failed to initialize SSL server context: Couldn't parse DH parameters"

[Michael A. Peters]

try

openssl dhparam -out /usr/local/etc/dovecot/dh.pem 2048

On 11/12/2018 07:28 PM, James Brown wrote:
I’m setting up Dovecot using Homebrew on a new server and am getting 
this when I try to login via IMAP:


Nov 13 14:13:35 auth: Debug: auth client connected (pid=30719)
Nov 13 14:13:35 imap-login: Info: Aborted login (no auth attempts in 0 
secs): user=<>, rip=::1, lip=::1, secured, 
session=
Nov 13 14:18:33 auth: Debug: Loading modules from directory: 
/usr/local/Cellar/dovecot/2.3.2.1/lib/dovecot/auth
Nov 13 14:18:33 auth: Debug: Module loaded: 
/usr/local/Cellar/dovecot/2.3.2.1/lib/dovecot/auth/lib20_auth_var_expand_crypt.so
Nov 13 14:18:33 auth: Debug: Read auth token secret from 
/usr/local/var/run/dovecot/auth-token-secret.dat

Nov 13 14:18:33 auth: Debug: auth client connected (pid=30848)
Nov 13 14:18:33 imap-login: Error: Failed to initialize SSL server 
context: Couldn't parse DH parameters: error:0906D06C:PEM 
routines:PEM_read_bio:no start line: Expecting: DH PARAMETERS: user=<>, 
rip=::1, lip=::1, secured, session=
Nov 13 14:18:33 imap-login: Info: Disconnected: TLS initialization 
failed. (no auth attempts in 0 secs): user=<>, rip=::1, lip=::1, 
secured, session=


I’ve used:

Openssl gendh 2048

And put the output:

-BEGIN DH PARAMETERS-
MIIBCAKCAQEA0IF7kQX32IJFm/5HEVwYf7Be4G9iY86MvLiFLL3wHGqcPT3EMsIv
YSe5XOT0Q7DGXPOZ+DLlJq8KDHxWKNI6j/0ZaRBrF38CWj8Jqxa8pqo9FVSWj45b
JwSLqBSoBIEFWibqSE6L8wlV8xjMsB34xLHduJDNbaBzsooN749CopTkmkuGeXKH
waOEbDzlOq+qHEa4bjx2/e/TnPj0kCrMnfeU4QILo1rJwuN4nY6k7fGwgEDVa2hE
oOrVfJxyuuuiblahblahblahhhXCGsxhlDQO
QmzOhHqPovzbBByO9iR5fu3xbNm9YRxPowIBAg==
-END DH PARAMETERS——

Into a file dh.pem and then added

ssl_dh=/usr/local/etc/dovecot/dh.pem

To my dovecot.conf file.

Reloaded Dovecot but still get the same error.

Any suggestions?

macOS 10.13.6, Dovecot 2.3.2.1

Any suggestions?

Thanks,

James.

Re: OCSP Stapling and Certificate Transparency

[Michael A. Peters]

On 05/01/2018 09:08 AM, Aki Tuomi wrote:



On 01 May 2018 at 19:03 Felipe Gasper < fel...@felipegasper.com
> wrote:


Hi,

For CAs that do not include a signed certificate timestamp in their
newly-issued certificates, does Dovecot support either OCSP stapling
or the Certificate Transparency TLS extension?

If the TLS extension is supported, how does the admin configure the
timestamp for each certificate?

I’m wondering if any MUAs will follow Google’s lead and insist on CT.

Thank you!

-Felipe Gasper
Mississauga, Ontario


Hi!

We are planning to add ocsp stapling support. At least Thunderbird
supports must-staple attribute.
---
Aki Tuomi


Hi, is there any more news on this?

Note I don't *personally* need it, but I provide custom dovecot RPMs for 
CentOS 7 and someone asked how to do it. They want to use a certificate 
that has the "must staple" feature.


(I'm personally more interested in DANE support in clients, which 
dovecot doesn't need to do anything for, that's client specific)

Re: OT: 'lost' emails

[Michael A. Peters]

On 07/20/2018 03:31 AM, Voytek wrote:

I suspect this is mail client issue, but looking for any suggestions:

user with Thunderbird says " I'm losing emails, mail is not in inbox,
but, when I search, that email shows in search result, but, I can't open
the email body" i don't fully understand what he was trying to say, and,
won't be able to look at his PC till Monday.

Looking at inbox's 'cur' directory, I can see the'missing' email amongst
the other 2000 emails in 'cur'

Is there any indexing I should do on the user's email folder, how?

or, is this purely Thunderbird issue, and, I need to re index Thunderbird?

V
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


I'm using 45.8.0 because I experienced weird things with newer (CentOS) 
such as inability to use self-signed certs properly, but I didn't 
experience that issue.


Not sure if that was CentOS 7 issue or Thunderbird, but the newer 
versions did give me trouble.


That issue though sounds like corrupted client database, not sure if 
there is a way to rebuild it but I suspect there is.


I experienced similar issues frequently in evolution, hence why I 
switched to thunderbird.

Re: Bounced message after update

[Michael A. Peters]

okay weird - I read https://wiki2.dovecot.org/DomainLost

I set auth_debug=yes to get a clearer indication if that was my problem.

Tried again and it successfully went through.

On 02/08/2018 05:46 PM, Michael A. Peters wrote:

Hi -

Updated from 2.2.27 to 2.3.0

server is webmail (roundcube)

Sending worked before after update. Now it receives, but trying to send
- this is the bounce in the log

Feb  9 01:37:45 {hostname} postfix/pipe[22891]: 931FD2577:
to=<{user}@{hostname}.{tld}>, relay=dovecot, delay=0.01, delays=0/0/0/0,
dsn=5.3.0, status=bounced (command line usage error. Command output:
lda: Fatal: Invalid -f parameter: Missing domain )
Feb  9 01:37:45 deviant postfix/qmgr[16492]: 931FD2577: removed

{hostname}, {user}, {tld} are substitutions.

Here's my lda config:

protocol lda {
log_path = /home/{hostname}/dovecot-deliver.log
auth_socket_path = /var/run/dovecot/auth-master
postmaster_address = postmaster@{hostname}.{tld}
}

Any suggestions (other than reverting) ?

This worked just before the update.

If it matters, Roundcube 1.3.4

Bounced message after update

[Michael A. Peters]

Hi -

Updated from 2.2.27 to 2.3.0

server is webmail (roundcube)

Sending worked before after update. Now it receives, but trying to send 
- this is the bounce in the log


Feb  9 01:37:45 {hostname} postfix/pipe[22891]: 931FD2577: 
to=<{user}@{hostname}.{tld}>, relay=dovecot, delay=0.01, delays=0/0/0/0, 
dsn=5.3.0, status=bounced (command line usage error. Command output: 
lda: Fatal: Invalid -f parameter: Missing domain )

Feb  9 01:37:45 deviant postfix/qmgr[16492]: 931FD2577: removed

{hostname}, {user}, {tld} are substitutions.

Here's my lda config:

protocol lda {
log_path = /home/{hostname}/dovecot-deliver.log
auth_socket_path = /var/run/dovecot/auth-master
postmaster_address = postmaster@{hostname}.{tld}
}

Any suggestions (other than reverting) ?

This worked just before the update.

If it matters, Roundcube 1.3.4

Dovecot and /dev/rand

[Michael A. Peters]

There's a (2014 I think) patch in dovecot rpm for Red Hat / Fedora 
ecosystem that was last update with 2.2.9 (patch last updated for that 
release)


I want to know if the problem it solves still exists in 2.3.x branch.

The patch is called "dovecot-2.2.9-nodevrand.patch" and is attached.

It allegedly addresses an issue with installation in chroot that does 
not have /dev/random


Red Hat bugzilla 1026790

I am apparently not authorized to see that bug so I don't know much 
about it, but with many code changes in 2.3.0 from 2.2.x I am wondering 
if the alleged issue was solved a different way or if the patch should 
be ported to 2.3.0 when packaged for people who might trigger it.


Thanks.




diff -up dovecot-2.2.9/src/lib-master/master-service.c.fixit dovecot-2.2.9/src/lib-master/master-service.c
--- dovecot-2.2.9/src/lib-master/master-service.c.fixit	2013-11-24 14:37:39.0 +0100
+++ dovecot-2.2.9/src/lib-master/master-service.c	2013-11-27 17:52:48.802843395 +0100
@@ -559,6 +559,11 @@ const char *master_service_get_name(stru
 	return service->name;
 }
 
+const enum master_service_flags master_service_get_flags(struct master_service *service)
+{
+	return service->flags;
+}
+
 void master_service_run(struct master_service *service,
 			master_service_connection_callback_t *callback)
 {
diff -up dovecot-2.2.9/src/lib-master/master-service.h.fixit dovecot-2.2.9/src/lib-master/master-service.h
--- dovecot-2.2.9/src/lib-master/master-service.h.fixit	2013-11-24 14:37:39.0 +0100
+++ dovecot-2.2.9/src/lib-master/master-service.h	2013-11-27 17:53:05.329705614 +0100
@@ -134,6 +134,8 @@ const char *master_service_get_version_s
 /* Returns name of the service, as given in name parameter to _init(). */
 const char *master_service_get_name(struct master_service *service);
 
+const enum master_service_flags master_service_get_flags(struct master_service *service);
+
 /* Start the service. Blocks until finished */
 void master_service_run(struct master_service *service,
 			master_service_connection_callback_t *callback)
diff -up dovecot-2.2.9/src/ssl-params/main.c.fixit dovecot-2.2.9/src/ssl-params/main.c
--- dovecot-2.2.9/src/ssl-params/main.c.fixit	2013-11-24 14:37:39.0 +0100
+++ dovecot-2.2.9/src/ssl-params/main.c	2013-11-27 17:51:06.664694558 +0100
@@ -103,7 +103,10 @@ static void sig_chld(const siginfo_t *si
 	if (waitpid(-1, , WNOHANG) < 0)
 		i_error("waitpid() failed: %m");
 	else if (status != 0)
+	{
 		i_error("child process failed with status %d", status);
+		if(master_service_get_flags(master_service) & MASTER_SERVICE_FLAG_STANDALONE) exit(1);
+	}
 	else {
 		/* params should have been created now. try refreshing. */
 		ssl_params_refresh(param);

Re: Dovecot and Self-signed issue

[Michael A. Peters]

Just to confirm - building thunderbird 45.8.0 worked, it connects just fine.

On 09/26/2017 01:46 AM, Michael A. Peters wrote:

No, no certificate in thunderbird.

Work fine when running CentOS 7.3, laptop that still runs 7.3 works fine.

I'm going to attempt building the CentOS 7.3 thundirbird src.rpm in 7.4
and see if that fixes it, and if it does, file a bug report with rhel.

On 09/26/2017 01:17 AM, Peter Chiochetti wrote:

Hello Micheal,

this reminds me of something, that I experienced in the past. Why
would the server! complain "Unknown CA"? To test inspect the
communication with wireshark and look if the client sends a cert; or:

$ echo "a001 LOGOUT" | openssl s_client -msg -connect your.server:993

and grep for "CertificateRequest".

Do you have a certificate configured in your mailclient Thunderbird
but not in Evolution?

HTH
Peter

Am 2017-09-26 um 00:08 schrieb Michael A. Peters:

Definitely client issue, connecting via evolution works just fine.

So I suppose it is off the the thunderbird list. I like thunderbird
better.

Only plugin I use is dkim validator and when I started thunderbird
w/o extensions - still had same issue.

But I think it is definitely not a dovecot problem.

On 09/25/2017 01:49 PM, Michael A. Peters wrote:

I'm not running any A/V software, and the same version of dovecot on
servers with CA signed certs (komodo) - the client connects to them
just fine.

On 09/25/2017 01:40 PM, Tony wrote:

It does look like a client issue. Do you also have some kind of AV
running? There are some AV software that can sometimes interfere with
mail sessions. See if you might be running into a similar situation:
https://support.mozilla.org/en-US/questions/1066126

Cheers,
--
TC

On 9/25/17 1:27 PM, Michael A. Peters wrote:

I use dovecot on several servers. One of them uses a self-signed
cert,
it's just me.

It worked fine until yesterday when I upgraded my desktop (NOT the
server) to CentOS 7.4

Now thunderbird complains when it starts up, and won't let me confirm
the security exception.

On the server the following error occurs in the log:

Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth
attempts in 1 secs): user=<>,
rip=2600:1010:b064:f260:e83e:562d:2316:18df,
lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept()
failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
unknown ca: SSL alert number 48,
session=<u7agQAlasK8mABAQsGTyYOg+Vi0jFhjf>

I believe this is a client issue, as it worked just fine in CentOS
7.3
client, but I am hoping this has been seen and fixed before

Re: Dovecot and Self-signed issue

[Michael A. Peters]

No, no certificate in thunderbird.

Work fine when running CentOS 7.3, laptop that still runs 7.3 works fine.

I'm going to attempt building the CentOS 7.3 thundirbird src.rpm in 7.4 
and see if that fixes it, and if it does, file a bug report with rhel.


On 09/26/2017 01:17 AM, Peter Chiochetti wrote:

Hello Micheal,

this reminds me of something, that I experienced in the past. Why would 
the server! complain "Unknown CA"? To test inspect the communication 
with wireshark and look if the client sends a cert; or:


$ echo "a001 LOGOUT" | openssl s_client -msg -connect your.server:993

and grep for "CertificateRequest".

Do you have a certificate configured in your mailclient Thunderbird but 
not in Evolution?


HTH
Peter

Am 2017-09-26 um 00:08 schrieb Michael A. Peters:

Definitely client issue, connecting via evolution works just fine.

So I suppose it is off the the thunderbird list. I like thunderbird 
better.


Only plugin I use is dkim validator and when I started thunderbird w/o 
extensions - still had same issue.


But I think it is definitely not a dovecot problem.

On 09/25/2017 01:49 PM, Michael A. Peters wrote:
I'm not running any A/V software, and the same version of dovecot on 
servers with CA signed certs (komodo) - the client connects to them 
just fine.


On 09/25/2017 01:40 PM, Tony wrote:

It does look like a client issue. Do you also have some kind of AV
running? There are some AV software that can sometimes interfere with
mail sessions. See if you might be running into a similar situation:
https://support.mozilla.org/en-US/questions/1066126

Cheers,
--
TC

On 9/25/17 1:27 PM, Michael A. Peters wrote:

I use dovecot on several servers. One of them uses a self-signed cert,
it's just me.

It worked fine until yesterday when I upgraded my desktop (NOT the
server) to CentOS 7.4

Now thunderbird complains when it starts up, and won't let me confirm
the security exception.

On the server the following error occurs in the log:

Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth
attempts in 1 secs): user=<>,
rip=2600:1010:b064:f260:e83e:562d:2316:18df,
lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept()
failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
unknown ca: SSL alert number 48,
session=<u7agQAlasK8mABAQsGTyYOg+Vi0jFhjf>

I believe this is a client issue, as it worked just fine in CentOS 7.3
client, but I am hoping this has been seen and fixed before

Re: Dovecot and Self-signed issue

[Michael A. Peters]

Definitely client issue, connecting via evolution works just fine.

So I suppose it is off the the thunderbird list. I like thunderbird better.

Only plugin I use is dkim validator and when I started thunderbird w/o 
extensions - still had same issue.


But I think it is definitely not a dovecot problem.

On 09/25/2017 01:49 PM, Michael A. Peters wrote:
I'm not running any A/V software, and the same version of dovecot on 
servers with CA signed certs (komodo) - the client connects to them just 
fine.


On 09/25/2017 01:40 PM, Tony wrote:

It does look like a client issue. Do you also have some kind of AV
running? There are some AV software that can sometimes interfere with
mail sessions. See if you might be running into a similar situation:
https://support.mozilla.org/en-US/questions/1066126

Cheers,
--
TC

On 9/25/17 1:27 PM, Michael A. Peters wrote:

I use dovecot on several servers. One of them uses a self-signed cert,
it's just me.

It worked fine until yesterday when I upgraded my desktop (NOT the
server) to CentOS 7.4

Now thunderbird complains when it starts up, and won't let me confirm
the security exception.

On the server the following error occurs in the log:

Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth
attempts in 1 secs): user=<>,
rip=2600:1010:b064:f260:e83e:562d:2316:18df,
lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept()
failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
unknown ca: SSL alert number 48,
session=<u7agQAlasK8mABAQsGTyYOg+Vi0jFhjf>

I believe this is a client issue, as it worked just fine in CentOS 7.3
client, but I am hoping this has been seen and fixed before.

Re: Dovecot and Self-signed issue

[Michael A. Peters]

I'm not running any A/V software, and the same version of dovecot on 
servers with CA signed certs (komodo) - the client connects to them just 
fine.


On 09/25/2017 01:40 PM, Tony wrote:

It does look like a client issue. Do you also have some kind of AV
running? There are some AV software that can sometimes interfere with
mail sessions. See if you might be running into a similar situation:
https://support.mozilla.org/en-US/questions/1066126

Cheers,
--
TC

On 9/25/17 1:27 PM, Michael A. Peters wrote:

I use dovecot on several servers. One of them uses a self-signed cert,
it's just me.

It worked fine until yesterday when I upgraded my desktop (NOT the
server) to CentOS 7.4

Now thunderbird complains when it starts up, and won't let me confirm
the security exception.

On the server the following error occurs in the log:

Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth
attempts in 1 secs): user=<>,
rip=2600:1010:b064:f260:e83e:562d:2316:18df,
lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept()
failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
unknown ca: SSL alert number 48,
session=<u7agQAlasK8mABAQsGTyYOg+Vi0jFhjf>

I believe this is a client issue, as it worked just fine in CentOS 7.3
client, but I am hoping this has been seen and fixed before.

Dovecot and Self-signed issue

[Michael A. Peters]

I use dovecot on several servers. One of them uses a self-signed cert, 
it's just me.


It worked fine until yesterday when I upgraded my desktop (NOT the 
server) to CentOS 7.4


Now thunderbird complains when it starts up, and won't let me confirm 
the security exception.


On the server the following error occurs in the log:

Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth 
attempts in 1 secs): user=<>, 
rip=2600:1010:b064:f260:e83e:562d:2316:18df, 
lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept() 
failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown 
ca: SSL alert number 48, session=


I believe this is a client issue, as it worked just fine in CentOS 7.3 
client, but I am hoping this has been seen and fixed before.

Re: Problem with Let's Encrypt Certificate

[Michael A. Peters]

On 02/20/2017 01:32 AM, chaouche yacine wrote:

What is the motivation behind using a new pair of keys and CSR ?



Every now and then, a bug in the OpenSSL API is found that leaked the 
private key under certain conditions.


By replacing the private key once a year with a new one, you are at 
lower risk of having a private key that is exposed by such a bug even if 
the bug isn't published and only a few know about it.


heartbleed was one such bug, DROWN was another.

Obviously when a bug of that type is found and reported and your server 
was potentially vulnerable you change right away - but when you use the 
same private key for a long time, you risk a scenario where the NSA knew 
about it, you stopped using the protocol or cipher before it became 
public, it becomes public several years later but you aren't worried 
because you haven't run that protocol or cipher suite in quite some time 
- yet the NSA already has your private key from years ago.


That's why I always generate new private key once a year.

It just reduces exploitable exposure in the unlikely but possible 
scenario that the private key was compromised and I did not know it.


That's also why I only allow ciphers that use forward secrecy for 
connections from mail clients.

Re: Problem with Let's Encrypt Certificate

[Michael A. Peters]

On 02/19/2017 05:39 AM, KT Walrus wrote:

That's one of the reasons I don't like Let's Encrypt, with one year certs it is 
easier to look at the certs and see what is going to expire in the coming month 
needing a new private key.


I use dehydrated (with Cloudflare DNS challenges) and as far as I know, it 
seems to generate a new private key every time.


Yeah that would be a problem for me because I implement DANE.

Every time I change the private key -

A) I have to make a TLSA record for the new key
B) I have to let that key propagate in DNS while the old cert is active. 
I use 8 hour TTL for DNS records, so that takes 16 hours (twice the TTL)

C) Then I can switch to the new key / cert in the server.

I use TLSA records for everything TLS, even dovecot - despite the fact I 
am not aware of any IMAP clients that will validate via DANE - because 
it is the right thing to do and sooner or later IMAP clients will 
support DNSSEC and DANE.


Having to do that every three months for every service I run, I really 
do not see what real world benefit I or my users would gain.

Re: Problem with Let's Encrypt Certificate

[Michael A. Peters]

On 02/18/2017 10:24 PM, Robert L Mathews wrote:

On 2/17/17 1:38 PM, chaouche yacine wrote:


Seems wrong to me too, Robert. If you put your private key inside
your certificate, won't it be sent to the client along with it ?


No; any SSL software that uses the file will extract the parts it needs
from it and convert them to its internal format for future use. It never
literally sends the file contents anywhere.

It's common and often recommended for a PEM file to contain everything
needed; see, for example, the bottom section of:

 https://www.digicert.com/ssl-support/pem-ssl-creation.htm

Doing this avoids the key and certificate files getting out of sync later.



I don't use Let's Encrypt but to avoid them getting out of sync, I 
simply put a time stamp in the filename, e.g.


/etc/pki/tls/private/deviant.email-20160427.key
/etc/pki/tls/certs/deviant.email-20160427.crt

I never re-use a private key, when a cert expires I always generate a 
new private key with a new CSR.


That's one of the reasons I don't like Let's Encrypt, with one year 
certs it is easier to look at the certs and see what is going to expire 
in the coming month needing a new private key.


Let's Encrypt does 3 month certs and re-uses the private key when it 
generates a new cert.


I'm sure it probably could be scripted to use a new private key every 
time but then I have to have to update the TLSA record frequently (and 
you have to have the new fingerprint TLSA record in DNS before you start 
using it) and that would be a hassle.


I'm sure it probably could also be scripted to use a new private key 
every fourth time, too.


But for me its just easier to have certs that last a year and I can 
easily visually see what is going to need my action.

Re: Dovecot and MariaDB/MySQL

[Michael A. Peters]

On 01/10/2017 11:50 PM, Aki Tuomi wrote:



Hi!

Try using doveadm pw -S SSHA256 for generating the password. The salt is
included in the password hash.

Aki



Thank you! Found the doveadm-pw man page, think I'm good from here.

Dovecot and MariaDB/MySQL

[Michael A. Peters]

Howdy -

For most of my dovecot servers, they are small and I just use unix accounts.

However I am going to be running a new server for more general users, 
webmail (probably roundcube but I'm hacking roundcube quite a bit, 
enough that I'm calling it squarepeg instead so users familiar with 
roundcube will know it is quite different) and it will use MariaDB for 
account management.


I already have it working, following the instructions at 
https://www.linode.com/docs/email/postfix/email-with-postfix-dovecot-and-mysql-on-centos-5/ 
- those instructions also work in CentOS 7 with the latest Dovecot - but 
there is something that really bothers me.


It makes no provision for salting the password before the crypt function.

What I would like to do is when creating a new account, use /dev/urandom 
to generate a random salt for the account that is stuck in the database 
along with the account and used when validating the password.


That way in the event of a SQL injection attack that dumps the database 
- yes it is still bad, but 20 accounts that have the same password will 
have radically different hashes and thus won't be a clue that they are 
the same, the blackhat that gets the database dump would have to 
generate a rainbow table for each unique salt.


I've looked at at least a dozen different Dovecot / MariaDB howto guides 
and none of the ones I have looked at supported any kind of individual 
salting of the user passwords.


Can someone point me to a guide that does?

I don't mind keeping the salt in the database, I just want to be able to 
have a different salt for each account.


Thank you

Re: v2.2.27 released --- libressl

[Michael A. Peters]

On 12/06/2016 11:35 AM, Ruga wrote:

Results from the application of the following patch from Aki.

perl -i -ple 's|^(\s*#include \s*)$|$1\n\t#if 
OPENSSL_VERSION_NUMBER == 0x2000L\n\t#define OPENSSL_VERSION_NUMBER 
0x10001000L\n\t#endif|' configure.ac;



I use a different method of patching but similar in end result concept, 
but I too have an error - I haven't looked at why yet, that's on my todo 
list, just saw the build fails.


I might see if I can get it to build tonight. My personal use of dovecot 
is rather limited, three low volume servers, so I can't be of much use 
in finding problems that are not compile related, but I'll try to figure 
out the LibreSSL needed build tweaking tonight.

Re: Good email client to use with Dovecot?

[Michael A. Peters]

On 11/16/2016 11:48 PM, Steve Litt wrote:

Hi all,

When I use an email client, its purpose is as a window into my Dovecot
IMAP, and as a mechanism to reply to and send emails. I don't do
filtering or calendaring on my email client (filtering via procmail
direct to Dovecot).

What email clients are all of you using to look at your IMAP email?

Thanks,

SteveT


Thunderbird on the Desktop and K9 on Android and roundcube for webmail.

Re: dovecot pre-install issue

[Michael A. Peters]

On 11/16/2016 01:06 AM, soumi...@iitk.ac.in wrote:

Hello all,

I am going for a dovecot director based setup (2 director+ 2 imap), more
imap servers will be added later  depending on demand/load. Presently I
have 12000+ dovecot users with Maildir quota varying from 1 GB to 20GB.
(peak hour IOPS 5+)

I am having 2 options in choosing dovecot version.

1) Old stable release. I.e RHEL, with prebuilt binary. This will be
having less trouble in managing. Why RHEL still using version 2.2.10.

2) Latest release with best features and lesser known bugs. I.e CentOS7
with with latest compiled version. I have to be more involved if a bug
is found.

I will prefer a less admin work after the setup, with all/most features
working.

If you have a recent similar setup/dovecot gurus, Pl. suggest.

With thanks & regards,



I only run small server but I use CentOS and build the most recent 
myself and do not have many issues.


CentOS 7 dovecot btw is same as RHEL 7 dovecot as far as I know.

Re: v2.2.26.0 released

[Michael A. Peters]

Indeed, which is why I use it.

But it also is in the minority which is why I find it acceptable for 
FLOSS projects like dovecot to elect to only un-officially support 
LibreSSL via a community maintained patch.


One of the reasons why OpenSSL was forked is because they were trying to 
support so many platforms that it made the code a real mess. Don't want 
the same to happen to another project because of it.


Especially with places like github that make it easy for members of the 
community to create and maintain such a patch, it may be the best option 
if the project itself doesn't have someone who can officially maintain 
LibreSSL support.


On 11/02/2016 05:08 AM, Ruga wrote:

libressl is a leaner and safer openssl

Sent from ProtonMail Mobile


On Wed, Nov 2, 2016 at 12:39 PM, Michael A. Peters <'mpet...@domblogger.net'> 
wrote:
IMHO it would be acceptable to have a LibreSSL patch that is maintained
by the people who want it.

It's free software, and that kind of is the point of Open Source.

On 11/02/2016 04:36 AM, Michael A. Peters wrote:

They have stated they are going to remain API compatible with 1.0.1h (or
g, forget which they forked) - their new stuff is outside of libcrypto.

On 11/02/2016 04:25 AM, Aki Tuomi wrote:

It does work today, I am just bit worried that it will keep on breaking
with libressl as they evolve their API. I would personally like to avoid
more ifdef hell if possible...

Aki


On 02.11.2016 13:22, Michael A. Peters wrote:

Standard way to fix it (on the LibreSSL page) is to check for
LIBRESSL_VERSION_NUMBER - e.g. the patch attached which I think
catches them all where needed. Note the word think.

It certainly appears to be working anyway with it.

On 11/02/2016 04:07 AM, Aki Tuomi wrote:

After doing some testing by myself, I noticed that libressl, for some
unknown reason, defines

#define OPENSSL_VERSION_NUMBER 0x2000L

No idea why they decided to advertise that they are OpenSSL v2.0.0. A
local fix, if you need one, is to use

#if OPENSSL_VERSION_NUMBER == 0x2000L
#define OPENSSL_VERSION_NUMBER 0x1000100L
#endif

in dcrypt-openssl.c after includes.

Aki


On 02.11.2016 12:39, Aki Tuomi wrote:

Hi!

Those are used if

#if OPENSSL_VERSION_NUMBER >= 0x1010L

So (your) libressl is providing this define. We compile our code using
GCC and CLANG regularly, with OpenSSL v1.0.x which is the currently
officially supported one.

Aki


On 02.11.2016 12:34, Ruga wrote:

dovecot 2.2.26.0 uses the following functions, which are not
available on libressl 2.4.3:

HMAC_CTX_new
HMAC_CTX_free
EVP_PKEY_get0_EC_KEY
EVP_PKEY_get0_RSA
OBJ_length
EVP_MD_CTX_new
EVP_MD_CTX_free

The result of calling a non-existent function is a runtime error,
and we do not want that on production servers.







There are additional problems. I recommend compiling with clang-llvm
3.9.0
to see them all.







 Original Message 
Subject: Re: v2.2.26.0 released
Local Time: 1 November 2016 7:30 PM
UTC Time: 1 November 2016 18:30
From: aki.tu...@dovecot.fi
To: Dovecot Mailing List <dovecot@dovecot.org>, Ruga
<r...@protonmail.com>

OpenSSL v1.0.1 is enough.

Aki


On November 1, 2016 at 7:46 PM Ruga <r...@protonmail.com> wrote:


Hello,

We cannot upgrade from 2.2.24, because we use libressl and the newer
dovecot versions demand openssl v1.1.

Please add the new library requirement to the INSTALL file.

All the best.









 Original Message 
Subject: v2.2.26.0 released
Local Time: 28 October 2016 6:51 PM
UTC Time: 28 October 2016 16:51
From: t...@iki.fi
To: dovecot-n...@dovecot.org, Dovecot Mailing List
<dovecot@dovecot.org>

http://dovecot.org/releases/2.2/dovecot-2.2.26.0.tar.gz
http://dovecot.org/releases/2.2/dovecot-2.2.26.0.tar.gz.sig

v2.2.26 had a couple of nasty bugs left in it, so here's a fixup
release. The version number is also a little bit weird, but had to
be done this way (although 2.2.26.0.1 could have been another
possibility).

- Fixed some compiling issues.
- auth: Fixed assert-crash when using NTLM or SKEY mechanisms and
multiple passdbs.
- auth: Fixed crash when exporting to auth-worker passdb extra
fields
that had empty values.
- dsync: Fixed assert-crash in dsync_brain_sync_mailbox_deinit

>

Re: v2.2.26.0 released

[Michael A. Peters]

IMHO it would be acceptable to have a LibreSSL patch that is maintained 
by the people who want it.


It's free software, and that kind of is the point of Open Source.

On 11/02/2016 04:36 AM, Michael A. Peters wrote:

They have stated they are going to remain API compatible with 1.0.1h (or
g, forget which they forked) - their new stuff is outside of libcrypto.

On 11/02/2016 04:25 AM, Aki Tuomi wrote:

It does work today, I am just bit worried that it will keep on breaking
with libressl as they evolve their API. I would personally like to avoid
more ifdef hell if possible...

Aki


On 02.11.2016 13:22, Michael A. Peters wrote:

Standard way to fix it (on the LibreSSL page) is to check for
LIBRESSL_VERSION_NUMBER - e.g. the patch attached which I think
catches them all where needed. Note the word think.

It certainly appears to be working anyway with it.

On 11/02/2016 04:07 AM, Aki Tuomi wrote:

After doing some testing by myself, I noticed that libressl, for some
unknown reason, defines

#define OPENSSL_VERSION_NUMBER0x2000L

No idea why they decided to advertise that they are OpenSSL v2.0.0. A
local fix, if you need one, is to use

#if OPENSSL_VERSION_NUMBER == 0x2000L
#define OPENSSL_VERSION_NUMBER 0x1000100L
#endif

in dcrypt-openssl.c after includes.

Aki


On 02.11.2016 12:39, Aki Tuomi wrote:

Hi!

Those are used if

#if OPENSSL_VERSION_NUMBER >= 0x1010L

So (your) libressl is providing this define. We compile our code using
GCC and CLANG regularly, with OpenSSL v1.0.x which is the currently
officially supported one.

Aki


On 02.11.2016 12:34, Ruga wrote:

dovecot 2.2.26.0 uses the following functions, which are not
available on libressl 2.4.3:

HMAC_CTX_new
HMAC_CTX_free
EVP_PKEY_get0_EC_KEY
EVP_PKEY_get0_RSA
OBJ_length
EVP_MD_CTX_new
EVP_MD_CTX_free

The result of calling a non-existent function is a runtime error,
and we do not want that on production servers.







There are additional problems. I recommend compiling with clang-llvm
3.9.0
to see them all.







 Original Message 
Subject: Re: v2.2.26.0 released
Local Time: 1 November 2016 7:30 PM
UTC Time: 1 November 2016 18:30
From: aki.tu...@dovecot.fi
To: Dovecot Mailing List <dovecot@dovecot.org>, Ruga
<r...@protonmail.com>

OpenSSL v1.0.1 is enough.

Aki


On November 1, 2016 at 7:46 PM Ruga <r...@protonmail.com> wrote:


Hello,

We cannot upgrade from 2.2.24, because we use libressl and the newer
dovecot versions demand openssl v1.1.

Please add the new library requirement to the INSTALL file.

All the best.









 Original Message 
Subject: v2.2.26.0 released
Local Time: 28 October 2016 6:51 PM
UTC Time: 28 October 2016 16:51
From: t...@iki.fi
To: dovecot-n...@dovecot.org, Dovecot Mailing List
<dovecot@dovecot.org>

http://dovecot.org/releases/2.2/dovecot-2.2.26.0.tar.gz
http://dovecot.org/releases/2.2/dovecot-2.2.26.0.tar.gz.sig

v2.2.26 had a couple of nasty bugs left in it, so here's a fixup
release. The version number is also a little bit weird, but had to
be done this way (although 2.2.26.0.1 could have been another
possibility).

- Fixed some compiling issues.
- auth: Fixed assert-crash when using NTLM or SKEY mechanisms and
multiple passdbs.
- auth: Fixed crash when exporting to auth-worker passdb extra
fields
that had empty values.
- dsync: Fixed assert-crash in dsync_brain_sync_mailbox_deinit

Re: v2.2.26.0 released

[Michael A. Peters]

They have stated they are going to remain API compatible with 1.0.1h (or 
g, forget which they forked) - their new stuff is outside of libcrypto.


On 11/02/2016 04:25 AM, Aki Tuomi wrote:

It does work today, I am just bit worried that it will keep on breaking
with libressl as they evolve their API. I would personally like to avoid
more ifdef hell if possible...

Aki


On 02.11.2016 13:22, Michael A. Peters wrote:

Standard way to fix it (on the LibreSSL page) is to check for
LIBRESSL_VERSION_NUMBER - e.g. the patch attached which I think
catches them all where needed. Note the word think.

It certainly appears to be working anyway with it.

On 11/02/2016 04:07 AM, Aki Tuomi wrote:

After doing some testing by myself, I noticed that libressl, for some
unknown reason, defines

#define OPENSSL_VERSION_NUMBER0x2000L

No idea why they decided to advertise that they are OpenSSL v2.0.0. A
local fix, if you need one, is to use

#if OPENSSL_VERSION_NUMBER == 0x2000L
#define OPENSSL_VERSION_NUMBER 0x1000100L
#endif

in dcrypt-openssl.c after includes.

Aki


On 02.11.2016 12:39, Aki Tuomi wrote:

Hi!

Those are used if

#if OPENSSL_VERSION_NUMBER >= 0x1010L

So (your) libressl is providing this define. We compile our code using
GCC and CLANG regularly, with OpenSSL v1.0.x which is the currently
officially supported one.

Aki


On 02.11.2016 12:34, Ruga wrote:

dovecot 2.2.26.0 uses the following functions, which are not
available on libressl 2.4.3:

HMAC_CTX_new
HMAC_CTX_free
EVP_PKEY_get0_EC_KEY
EVP_PKEY_get0_RSA
OBJ_length
EVP_MD_CTX_new
EVP_MD_CTX_free

The result of calling a non-existent function is a runtime error,
and we do not want that on production servers.







There are additional problems. I recommend compiling with clang-llvm
3.9.0
to see them all.







 Original Message 
Subject: Re: v2.2.26.0 released
Local Time: 1 November 2016 7:30 PM
UTC Time: 1 November 2016 18:30
From: aki.tu...@dovecot.fi
To: Dovecot Mailing List <dovecot@dovecot.org>, Ruga
<r...@protonmail.com>

OpenSSL v1.0.1 is enough.

Aki


On November 1, 2016 at 7:46 PM Ruga <r...@protonmail.com> wrote:


Hello,

We cannot upgrade from 2.2.24, because we use libressl and the newer
dovecot versions demand openssl v1.1.

Please add the new library requirement to the INSTALL file.

All the best.









 Original Message 
Subject: v2.2.26.0 released
Local Time: 28 October 2016 6:51 PM
UTC Time: 28 October 2016 16:51
From: t...@iki.fi
To: dovecot-n...@dovecot.org, Dovecot Mailing List
<dovecot@dovecot.org>

http://dovecot.org/releases/2.2/dovecot-2.2.26.0.tar.gz
http://dovecot.org/releases/2.2/dovecot-2.2.26.0.tar.gz.sig

v2.2.26 had a couple of nasty bugs left in it, so here's a fixup
release. The version number is also a little bit weird, but had to
be done this way (although 2.2.26.0.1 could have been another
possibility).

- Fixed some compiling issues.
- auth: Fixed assert-crash when using NTLM or SKEY mechanisms and
multiple passdbs.
- auth: Fixed crash when exporting to auth-worker passdb extra fields
that had empty values.
- dsync: Fixed assert-crash in dsync_brain_sync_mailbox_deinit

Re: v2.2.26.0 released

[Michael A. Peters]

Standard way to fix it (on the LibreSSL page) is to check for 
LIBRESSL_VERSION_NUMBER - e.g. the patch attached which I think catches 
them all where needed. Note the word think.


It certainly appears to be working anyway with it.

On 11/02/2016 04:07 AM, Aki Tuomi wrote:

After doing some testing by myself, I noticed that libressl, for some
unknown reason, defines

#define OPENSSL_VERSION_NUMBER0x2000L

No idea why they decided to advertise that they are OpenSSL v2.0.0. A
local fix, if you need one, is to use

#if OPENSSL_VERSION_NUMBER == 0x2000L
#define OPENSSL_VERSION_NUMBER 0x1000100L
#endif

in dcrypt-openssl.c after includes.

Aki


On 02.11.2016 12:39, Aki Tuomi wrote:

Hi!

Those are used if

#if OPENSSL_VERSION_NUMBER >= 0x1010L

So (your) libressl is providing this define. We compile our code using
GCC and CLANG regularly, with OpenSSL v1.0.x which is the currently
officially supported one.

Aki


On 02.11.2016 12:34, Ruga wrote:

dovecot 2.2.26.0 uses the following functions, which are not
available on libressl 2.4.3:

HMAC_CTX_new
HMAC_CTX_free
EVP_PKEY_get0_EC_KEY
EVP_PKEY_get0_RSA
OBJ_length
EVP_MD_CTX_new
EVP_MD_CTX_free

The result of calling a non-existent function is a runtime error,
and we do not want that on production servers.







There are additional problems. I recommend compiling with clang-llvm
3.9.0
to see them all.







 Original Message 
Subject: Re: v2.2.26.0 released
Local Time: 1 November 2016 7:30 PM
UTC Time: 1 November 2016 18:30
From: aki.tu...@dovecot.fi
To: Dovecot Mailing List , Ruga


OpenSSL v1.0.1 is enough.

Aki


On November 1, 2016 at 7:46 PM Ruga  wrote:


Hello,

We cannot upgrade from 2.2.24, because we use libressl and the newer
dovecot versions demand openssl v1.1.

Please add the new library requirement to the INSTALL file.

All the best.









 Original Message 
Subject: v2.2.26.0 released
Local Time: 28 October 2016 6:51 PM
UTC Time: 28 October 2016 16:51
From: t...@iki.fi
To: dovecot-n...@dovecot.org, Dovecot Mailing List


http://dovecot.org/releases/2.2/dovecot-2.2.26.0.tar.gz
http://dovecot.org/releases/2.2/dovecot-2.2.26.0.tar.gz.sig

v2.2.26 had a couple of nasty bugs left in it, so here's a fixup
release. The version number is also a little bit weird, but had to
be done this way (although 2.2.26.0.1 could have been another
possibility).

- Fixed some compiling issues.
- auth: Fixed assert-crash when using NTLM or SKEY mechanisms and
multiple passdbs.
- auth: Fixed crash when exporting to auth-worker passdb extra fields
that had empty values.
- dsync: Fixed assert-crash in dsync_brain_sync_mailbox_deinit


diff -ur dovecot-2.2.26.0.orig/src/lib-dcrypt/dcrypt-openssl.c dovecot-2.2.26.0/src/lib-dcrypt/dcrypt-openssl.c
--- dovecot-2.2.26.0.orig/src/lib-dcrypt/dcrypt-openssl.c	2016-10-27 05:26:28.0 -0700
+++ dovecot-2.2.26.0/src/lib-dcrypt/dcrypt-openssl.c	2016-11-02 04:12:32.854546200 -0700
@@ -67,7 +67,7 @@
   2key algo oid1symmetric algo namesalthash algoroundsE(RSA = i2d_PrivateKey, EC=Private Point)key id
 **/
 
-#if OPENSSL_VERSION_NUMBER < 0x1010L
+#if OPENSSL_VERSION_NUMBER < 0x1010L || defined (LIBRESSL_VERSION_NUMBER)
 #define EVP_PKEY_get0_EC_KEY(x) x->pkey.ec
 #define EVP_PKEY_get0_RSA(x) x->pkey.rsa
 #define OBJ_length(o) ((o)->length)
@@ -90,7 +90,7 @@
 struct dcrypt_context_hmac {
 	pool_t pool;
 	const EVP_MD *md;
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined (LIBRESSL_VERSION_NUMBER)
 	HMAC_CTX *ctx;
 #else
 	HMAC_CTX ctx;
@@ -427,7 +427,7 @@
 void dcrypt_openssl_ctx_hmac_destroy(struct dcrypt_context_hmac **ctx)
 {
 	pool_t pool = (*ctx)->pool;
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined (LIBRESSL_VERSION_NUMBER)
 	if ((*ctx)->ctx) HMAC_CTX_free((*ctx)->ctx);
 #else
 	HMAC_cleanup(&((*ctx)->ctx));
@@ -470,7 +470,7 @@
 {
 	int ec;
 	i_assert(ctx->md != NULL);
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined (LIBRESSL_VERSION_NUMBER)
 	ctx->ctx = HMAC_CTX_new();
 	if (ctx->ctx == NULL) return dcrypt_openssl_error(error_r);
 	ec = HMAC_Init_ex(ctx->ctx, ctx->key, ctx->klen, ctx->md, NULL);
@@ -484,7 +484,7 @@
 bool dcrypt_openssl_ctx_hmac_update(struct dcrypt_context_hmac *ctx, const unsigned char *data, size_t data_len, const char **error_r)
 {
 	int ec;
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined (LIBRESSL_VERSION_NUMBER)
 	ec = HMAC_Update(ctx->ctx, data, data_len);
 #else
 	ec = HMAC_Update(&(ctx->ctx), data, data_len);
@@ -498,7 +498,7 @@
 	int ec;
 	unsigned char buf[HMAC_MAX_MD_CBLOCK];
 	unsigned int outl;
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined (LIBRESSL_VERSION_NUMBER)
 	ec = HMAC_Final(ctx->ctx, buf, );
 	

Re: v2.2.26.0 released

[Michael A. Peters]

I can confirm that LibreSSL 2.4.3 works just fine for building 2.2.26.0

On 11/01/2016 09:25 PM, Reuben Farrelly wrote:

I don't believe that is the case.

I have 2.2.26.0 and -git building and running on multiple systems now
(two of which are Gentoo boxes) with LibreSSL-2.5 - and these systems do
not have OpenSSL installed.  Are you running an old version of LibreSSL
perhaps?

I *think* LibreSSL-2.4 was OK as well.

Reuben


On 2/11/2016 4:46 AM, Ruga wrote:

Hello,

We cannot upgrade from 2.2.24, because we use libressl and the newer
dovecot versions demand openssl v1.1.

Please add the new library requirement to the INSTALL file.

All the best.

Re: v2.2.26 released

[Michael A. Peters]

On 10/27/2016 09:43 AM, Aki Tuomi wrote:




*snip*



Aki


You are right, it was supposed to be there. Unfortunately it isn't.

We'll see what can be done.

Aki


I maintain an RPM of the 2.2.x branch.

Should I wait with pushing the update?

Re: v2.2.26 release candidate released

[Michael A. Peters]

On 10/21/2016 02:25 AM, Michael A. Peters wrote:

On 10/19/2016 02:01 PM, Timo Sirainen wrote:

http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz
http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz.sig

There are quite a lot of changes since v2.2.25. Please try out this RC
so we can get a good and stable v2.2.26 out.


I am not able to test it but I can verify that it compiles on CentOS
against LibreSSL 2.4.3


On CentOS 7

Re: v2.2.26 release candidate released

[Michael A. Peters]

On 10/19/2016 02:01 PM, Timo Sirainen wrote:

http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz
http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz.sig

There are quite a lot of changes since v2.2.25. Please try out this RC so we 
can get a good and stable v2.2.26 out.


I am not able to test it but I can verify that it compiles on CentOS 
against LibreSSL 2.4.3

Re: Dovecot 2.2.25 fails on SSL

[Michael A. Peters]

On 09/02/2016 12:50 PM, Joseph Tam wrote:

Aki Tuomi wrote:


ldd /usr/local/Dovecot-2.2.25/lib/dovecot/libdcrypt_openssl.so
linux-gate.so.1 =>  (0x00dca000)
libcrypto.so.1.0.0 => not found
...


Well, then it leaves only option of using /etc/ld.so.conf
so basically add your libssl location there.


You can also affect where shared libraries are loaded using the
LD_LIBRARY_PATH environment variable.  Try adding

LD_LIBARY_PATH=/location/of/libdir; export LD_LIBARY_PATH

to your service boot scripts.


would an rpath solve the problem?

I believe chrpath command can probably be used to set the rpath if it 
isn't set at compile time.

Re: Dovecot password policy

[Michael A. Peters]

On 08/05/2016 08:41 AM, Robert Blayzor wrote:

Is there a way to configure Dovecot to perhaps filter/enforce which passwords 
are accepted before authenticating?

Ie:  Reject immediately (without a database lookup) if password is not X 
characters in length?

?



Not sure what the benefit would be, other than helping automated bots 
figure out your minimum password length based upon the response time.

Re: Dovecot 2.2.25 test failure

[Michael A. Peters]

On 08/04/2016 10:31 AM, aki.tu...@dovecot.fi wrote:



On August 4, 2016 at 7:38 PM aki.tu...@dovecot.fi wrote:




On August 4, 2016 at 4:53 PM "Michael A. Peters" <mpet...@domblogger.net> wrote:


On 08/04/2016 06:50 AM, aki.tu...@dovecot.fi wrote:



On August 4, 2016 at 4:19 PM "Michael A. Peters" <mpet...@domblogger.net> wrote:


On 08/04/2016 06:13 AM, Aki Tuomi wrote:



On 04.08.2016 16:11, Michael A. Peters wrote:

Operating system - 64 bit CentOS 7
gcc-4.8.5-4.el7.x86_64

Building against LibreSSL which has been fine for other releases, but
it is a crypto test that is fails.

Tried with LibreSSL 2.4.2 and 2.3.6 - both the build completes but
fails the make check

Dovecot 2.2.24 passes make check on both.

This is where it fails:

Making check in lib-dcrypt
make[2]: Entering directory
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt'
for bin in test-crypto test-stream; do \
  if ! /bin/sh ../../run-test.sh ../.. ./$bin; then exit 1; fi; \
done
../../run-test.sh: line 21: 22369 Segmentation fault  (core
dumped) valgrind -q --trace-children=yes --leak-check=full
--suppressions="$supp_path" --log-file=test.out.$$ $*
==22369== Invalid read of size 8
==22369==at 0x113A47: dcrypt_ctx_sym_create (dcrypt.c:61)
==22369==by 0x119194: test_cipher_test_vectors (test-crypto.c:60)
==22369==by 0x1196F0: test_run_funcs (test-common.c:354)
==22369==by 0x119FC0: test_run (test-common.c:404)
==22369==by 0x113461: main (test-crypto.c:554)
==22369==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==22369==
==22369==
==22369== Process terminating with default action of signal 11 (SIGSEGV)
==22369==  Access not within mapped region at address 0x8
==22369==at 0x113A47: dcrypt_ctx_sym_create (dcrypt.c:61)
==22369==by 0x119194: test_cipher_test_vectors (test-crypto.c:60)
==22369==by 0x1196F0: test_run_funcs (test-common.c:354)
==22369==by 0x119FC0: test_run (test-common.c:404)
==22369==by 0x113461: main (test-crypto.c:554)
==22369==  If you believe this happened as a result of a stack
==22369==  overflow in your program's main thread (unlikely but
==22369==  possible), you can try to increase the size of the
==22369==  main thread stack using the --main-stacksize= flag.
==22369==  The main thread stack size used in this run was 8388608.
Failed to run: ./test-crypto
make[2]: *** [check-test] Error 1
make[2]: Leaving directory
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src'
make: *** [check-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.Il5fdU (%check)

Thanks for suggestions.


Hi!

can you please provide stack trace with gdb?

gdb ./test-crypto
r
bt full

Aki



[alice@pern lib-dcrypt]$ gdb ./test-crypto
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt/test-crypto...done.
(gdb) r
Starting program:
/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt/./test-crypto

Program received signal SIGSEGV, Segmentation fault.
0xfa47 in dcrypt_ctx_sym_create (algorithm=0x5557c12e
"AES-128-CBC", mode=DCRYPT_MODE_ENCRYPT, ctx_r=0x7fffdf30,
error_r=0x0) at dcrypt.c:61
61  return dcrypt_vfs->ctx_sym_create(algorithm, mode, ctx_r, 
error_r);
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-106.el7_2.6.x86_64
(gdb) bt full
#0  0xfa47 in dcrypt_ctx_sym_create
(algorithm=0x5557c12e "AES-128-CBC", mode=DCRYPT_MODE_ENCRYPT,
ctx_r=0x7fffdf30, error_r=0x0) at dcrypt.c:61
No locals.


Can you p dcrypt_vfs?

Aki



(gdb) p dcrypt_vfs
$1 = (struct dcrypt_vfs *) 0x0
(gdb)


Af. This problem is because there is no openssl backend built with dcrypt, as 
we don't have libressl support officially. I'll add code that checks that if 
dcrypt initialization fails, the tests are skipped.

Aki


Fixed in 
https://github.com/dovecot/core/commit/b91d91633bf40f5fc8f962cc72faea8b867a181a

Aki



Thank you. I'll test it today.

I understand the limited resource issue and the large number of TLS 
implementations that exist.


For what its worth, I've been running Dovecot built against LibreSSL for 
almost a year now without any issues. Thank you.

Re: Dovecot 2.2.25 test failure

[Michael A. Peters]

On 08/04/2016 06:50 AM, aki.tu...@dovecot.fi wrote:



On August 4, 2016 at 4:19 PM "Michael A. Peters" <mpet...@domblogger.net> wrote:


On 08/04/2016 06:13 AM, Aki Tuomi wrote:



On 04.08.2016 16:11, Michael A. Peters wrote:

Operating system - 64 bit CentOS 7
gcc-4.8.5-4.el7.x86_64

Building against LibreSSL which has been fine for other releases, but
it is a crypto test that is fails.

Tried with LibreSSL 2.4.2 and 2.3.6 - both the build completes but
fails the make check

Dovecot 2.2.24 passes make check on both.

This is where it fails:

Making check in lib-dcrypt
make[2]: Entering directory
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt'
for bin in test-crypto test-stream; do \
  if ! /bin/sh ../../run-test.sh ../.. ./$bin; then exit 1; fi; \
done
../../run-test.sh: line 21: 22369 Segmentation fault  (core
dumped) valgrind -q --trace-children=yes --leak-check=full
--suppressions="$supp_path" --log-file=test.out.$$ $*
==22369== Invalid read of size 8
==22369==at 0x113A47: dcrypt_ctx_sym_create (dcrypt.c:61)
==22369==by 0x119194: test_cipher_test_vectors (test-crypto.c:60)
==22369==by 0x1196F0: test_run_funcs (test-common.c:354)
==22369==by 0x119FC0: test_run (test-common.c:404)
==22369==by 0x113461: main (test-crypto.c:554)
==22369==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==22369==
==22369==
==22369== Process terminating with default action of signal 11 (SIGSEGV)
==22369==  Access not within mapped region at address 0x8
==22369==at 0x113A47: dcrypt_ctx_sym_create (dcrypt.c:61)
==22369==by 0x119194: test_cipher_test_vectors (test-crypto.c:60)
==22369==by 0x1196F0: test_run_funcs (test-common.c:354)
==22369==by 0x119FC0: test_run (test-common.c:404)
==22369==by 0x113461: main (test-crypto.c:554)
==22369==  If you believe this happened as a result of a stack
==22369==  overflow in your program's main thread (unlikely but
==22369==  possible), you can try to increase the size of the
==22369==  main thread stack using the --main-stacksize= flag.
==22369==  The main thread stack size used in this run was 8388608.
Failed to run: ./test-crypto
make[2]: *** [check-test] Error 1
make[2]: Leaving directory
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src'
make: *** [check-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.Il5fdU (%check)

Thanks for suggestions.


Hi!

can you please provide stack trace with gdb?

gdb ./test-crypto
r
bt full

Aki



[alice@pern lib-dcrypt]$ gdb ./test-crypto
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt/test-crypto...done.
(gdb) r
Starting program:
/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt/./test-crypto

Program received signal SIGSEGV, Segmentation fault.
0xfa47 in dcrypt_ctx_sym_create (algorithm=0x5557c12e
"AES-128-CBC", mode=DCRYPT_MODE_ENCRYPT, ctx_r=0x7fffdf30,
error_r=0x0) at dcrypt.c:61
61  return dcrypt_vfs->ctx_sym_create(algorithm, mode, ctx_r, 
error_r);
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-106.el7_2.6.x86_64
(gdb) bt full
#0  0xfa47 in dcrypt_ctx_sym_create
(algorithm=0x5557c12e "AES-128-CBC", mode=DCRYPT_MODE_ENCRYPT,
ctx_r=0x7fffdf30, error_r=0x0) at dcrypt.c:61
No locals.


Can you p dcrypt_vfs?

Aki



(gdb) p dcrypt_vfs
$1 = (struct dcrypt_vfs *) 0x0
(gdb)

Re: Dovecot 2.2.25 test failure

[Michael A. Peters]

On 08/04/2016 06:13 AM, Aki Tuomi wrote:



On 04.08.2016 16:11, Michael A. Peters wrote:

Operating system - 64 bit CentOS 7
gcc-4.8.5-4.el7.x86_64

Building against LibreSSL which has been fine for other releases, but
it is a crypto test that is fails.

Tried with LibreSSL 2.4.2 and 2.3.6 - both the build completes but
fails the make check

Dovecot 2.2.24 passes make check on both.

This is where it fails:

Making check in lib-dcrypt
make[2]: Entering directory
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt'
for bin in test-crypto test-stream; do \
  if ! /bin/sh ../../run-test.sh ../.. ./$bin; then exit 1; fi; \
done
../../run-test.sh: line 21: 22369 Segmentation fault  (core
dumped) valgrind -q --trace-children=yes --leak-check=full
--suppressions="$supp_path" --log-file=test.out.$$ $*
==22369== Invalid read of size 8
==22369==at 0x113A47: dcrypt_ctx_sym_create (dcrypt.c:61)
==22369==by 0x119194: test_cipher_test_vectors (test-crypto.c:60)
==22369==by 0x1196F0: test_run_funcs (test-common.c:354)
==22369==by 0x119FC0: test_run (test-common.c:404)
==22369==by 0x113461: main (test-crypto.c:554)
==22369==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==22369==
==22369==
==22369== Process terminating with default action of signal 11 (SIGSEGV)
==22369==  Access not within mapped region at address 0x8
==22369==at 0x113A47: dcrypt_ctx_sym_create (dcrypt.c:61)
==22369==by 0x119194: test_cipher_test_vectors (test-crypto.c:60)
==22369==by 0x1196F0: test_run_funcs (test-common.c:354)
==22369==by 0x119FC0: test_run (test-common.c:404)
==22369==by 0x113461: main (test-crypto.c:554)
==22369==  If you believe this happened as a result of a stack
==22369==  overflow in your program's main thread (unlikely but
==22369==  possible), you can try to increase the size of the
==22369==  main thread stack using the --main-stacksize= flag.
==22369==  The main thread stack size used in this run was 8388608.
Failed to run: ./test-crypto
make[2]: *** [check-test] Error 1
make[2]: Leaving directory
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src'
make: *** [check-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.Il5fdU (%check)

Thanks for suggestions.


Hi!

can you please provide stack trace with gdb?

gdb ./test-crypto
r
bt full

Aki



[alice@pern lib-dcrypt]$ gdb ./test-crypto
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from 
/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt/test-crypto...done.

(gdb) r
Starting program: 
/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt/./test-crypto


Program received signal SIGSEGV, Segmentation fault.
0xfa47 in dcrypt_ctx_sym_create (algorithm=0x5557c12e 
"AES-128-CBC", mode=DCRYPT_MODE_ENCRYPT, ctx_r=0x7fffdf30, 
error_r=0x0) at dcrypt.c:61

61  return dcrypt_vfs->ctx_sym_create(algorithm, mode, ctx_r, 
error_r);
Missing separate debuginfos, use: debuginfo-install 
glibc-2.17-106.el7_2.6.x86_64

(gdb) bt full
#0  0xfa47 in dcrypt_ctx_sym_create 
(algorithm=0x5557c12e "AES-128-CBC", mode=DCRYPT_MODE_ENCRYPT, 
ctx_r=0x7fffdf30, error_r=0x0) at dcrypt.c:61

No locals.
#1  0x55565195 in test_cipher_test_vectors () at test-crypto.c:60
ctx = 0x57a6911f
i = 0
vectors = {{key = 0x5557dd48 
"2b7e151628aed2a6abf7158809cf4f3c", iv = 0x5557dd70 
"000102030405060708090a0b0c0d0e0f", pt = 0x5557dd98 
"6bc1bee22e409f96e93d7e117393172a",
ct = 0x5557ddc0 "7649abac8119b246cee98e9b12e9197d"}, 
{key = 0x5557dd48 "2b7e151628aed2a6abf7158809cf4f3c", iv = 
0x5557dde8 "7649ABAC8119B246CEE98E9B12E9197D",
pt = 0x5557de10 "ae2d8a571e03ac9c9eb76fac45af8e51", ct 
= 0x5557de38 "5086cb9b507219ee95db113a917678b2"}}

key = 0x5578e0f0
iv = 0x5578e158
pt = 0x5578e1c0
ct = 0x5578e228
res_enc = 0x5578e290
res_dec = 0x5578e308
#2  0x555656f1 in test_run_funcs 
(test_functions=test_functions@entry=0x5578b020 
) at test-common.c:354

_data_stack_cur_id = 2
i = 0
#3  0x55565fc1 in test_run (test_functions=0x5578b020 
) at test-

Dovecot 2.2.25 test failure

[Michael A. Peters]

Operating system - 64 bit CentOS 7
gcc-4.8.5-4.el7.x86_64

Building against LibreSSL which has been fine for other releases, but it 
is a crypto test that is fails.


Tried with LibreSSL 2.4.2 and 2.3.6 - both the build completes but fails 
the make check


Dovecot 2.2.24 passes make check on both.

This is where it fails:

Making check in lib-dcrypt
make[2]: Entering directory 
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt'

for bin in test-crypto test-stream; do \
  if ! /bin/sh ../../run-test.sh ../.. ./$bin; then exit 1; fi; \
done
../../run-test.sh: line 21: 22369 Segmentation fault  (core dumped) 
valgrind -q --trace-children=yes --leak-check=full 
--suppressions="$supp_path" --log-file=test.out.$$ $*

==22369== Invalid read of size 8
==22369==at 0x113A47: dcrypt_ctx_sym_create (dcrypt.c:61)
==22369==by 0x119194: test_cipher_test_vectors (test-crypto.c:60)
==22369==by 0x1196F0: test_run_funcs (test-common.c:354)
==22369==by 0x119FC0: test_run (test-common.c:404)
==22369==by 0x113461: main (test-crypto.c:554)
==22369==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==22369==
==22369==
==22369== Process terminating with default action of signal 11 (SIGSEGV)
==22369==  Access not within mapped region at address 0x8
==22369==at 0x113A47: dcrypt_ctx_sym_create (dcrypt.c:61)
==22369==by 0x119194: test_cipher_test_vectors (test-crypto.c:60)
==22369==by 0x1196F0: test_run_funcs (test-common.c:354)
==22369==by 0x119FC0: test_run (test-common.c:404)
==22369==by 0x113461: main (test-crypto.c:554)
==22369==  If you believe this happened as a result of a stack
==22369==  overflow in your program's main thread (unlikely but
==22369==  possible), you can try to increase the size of the
==22369==  main thread stack using the --main-stacksize= flag.
==22369==  The main thread stack size used in this run was 8388608.
Failed to run: ./test-crypto
make[2]: *** [check-test] Error 1
make[2]: Leaving directory 
`/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src/lib-dcrypt'

make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/alice/rpmbuild/BUILD/dovecot-2.2.25/src'
make: *** [check-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.Il5fdU (%check)

Thanks for suggestions.