From simo at redhat.com  Wed Apr  3 13:21:52 2019
From: simo at redhat.com (Simo Sorce)
Date: Wed, 03 Apr 2019 13:21:52 -0400
Subject: Rules of engagement for cyrus-sasl contributions
In-Reply-To: <07f666f0-e7a5-9fd0-8ef0-19c1a0c7c5c4@fastmail.com>
References: <0b2b02660b67d5968d66b7f780405b803a72db37.camel@redhat.com>
 <07f666f0-e7a5-9fd0-8ef0-19c1a0c7c5c4@fastmail.com>
Message-ID: <9afeb6a0ccd8c3025faa45ebb52350e0adafe237.camel@redhat.com>

Thanks Ken,
I posted another PR and noticed that travis is not able to show results
on new PRs.

I know that I had to change one of my projects to allow GitHub Oauuth
integration. This comment from another user with the same issue
explains how to fix it: 
https://github.com/travis-ci/travis-ci/issues/9440#issuecomment-378707440

That said, I see there are no tests run in travis, only a build of
sources. Is there any interest in adding at least some minimal testing
via something like sample-server/sample-client ?

Simo.

On Fri, 2019-03-29 at 10:31 -0400, Ken Murchison wrote:
> PRs are the best way to contribute.  I will try to find some time to 
> work through the existing PRs.
> 
> 
> On 3/29/19 10:11 AM, Simo Sorce wrote:
> > Hello list,
> > as of recently I am working as the Red Hat maintainer for the cyrus-
> > sasl package taking over from Jakub Jelen.
> > 
> > I am writing to ask what is the correct way to engage with regard to
> > patch review and getting work done in general. I have submitted a few
> > PRs to the github tree over the last few months but I've seen no
> > reaction so I am wondering if I need to ping any individual
> > specifically or need to drop a message here, or anything else.
> > 
> > I am planning to write some more patches, for example we would like to
> > move away from any custom cryptography implementation in our packages
> > and I found DES, RC4 and MD5 algorithms implemented in the package.
> > I would like to replace them with simple calls to the OpenSSL EVP
> > interface but it is not clear to me that is is ok, and how to deal with
> > other platforms I do not have access to (like Mac OS X).
> > 
> > Any guidance ?
> > 
> > Thanks,
> > Simo.
> > 

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc



From flashl at cox.net  Sun Apr  7 22:24:51 2019
From: flashl at cox.net (Flash)
Date: Sun, 7 Apr 2019 22:24:51 -0400 (EDT)
Subject: [No Subject]
Message-ID: <1232323090.9884.1554690291088@myemail.cox.net>

unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20190407/e8ff1e59/attachment.html>

From philipp.gesang at intra2net.com  Tue Apr 16 03:03:12 2019
From: philipp.gesang at intra2net.com (Philipp Gesang)
Date: Tue, 16 Apr 2019 09:03:12 +0200
Subject: double free in digest-md5
Message-ID: <20190416070312.GC10409@drift.m.i2n>

Hi,

this is an issue I originally raised on the mutt-users list [0]
where it was suggested that I seek assistance here. The MUA
crashes when sending email over a digest-md5 authenticated
connection. This happens in a call to sasl_dispose() that
indirectly frees some handle that had been freed earlier while
authenticating.

Backtraces:

--8<-- free 1 ----------------------------------------------->8--

#0  free_rc4 (text=text at entry=0x21d3460) at digestmd5.c:1227
#1  0x00007f1fa8416b92 in make_client_response (text=text at entry=0x21d3460, 
    params=params at entry=0x21d3200, oparams=oparams at entry=0x21d18f0) at digestmd5.c:3613
#2  0x00007f1fa8417039 in digestmd5_client_mech_step2 (oparams=<optimized out>, 
    clientoutlen=<optimized out>, clientout=<optimized out>, prompt_need=<optimized out>, 
    serverinlen=<optimized out>, serverin=<optimized out>, params=0x21d3200, 
    ctext=<optimized out>) at digestmd5.c:4364
#3  digestmd5_client_mech_step (conn_context=<optimized out>, params=0x21d3200, 
    serverin=<optimized out>, serverinlen=<optimized out>, prompt_need=<optimized out>, 
    clientout=<optimized out>, clientoutlen=<optimized out>, oparams=<optimized out>)
    at digestmd5.c:4558
#4  0x00007f1fa7e6a471 in sasl_client_step (conn=0x21d1080, serverin=<optimized out>, 
    serverinlen=<optimized out>, prompt_need=prompt_need at entry=0x7fffc8656330, 
    clientout=clientout at entry=0x7fffc8656340, clientoutlen=clientoutlen at entry=0x7fffc865631c)
    at client.c:922
#5  0x0000000000492c05 in smtp_auth_sasl (conn=conn at entry=0x210f810, mechlist=<optimized out>)
    at smtp.c:635
#6  0x000000000049339d in smtp_auth (conn=0x210f810) at smtp.c:549
#7  smtp_open (conn=0x210f810) at smtp.c:503
#8  mutt_smtp_send (from=0x210ce70, to=0x210c890, cc=0x0, bcc=0x0, 
    msgfile=msgfile at entry=0x7fffc8657570 "/tmp/mutt-drift-2428-105237-294724449650828126", 
    eightbit=1) at smtp.c:311
#9  0x0000000000464a45 in send_message (msg=<optimized out>, msg=<optimized out>) at send.c:1030
#10 ci_send_message (flags=<optimized out>, flags at entry=0, msg=<optimized out>, msg at entry=0x0, 
    tempfile=tempfile at entry=0x0, ctx=0x1f44270, cur=<optimized out>, cur at entry=0x0) at send.c:1936
#11 0x000000000042201e in mutt_index_menu () at curs_main.c:2161
#12 0x0000000000409253 in main (argc=1, argv=0x7fffc865abe8, environ=<optimized out>)
    at main.c:1274

--8<-- free 2 ----------------------------------------------->8--

#0  free_rc4 (text=0x21d3460) at digestmd5.c:1227
#1  0x00007f1fa8413420 in digestmd5_common_mech_dispose (conn_context=0x21d3460, utils=0x21d32d0)
    at digestmd5.c:1610
#2  0x00007f1fa7e696f8 in client_dispose (pconn=0x21d1080) at client.c:337
#3  0x00007f1fa7e6c414 in sasl_dispose (pconn=0x21693a0) at common.c:849
#4  0x00000000004987c0 in mutt_sasl_conn_close (conn=0x210f810) at mutt_sasl.c:496
#5  0x00000000004952a3 in mutt_socket_close (conn=conn at entry=0x210f810) at mutt_socket.c:85
#6  0x000000000049395a in mutt_smtp_send (from=<optimized out>, to=0x210c890, cc=0x0, bcc=0x0, 
    msgfile=msgfile at entry=0x7fffc8657570 "/tmp/mutt-drift-2428-105237-294724449650828126", 
    eightbit=<optimized out>) at smtp.c:357
#7  0x0000000000464a45 in send_message (msg=<optimized out>, msg=<optimized out>) at send.c:1030
#8  ci_send_message (flags=<optimized out>, flags at entry=0, msg=<optimized out>, msg at entry=0x0, 
    tempfile=tempfile at entry=0x0, ctx=0x1f44270, cur=<optimized out>, cur at entry=0x0) at send.c:1936
#9  0x000000000042201e in mutt_index_menu () at curs_main.c:2161
#10 0x0000000000409253 in main (argc=1, argv=0x7fffc865abe8, environ=<optimized out>)
    at main.c:1274

--8<--------------------------------------------------------->8--

AFAICT mutt?s smtp client code follows the steps layed out in
sample/client.c. Is there a precaution to be taken by the caller
of sasl_client_step() and sasl_dispose() to guard against
accidentally triggering free_rc4() twice?

I?ve tested both 2.1.26 and 2.1.27, the issue is present in both.
FWIW the client authenticates against a postfix built against
cyrus-sasl 2.1.23. Let me know if you need more information.

Thanks,
Philipp

[0] http://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20190415/000824.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20190416/931c3a1d/attachment.sig>

From simo at redhat.com  Tue Apr 16 10:23:37 2019
From: simo at redhat.com (Simo Sorce)
Date: Tue, 16 Apr 2019 10:23:37 -0400
Subject: double free in digest-md5
In-Reply-To: <20190416070312.GC10409@drift.m.i2n>
References: <20190416070312.GC10409@drift.m.i2n>
Message-ID: <f449d358ad46a8e2f2cfb4eea0c523e3b12a5b81.camel@redhat.com>

Hi Philipp,
I created PR #562 which should handle this issue, would be nice if you
could try it out and confirm it resolve the crashes for you.

Simo.

On Tue, 2019-04-16 at 09:03 +0200, Philipp Gesang wrote:
> Hi,
> 
> this is an issue I originally raised on the mutt-users list [0]
> where it was suggested that I seek assistance here. The MUA
> crashes when sending email over a digest-md5 authenticated
> connection. This happens in a call to sasl_dispose() that
> indirectly frees some handle that had been freed earlier while
> authenticating.
> 
> Backtraces:
> 
> --8<-- free 1 ----------------------------------------------->8--
> 
> #0  free_rc4 (text=text at entry=0x21d3460) at digestmd5.c:1227
> #1  0x00007f1fa8416b92 in make_client_response (text=text at entry=0x21d3460, 
>     params=params at entry=0x21d3200, oparams=oparams at entry=0x21d18f0) at digestmd5.c:3613
> #2  0x00007f1fa8417039 in digestmd5_client_mech_step2 (oparams=<optimized out>, 
>     clientoutlen=<optimized out>, clientout=<optimized out>, prompt_need=<optimized out>, 
>     serverinlen=<optimized out>, serverin=<optimized out>, params=0x21d3200, 
>     ctext=<optimized out>) at digestmd5.c:4364
> #3  digestmd5_client_mech_step (conn_context=<optimized out>, params=0x21d3200, 
>     serverin=<optimized out>, serverinlen=<optimized out>, prompt_need=<optimized out>, 
>     clientout=<optimized out>, clientoutlen=<optimized out>, oparams=<optimized out>)
>     at digestmd5.c:4558
> #4  0x00007f1fa7e6a471 in sasl_client_step (conn=0x21d1080, serverin=<optimized out>, 
>     serverinlen=<optimized out>, prompt_need=prompt_need at entry=0x7fffc8656330, 
>     clientout=clientout at entry=0x7fffc8656340, clientoutlen=clientoutlen at entry=0x7fffc865631c)
>     at client.c:922
> #5  0x0000000000492c05 in smtp_auth_sasl (conn=conn at entry=0x210f810, mechlist=<optimized out>)
>     at smtp.c:635
> #6  0x000000000049339d in smtp_auth (conn=0x210f810) at smtp.c:549
> #7  smtp_open (conn=0x210f810) at smtp.c:503
> #8  mutt_smtp_send (from=0x210ce70, to=0x210c890, cc=0x0, bcc=0x0, 
>     msgfile=msgfile at entry=0x7fffc8657570 "/tmp/mutt-drift-2428-105237-294724449650828126", 
>     eightbit=1) at smtp.c:311
> #9  0x0000000000464a45 in send_message (msg=<optimized out>, msg=<optimized out>) at send.c:1030
> #10 ci_send_message (flags=<optimized out>, flags at entry=0, msg=<optimized out>, msg at entry=0x0, 
>     tempfile=tempfile at entry=0x0, ctx=0x1f44270, cur=<optimized out>, cur at entry=0x0) at send.c:1936
> #11 0x000000000042201e in mutt_index_menu () at curs_main.c:2161
> #12 0x0000000000409253 in main (argc=1, argv=0x7fffc865abe8, environ=<optimized out>)
>     at main.c:1274
> 
> --8<-- free 2 ----------------------------------------------->8--
> 
> #0  free_rc4 (text=0x21d3460) at digestmd5.c:1227
> #1  0x00007f1fa8413420 in digestmd5_common_mech_dispose (conn_context=0x21d3460, utils=0x21d32d0)
>     at digestmd5.c:1610
> #2  0x00007f1fa7e696f8 in client_dispose (pconn=0x21d1080) at client.c:337
> #3  0x00007f1fa7e6c414 in sasl_dispose (pconn=0x21693a0) at common.c:849
> #4  0x00000000004987c0 in mutt_sasl_conn_close (conn=0x210f810) at mutt_sasl.c:496
> #5  0x00000000004952a3 in mutt_socket_close (conn=conn at entry=0x210f810) at mutt_socket.c:85
> #6  0x000000000049395a in mutt_smtp_send (from=<optimized out>, to=0x210c890, cc=0x0, bcc=0x0, 
>     msgfile=msgfile at entry=0x7fffc8657570 "/tmp/mutt-drift-2428-105237-294724449650828126", 
>     eightbit=<optimized out>) at smtp.c:357
> #7  0x0000000000464a45 in send_message (msg=<optimized out>, msg=<optimized out>) at send.c:1030
> #8  ci_send_message (flags=<optimized out>, flags at entry=0, msg=<optimized out>, msg at entry=0x0, 
>     tempfile=tempfile at entry=0x0, ctx=0x1f44270, cur=<optimized out>, cur at entry=0x0) at send.c:1936
> #9  0x000000000042201e in mutt_index_menu () at curs_main.c:2161
> #10 0x0000000000409253 in main (argc=1, argv=0x7fffc865abe8, environ=<optimized out>)
>     at main.c:1274
> 
> --8<--------------------------------------------------------->8--
> 
> AFAICT mutt?s smtp client code follows the steps layed out in
> sample/client.c. Is there a precaution to be taken by the caller
> of sasl_client_step() and sasl_dispose() to guard against
> accidentally triggering free_rc4() twice?
> 
> I?ve tested both 2.1.26 and 2.1.27, the issue is present in both.
> FWIW the client authenticates against a postfix built against
> cyrus-sasl 2.1.23. Let me know if you need more information.
> 
> Thanks,
> Philipp
> 
> [0] http://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20190415/000824.html
> 

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc



From philipp.gesang at intra2net.com  Wed Apr 17 04:01:31 2019
From: philipp.gesang at intra2net.com (Philipp Gesang)
Date: Wed, 17 Apr 2019 10:01:31 +0200
Subject: double free in digest-md5
In-Reply-To: <f449d358ad46a8e2f2cfb4eea0c523e3b12a5b81.camel@redhat.com>
References: <20190416070312.GC10409@drift.m.i2n>
 <f449d358ad46a8e2f2cfb4eea0c523e3b12a5b81.camel@redhat.com>
Message-ID: <20190417080131.GA428603@drift.m.i2n>

Hi Simo,

-<| Quoting Simo Sorce <simo at redhat.com>, on Tuesday, 2019-04-16 10:23:37 AM |>-
> I created PR #562 which should handle this issue, would be nice if you
> could try it out and confirm it resolve the crashes for you.

tried it against 2.1.27 and mutt is no longer crashing.

Thank you for the quick fix!
Philipp

> On Tue, 2019-04-16 at 09:03 +0200, Philipp Gesang wrote:
> > Hi,
> > 
> > this is an issue I originally raised on the mutt-users list [0]
> > where it was suggested that I seek assistance here. The MUA
> > crashes when sending email over a digest-md5 authenticated
> > connection. This happens in a call to sasl_dispose() that
> > indirectly frees some handle that had been freed earlier while
> > authenticating.
> > 
> > Backtraces:
> > 
> > --8<-- free 1 ----------------------------------------------->8--
> > 
> > #0  free_rc4 (text=text at entry=0x21d3460) at digestmd5.c:1227
> > #1  0x00007f1fa8416b92 in make_client_response (text=text at entry=0x21d3460, 
> >     params=params at entry=0x21d3200, oparams=oparams at entry=0x21d18f0) at digestmd5.c:3613
> > #2  0x00007f1fa8417039 in digestmd5_client_mech_step2 (oparams=<optimized out>, 
> >     clientoutlen=<optimized out>, clientout=<optimized out>, prompt_need=<optimized out>, 
> >     serverinlen=<optimized out>, serverin=<optimized out>, params=0x21d3200, 
> >     ctext=<optimized out>) at digestmd5.c:4364
> > #3  digestmd5_client_mech_step (conn_context=<optimized out>, params=0x21d3200, 
> >     serverin=<optimized out>, serverinlen=<optimized out>, prompt_need=<optimized out>, 
> >     clientout=<optimized out>, clientoutlen=<optimized out>, oparams=<optimized out>)
> >     at digestmd5.c:4558
> > #4  0x00007f1fa7e6a471 in sasl_client_step (conn=0x21d1080, serverin=<optimized out>, 
> >     serverinlen=<optimized out>, prompt_need=prompt_need at entry=0x7fffc8656330, 
> >     clientout=clientout at entry=0x7fffc8656340, clientoutlen=clientoutlen at entry=0x7fffc865631c)
> >     at client.c:922
> > #5  0x0000000000492c05 in smtp_auth_sasl (conn=conn at entry=0x210f810, mechlist=<optimized out>)
> >     at smtp.c:635
> > #6  0x000000000049339d in smtp_auth (conn=0x210f810) at smtp.c:549
> > #7  smtp_open (conn=0x210f810) at smtp.c:503
> > #8  mutt_smtp_send (from=0x210ce70, to=0x210c890, cc=0x0, bcc=0x0, 
> >     msgfile=msgfile at entry=0x7fffc8657570 "/tmp/mutt-drift-2428-105237-294724449650828126", 
> >     eightbit=1) at smtp.c:311
> > #9  0x0000000000464a45 in send_message (msg=<optimized out>, msg=<optimized out>) at send.c:1030
> > #10 ci_send_message (flags=<optimized out>, flags at entry=0, msg=<optimized out>, msg at entry=0x0, 
> >     tempfile=tempfile at entry=0x0, ctx=0x1f44270, cur=<optimized out>, cur at entry=0x0) at send.c:1936
> > #11 0x000000000042201e in mutt_index_menu () at curs_main.c:2161
> > #12 0x0000000000409253 in main (argc=1, argv=0x7fffc865abe8, environ=<optimized out>)
> >     at main.c:1274
> > 
> > --8<-- free 2 ----------------------------------------------->8--
> > 
> > #0  free_rc4 (text=0x21d3460) at digestmd5.c:1227
> > #1  0x00007f1fa8413420 in digestmd5_common_mech_dispose (conn_context=0x21d3460, utils=0x21d32d0)
> >     at digestmd5.c:1610
> > #2  0x00007f1fa7e696f8 in client_dispose (pconn=0x21d1080) at client.c:337
> > #3  0x00007f1fa7e6c414 in sasl_dispose (pconn=0x21693a0) at common.c:849
> > #4  0x00000000004987c0 in mutt_sasl_conn_close (conn=0x210f810) at mutt_sasl.c:496
> > #5  0x00000000004952a3 in mutt_socket_close (conn=conn at entry=0x210f810) at mutt_socket.c:85
> > #6  0x000000000049395a in mutt_smtp_send (from=<optimized out>, to=0x210c890, cc=0x0, bcc=0x0, 
> >     msgfile=msgfile at entry=0x7fffc8657570 "/tmp/mutt-drift-2428-105237-294724449650828126", 
> >     eightbit=<optimized out>) at smtp.c:357
> > #7  0x0000000000464a45 in send_message (msg=<optimized out>, msg=<optimized out>) at send.c:1030
> > #8  ci_send_message (flags=<optimized out>, flags at entry=0, msg=<optimized out>, msg at entry=0x0, 
> >     tempfile=tempfile at entry=0x0, ctx=0x1f44270, cur=<optimized out>, cur at entry=0x0) at send.c:1936
> > #9  0x000000000042201e in mutt_index_menu () at curs_main.c:2161
> > #10 0x0000000000409253 in main (argc=1, argv=0x7fffc865abe8, environ=<optimized out>)
> >     at main.c:1274
> > 
> > --8<--------------------------------------------------------->8--
> > 
> > AFAICT mutt?s smtp client code follows the steps layed out in
> > sample/client.c. Is there a precaution to be taken by the caller
> > of sasl_client_step() and sasl_dispose() to guard against
> > accidentally triggering free_rc4() twice?
> > 
> > I?ve tested both 2.1.26 and 2.1.27, the issue is present in both.
> > FWIW the client authenticates against a postfix built against
> > cyrus-sasl 2.1.23. Let me know if you need more information.
> > 
> > Thanks,
> > Philipp
> > 
> > [0] http://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20190415/000824.html
> > 
> 
> -- 
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20190417/cac049c2/attachment.sig>

From aixtools at felt.demon.nl  Wed Apr 17 13:46:02 2019
From: aixtools at felt.demon.nl (Michael)
Date: Wed, 17 Apr 2019 19:46:02 +0200
Subject: man pages included in distribution - next time around?
Message-ID: <556b4415-f0f0-fffd-858b-3a37908ccae6@felt.demon.nl>

Hi.

Not sure what the dependencies are, but it would be nice if the man
pages could also be part of the standard distribution. I'll continue
looking (or try to generate them on a different platform). Was quite sad
to see that all the man pages are 0 bytes.

warning: missing documentation dependencies. man pages will be empty

Michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20190417/92221632/attachment.sig>

From quanah at symas.com  Wed Apr 17 14:21:21 2019
From: quanah at symas.com (Quanah Gibson-Mount)
Date: Wed, 17 Apr 2019 11:21:21 -0700
Subject: man pages included in distribution - next time around?
In-Reply-To: <556b4415-f0f0-fffd-858b-3a37908ccae6@felt.demon.nl>
References: <556b4415-f0f0-fffd-858b-3a37908ccae6@felt.demon.nl>
Message-ID: <62E4A62A9124FF717A929D01@[192.168.1.39]>

--On Wednesday, April 17, 2019 8:46 PM +0200 Michael 
<aixtools at felt.demon.nl> wrote:

> warning: missing documentation dependencies. man pages will be empty

Fix your build environment so they get generated?  I.e., the issue isn't 
that they aren't available with the source, the issue is that your build 
environment is missing the necessary tools to generate them.

--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>


From a_s_y at sama.ru  Wed Apr 24 16:15:30 2019
From: a_s_y at sama.ru (Sergey)
Date: Thu, 25 Apr 2019 00:15:30 +0400
Subject: 2.1.27: problem with --sysconfdir and Sendmail
Message-ID: <201904250015.30585.a_s_y@sama.ru>

Hello.

I have a problem with Cyrus-SASL 2.1.27 release and Sendmail. Sendmail
uses SASL's paths for find Sendmail.conf. It searchs configuration in
"sysconfdir" and "plugindir". I build sasl with --sysconfdir=/etc/sasl2
and --with-plugindir=/usr/lib/sasl2-3 (i586 version). Sendmail works
with 2.1.26 and 2.1.27rc8. It starts with one error

safesasl(/usr/lib/sasl2-3/Sendmail.conf) failed: No such file or directory

and finds Sendmail.conf in the directory /etc/sasl2. However, with 2.1.27
release an extra directory "sasl2" is added and the file is not found:

safesasl(/usr/lib/sasl2-3/Sendmail.conf) failed: No such file or directory
safesasl(/etc/sasl2/sasl2/Sendmail.conf) failed: No such file or directory

Is this a bug or Is using of --sysconfdir was changed?

-- 
Regards,
Sergey

From quanah at symas.com  Wed Apr 24 16:28:35 2019
From: quanah at symas.com (Quanah Gibson-Mount)
Date: Wed, 24 Apr 2019 13:28:35 -0700
Subject: 2.1.27: problem with --sysconfdir and Sendmail
In-Reply-To: <201904250015.30585.a_s_y@sama.ru>
References: <201904250015.30585.a_s_y@sama.ru>
Message-ID: <B44A6F187D320D81A407C25D@[192.168.1.39]>

--On Thursday, April 25, 2019 1:15 AM +0400 Sergey <a_s_y at sama.ru> wrote:

> Hello.
>
> I have a problem with Cyrus-SASL 2.1.27 release and Sendmail. Sendmail
> uses SASL's paths for find Sendmail.conf. It searchs configuration in
> "sysconfdir" and "plugindir". I build sasl with --sysconfdir=/etc/sasl2
> and --with-plugindir=/usr/lib/sasl2-3 (i586 version). Sendmail works
> with 2.1.26 and 2.1.27rc8. It starts with one error
>
> safesasl(/usr/lib/sasl2-3/Sendmail.conf) failed: No such file or directory
>
> and finds Sendmail.conf in the directory /etc/sasl2. However, with 2.1.27
> release an extra directory "sasl2" is added and the file is not found:
>
> safesasl(/usr/lib/sasl2-3/Sendmail.conf) failed: No such file or directory
> safesasl(/etc/sasl2/sasl2/Sendmail.conf) failed: No such file or directory
>
> Is this a bug or Is using of --sysconfdir was changed?

The behavior was changed.  If you look at 2.1.27's configure:

  configdir='${plugindir}:${sysconfdir}/sasl2'

There's even a new option to configure:

   --with-configdir=DIR    set the directory where config files will

I believe sysconfdir was never intended to be "/etc/sasl2", just "/etc".

The config dir is intended to be "/etc/sasl2" (or /usr/local/etc/sasl2, 
etc, depending on the prefix).

--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>


From a_s_y at sama.ru  Thu Apr 25 09:38:54 2019
From: a_s_y at sama.ru (Sergey)
Date: Thu, 25 Apr 2019 17:38:54 +0400
Subject: 2.1.27: problem with --sysconfdir and Sendmail
In-Reply-To: <B44A6F187D320D81A407C25D@[192.168.1.39]>
References: <201904250015.30585.a_s_y@sama.ru>
 <B44A6F187D320D81A407C25D@[192.168.1.39]>
Message-ID: <201904251738.54292.a_s_y@sama.ru>

On Thursday 25 April 2019, Quanah Gibson-Mount wrote:

> > safesasl(/usr/lib/sasl2-3/Sendmail.conf) failed: No such file or directory
> > safesasl(/etc/sasl2/sasl2/Sendmail.conf) failed: No such file or directory
> >
> > Is this a bug or is using of --sysconfdir was changed?

> The behavior was changed.  If you look at 2.1.27's configure:
>
>  configdir='${plugindir}:${sysconfdir}/sasl2'
>
> There's even a new option to configure:
> 
> ? ?--with-configdir=DIR ? ?set the directory where config files will
 
Thanks. It works.

-- 
Regards, Sergey

From aixtools at felt.demon.nl  Mon Apr 29 09:11:50 2019
From: aixtools at felt.demon.nl (Michael)
Date: Mon, 29 Apr 2019 15:11:50 +0200
Subject: AUTH confirmation with SENDMAIL
Message-ID: <93b901f2-ccfd-e448-7a40-60ec52cfad4a@felt.demon.nl>

If you have any experience with configuring SENDMAIL and AUTH - and
willing to share - I'd appreciate some hints.

Just to get things started:

a) I am building sasl and sendmail myself - errors are likely
self-inflicted.

b) when I start sendmail (-OLogLevel=14) I see:

syslog output: date-string... AUTH: available mech=SCRAM-SHA-1
SCRAM-SHA-256 DIGEST-MD5 OTP CRAM-MD5 PLAIN ANONYMOUS, allowed
mech=EXTERNAL GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5

FYI: no special attention to mechanisms I recall when building SASL (v1.27)

My sendmail.mc file contains:

dnl # FEATURE(genericstable)dnl
dnl # FEATURE(mailertable)dnl
dnl # FEATURE(virtusertable)dnl
dnl # FEATURE(domaintable)dnl
dnl # FEATURE(access_db)dnl
dnl # FEATURE(blacklist_recipients)dnl

dnl ### AUTH CONFIGURATION
define(`confAUTH_OPTIONS', `A')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl

The generated sendmail.cf file contains:

root at x066:[/data/prj/aixtools/git/sendmail/sendmail-8.15.2.1/cf/cf]grep
Auth /tmp/sendmail.cf
C{TrustAuthMech}LOGIN PLAIN
O AuthMechanisms=LOGIN PLAIN
# Authentication realm
#O AuthRealm
#O DefaultAuthInfo=/etc/mail/default-auth-info
O AuthOptions=A
#O AuthMaxBits
R$*???????????????????? $: $1 $| $>"Local_Relay_Auth" $&{auth_type}
R$* $| $={TrustAuthMech}??????? $# RELAY

ehlo says:

ehlo x.y.z
250-x066.home.local Hello root at localhost, pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5
250-STARTTLS
250-DELIVERBY
250 HELP
auth
501 5.5.2 AUTH mechanism must be specified
auth PLAIN
504 5.3.3 AUTH mechanism PLAIN not available
AUTH LOGIN
504 5.3.3 AUTH mechanism LOGIN not available
AUTH CRAM-MD5
334 PDEyMzI4NzU5MjEuMTMwMzk1NDZAeDA2Ni5ob21lLmxvY2FsPg==

***

While I do not expect to run as "PLAIN", I am using these values to
verify my understanding of the setup. Suggestions on how to activate
PLAIN/LOGIN are welcome!

Michael



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20190429/cd398b52/attachment.sig>

From edgar at pettijohn-web.com  Mon Apr 29 09:18:06 2019
From: edgar at pettijohn-web.com (Edgar Pettijohn)
Date: Mon, 29 Apr 2019 08:18:06 -0500
Subject: AUTH confirmation with SENDMAIL
Message-ID: <201904291318.x3TDI9Ks076946@mailman-02.andrew.cmu.edu>

It's been awhile but this is what I used to get started.

http://www.sendmail.org/~ca/email/auth.html
On Apr 29, 2019 8:11 AM, Michael <aixtools at felt.demon.nl> wrote:
>
> If you have any experience with configuring SENDMAIL and AUTH - and
> willing to share - I'd appreciate some hints.
>
> Just to get things started:
>
> a) I am building sasl and sendmail myself - errors are likely
> self-inflicted.
>
> b) when I start sendmail (-OLogLevel=14) I see:
>
> syslog output: date-string... AUTH: available mech=SCRAM-SHA-1
> SCRAM-SHA-256 DIGEST-MD5 OTP CRAM-MD5 PLAIN ANONYMOUS, allowed
> mech=EXTERNAL GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5
>
> FYI: no special attention to mechanisms I recall when building SASL (v1.27)
>
> My sendmail.mc file contains:
>
> dnl # FEATURE(genericstable)dnl
> dnl # FEATURE(mailertable)dnl
> dnl # FEATURE(virtusertable)dnl
> dnl # FEATURE(domaintable)dnl
> dnl # FEATURE(access_db)dnl
> dnl # FEATURE(blacklist_recipients)dnl
>
> dnl ### AUTH CONFIGURATION
> define(`confAUTH_OPTIONS', `A')dnl
> TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
> define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
>
> The generated sendmail.cf file contains:
>
> root at x066:[/data/prj/aixtools/git/sendmail/sendmail-8.15.2.1/cf/cf]grep
> Auth /tmp/sendmail.cf
> C{TrustAuthMech}LOGIN PLAIN
> O AuthMechanisms=LOGIN PLAIN
> # Authentication realm
> #O AuthRealm
> #O DefaultAuthInfo=/etc/mail/default-auth-info
> O AuthOptions=A
> #O AuthMaxBits
> R$*???????????????????? $: $1 $| $>"Local_Relay_Auth" $&{auth_type}
> R$* $| $={TrustAuthMech}??????? $# RELAY
>
> ehlo says:
>
> ehlo x.y.z
> 250-x066.home.local Hello root at localhost, pleased to meet you
> 250-ENHANCEDSTATUSCODES
> 250-PIPELINING
> 250-EXPN
> 250-VERB
> 250-8BITMIME
> 250-SIZE
> 250-DSN
> 250-ETRN
> 250-AUTH DIGEST-MD5 CRAM-MD5
> 250-STARTTLS
> 250-DELIVERBY
> 250 HELP
> auth
> 501 5.5.2 AUTH mechanism must be specified
> auth PLAIN
> 504 5.3.3 AUTH mechanism PLAIN not available
> AUTH LOGIN
> 504 5.3.3 AUTH mechanism LOGIN not available
> AUTH CRAM-MD5
> 334 PDEyMzI4NzU5MjEuMTMwMzk1NDZAeDA2Ni5ob21lLmxvY2FsPg==
>
> ***
>
> While I do not expect to run as "PLAIN", I am using these values to
> verify my understanding of the setup. Suggestions on how to activate
> PLAIN/LOGIN are welcome!
>
> Michael
>
>
>

From kenh at cmf.nrl.navy.mil  Mon Apr 29 09:21:14 2019
From: kenh at cmf.nrl.navy.mil (Ken Hornstein)
Date: Mon, 29 Apr 2019 09:21:14 -0400
Subject: AUTH confirmation with SENDMAIL
In-Reply-To: <93b901f2-ccfd-e448-7a40-60ec52cfad4a@felt.demon.nl>
References: <93b901f2-ccfd-e448-7a40-60ec52cfad4a@felt.demon.nl>
Message-ID: <201904291321.x3TDLExc018527@hedwig.cmf.nrl.navy.mil>

>250-AUTH DIGEST-MD5 CRAM-MD5
>250-STARTTLS

A lot of the time applications either have a default configuration or are
hardwired to only offer "insecure" SASL mechanisms when session encryption
(like TLS) is being used.  Why don't you try:

  openssl s_client -connect smtp-server:smtp-port -crlf -starttls smtp

Do a EHLO, and see what is being offered as SASL mechanisms then.

--Ken

From russellbell at gmail.com  Mon Apr 29 13:29:28 2019
From: russellbell at gmail.com (russellbell at gmail.com)
Date: Mon, 29 Apr 2019 11:29:28 -0600
Subject: sendmail + sasl
Message-ID: <201904291729.x3THTSYk015363@randytool.net>

	I use these successfully.  I set it up years ago and forget
the details.  The mc file contains:

	define(`confAUTH_OPTIONS', `A p y')
	define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')


	devtools/Site/site.config.m4 is:

	APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL')
	APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
	APPENDDEF(`confINCDIRS', `-I/usr/include/sasl')

	dnl ### Changes for STARTTLS support
	APPENDDEF(`confENVDEF',`-DSTARTTLS')
	APPENDDEF(`confLIBS', `-lssl -lcrypto')
	APPENDDEF(`confINCDIRS', `-I/usr/include/openssl')


	Does ldd sendmail return a dependence on libsasl?

	Claus A?mann occasionally responds usefully on comp.mail.sendmail

russell bell

From aixtools at felt.demon.nl  Tue Apr 30 02:45:38 2019
From: aixtools at felt.demon.nl (Michael)
Date: Tue, 30 Apr 2019 08:45:38 +0200
Subject: AUTH confirmation with SENDMAIL
In-Reply-To: <93b901f2-ccfd-e448-7a40-60ec52cfad4a@felt.demon.nl>
References: <93b901f2-ccfd-e448-7a40-60ec52cfad4a@felt.demon.nl>
Message-ID: <92e636d9-dbdf-6c7c-d2a6-621fd743e4dc@felt.demon.nl>

On 29/04/2019 15:11, Michael wrote:
> If you have any experience with configuring SENDMAIL and AUTH - and
> willing to share - I'd appreciate some hints.
>
> Just to get things started:
>
> a) I am building sasl and sendmail myself - errors are likely
> self-inflicted.

And the answer is: not enough coffee - so I was blinded to my typo - not
using sendmail .... -C /tmp/sendmail.cf, and it kept using, over and
over and over, the system sendmail.cf. So, now I am getting "AUTH PLAIN"
as an option.

My many thanks to the replies - I shall post a short summary of my
"encounter" with sendmail+sasl.

FYI: I am working on AIX. IBM has apparently decided they do not plan to
support AUTH (on AIX), so this been quite the experience.

IMHO: the sendmail FAQ (which is very hard to find/access via the
portal, I doubt I ever actually managed that) - would need to have added
- a reminder - that sendmail ./Build pre-dates GNU autotools - and if
there is a DEFINE missing, you must provide it yourself! (HADURANDOMDEV
needed to get STARTTLS working)

IMHO2: SASL documentation is not easy for a newbie - to find things.
Working from defaults, so also an empty Sendmail.conf. I guess my task
today is to find howto/whatto add into the ./configure arguments for
SASL (as I am confused by the output of syslog re: SASL, compared to
output of saslauthd)

Apr 30 06:24:12 x066 mail:info sendmail[4194364]: AUTH: available
mech=SCRAM-SHA-1 SCRAM-SHA-256 DIGEST-MD5 OTP CRAM-MD5 PLAIN ANONYMOUS,
allowed ...

root at x066:[/]opt/sbin/saslauthd -v saslauthd authentication mechanisms
saslauthd 2.1.27
authentication mechanisms: getpwent pam rimap

My assumption at this point is that "getpwent" is the mechanism that
gets local users. A document I have looked at mentions (at version
2.1.22 time) the mechanisms: getpwent rimap shadow (and places emphasis
on shadow)

Anyway - long intro (as in as I gather my thoughts).

Suggestions on what to read first, then second - would be appreciated.

Thanks again for the suggestions on where to look. They all helped!

Sincerely,

Michael

knip
>
> ehlo says:
>
> ehlo x.y.z
> 250-x066.home.local Hello root at localhost, pleased to meet you
> 250-ENHANCEDSTATUSCODES
> 250-PIPELINING
> 250-EXPN
> 250-VERB
> 250-8BITMIME
> 250-SIZE
> 250-DSN
> 250-ETRN
> 250-AUTH DIGEST-MD5 CRAM-MD5
> 250-STARTTLS
> 250-DELIVERBY
> 250 HELP
> auth
> 501 5.5.2 AUTH mechanism must be specified
> auth PLAIN
> 504 5.3.3 AUTH mechanism PLAIN not available
> AUTH LOGIN
> 504 5.3.3 AUTH mechanism LOGIN not available
> AUTH CRAM-MD5
> 334 PDEyMzI4NzU5MjEuMTMwMzk1NDZAeDA2Ni5ob21lLmxvY2FsPg==
>
> ***
>
> While I do not expect to run as "PLAIN", I am using these values to
> verify my understanding of the setup. Suggestions on how to activate
> PLAIN/LOGIN are welcome!
>
> Michael
>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20190430/8f4ec94e/attachment.sig>