From Duncan.Gibb at SiriusIT.co.uk Tue Nov 4 14:08:59 2008 From: Duncan.Gibb at SiriusIT.co.uk (Duncan Gibb) Date: Tue, 04 Nov 2008 19:08:59 +0000 Subject: [PATCH 1/2] mupdate starttls always times out Message-ID: <49109DCB.7090104@SiriusIT.co.uk> Hi We're building a 2.3.13 murder in which we would like as much network traffic as possible to be encrypted. We found that the starttls command always times out when talking to the MUPDATE master. strace suggests the problem is the select() call at imap/tls.c line 871 which has the fd ceiling value hard-coded to 1. That code was introduced by rev 1.60 of this file: https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/imap/tls.c.diff?r1=1.59;r2=1.60;f=h mupdate is the only daemon affected since all the others call "tls_start_servertls(0, ...)". In the mupdate case readfd is not stdin. AFAICT this must have been broken in 2.3.11 and 2.3.12 as well, so I'm surprised no-one seems to have noticed earlier. I did have a hunt around in CMU bugzilla (and a Google) to no avail. I will create a new bugzilla tomorrow unless someone can point me at an existing report. The attached patch "fixes" the problem but reveals a related one (see next email)... Cheers Duncan -- Duncan Gibb, Technical Director Sirius Corporation plc - The Open Source Experts http://www.siriusit.co.uk/ Tel: +44 870 608 0063 -------------- next part -------------- A non-text attachment was scrubbed... Name: mupdate-tls-timeout.patch Type: text/x-diff Size: 451 bytes Desc: not available Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20081104/211e7623/attachment.bin From Duncan.Gibb at SiriusIT.co.uk Tue Nov 4 14:11:47 2008 From: Duncan.Gibb at SiriusIT.co.uk (Duncan Gibb) Date: Tue, 04 Nov 2008 19:11:47 +0000 Subject: [PATCH 2/2] mupdate starttls should be thread-safe Message-ID: <49109E73.8020106@SiriusIT.co.uk> Hello again, I just posted a patch to make starttls in mupdate do something other than time out. However, the crypto code is not thread-safe. Under moderate load TLS negotiations fail all over the place and mupdate segfaults fairly frequently. The attached is a first attempt at addressing this. It creates two new files, imap/tls_th-lock.c and imap/tls_th-lock.h mostly borrowed from the example pthread locking functions supplied with OpenSSL. For brevity, this patch does not add the CMU comment block to these new files. The idea is to create an object which could be linked with daemons other than mupdate if they also need multi-threaded TLS in the future. For now we just add CRYPTO_thread_setup() and CRYPTO_thread_cleanup() calls to mupdate's service_init() and service_abort() respectively. This has been tested only on x86_64 Debian Linux and not (yet) in a production murder. Note that ciphers requiring ephemeral keys are probably still broken without a thread-safe replacement for tmp_rsa_cb(). Cheers Duncan -- Duncan Gibb, Technical Director Sirius Corporation plc - The Open Source Experts http://www.siriusit.co.uk/ Tel: +44 870 608 0063 -------------- next part -------------- A non-text attachment was scrubbed... Name: mupdate-threaded-tls.patch Type: text/x-diff Size: 4532 bytes Desc: not available Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20081104/78c925b4/attachment.bin From wes at umich.edu Tue Nov 4 14:37:16 2008 From: wes at umich.edu (Wesley Craig) Date: Tue, 4 Nov 2008 14:37:16 -0500 Subject: [PATCH 2/2] mupdate starttls should be thread-safe In-Reply-To: <49109E73.8020106@SiriusIT.co.uk> References: <49109E73.8020106@SiriusIT.co.uk> Message-ID: <36D69C3C-6E26-4751-BCE8-7A1537A5EEA6@umich.edu> On 04 Nov 2008, at 14:11, Duncan Gibb wrote: > I just posted a patch to make starttls in mupdate do something other > than time out. However, the crypto code is not thread-safe. Under > moderate load TLS negotiations fail all over the place and mupdate > segfaults fairly frequently. Both of these patches look good. Please enter them into bugzilla. I look forward to your changes for tmp_rsa_cb(). Thanks! :wes From Duncan.Gibb at SiriusIT.co.uk Wed Nov 5 05:22:24 2008 From: Duncan.Gibb at SiriusIT.co.uk (Duncan Gibb) Date: Wed, 05 Nov 2008 10:22:24 +0000 Subject: [PATCH 2/2] mupdate starttls should be thread-safe In-Reply-To: <36D69C3C-6E26-4751-BCE8-7A1537A5EEA6@umich.edu> References: <49109E73.8020106@SiriusIT.co.uk> <36D69C3C-6E26-4751-BCE8-7A1537A5EEA6@umich.edu> Message-ID: <491173E0.4090106@SiriusIT.co.uk> Wesley Craig wrote: DG> I just posted a patch to make starttls in mupdate do something DG> other than time out. However, the crypto code is not thread-safe. WC> Both of these patches look good. Please enter them into bugzilla. OK. https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3119 WC> I look forward to your changes for tmp_rsa_cb(). Thanks! I'll try to look at that, but ephemeral-key ciphers are not something I need working immediately. Ideally I want a murder in which all the server-to-server authentication is done with x509 certificates... Cheers Duncan -- Duncan Gibb, Technical Director Sirius Corporation plc - The Open Source Experts http://www.siriusit.co.uk/ Tel: +44 870 608 0063 From Duncan.Gibb at SiriusIT.co.uk Fri Nov 7 12:59:04 2008 From: Duncan.Gibb at SiriusIT.co.uk (Duncan Gibb) Date: Fri, 07 Nov 2008 17:59:04 +0000 Subject: [PATCH] client certificates for TLS Message-ID: <491481E8.2010103@SiriusIT.co.uk> Hello Friday afternoon proposed feature enhancement... The attached patch extends the functionality of backend.c to support client certificates when setting up TLS sessions between one Cyrus machine and another. The new options tls_client_cert_file and tls_client_key_file can use the established "_" and/or "_" prefixes just like the server certificate equivalents and "_password". Client certificates can be used to augment or, by the magic of SASL's "EXTERNAL" mechanism, replace passwords for Cyrus-to-Cyrus authentication in Murder. Tested (very briefly) on Debian x86_64 for imap proxy authentication and mupdate authentication (with our mupdate TLS patches -- see https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3119 ). Cheers Duncan -- Duncan Gibb, Technical Director Sirius Corporation plc - The Open Source Experts http://www.siriusit.co.uk/ Tel: +44 870 608 0063 -------------- next part -------------- A non-text attachment was scrubbed... Name: backend_client_certs.patch Type: text/x-diff Size: 3739 bytes Desc: not available Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20081107/7381755d/attachment.bin From alexey.melnikov at isode.com Sat Nov 15 15:41:32 2008 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Sat, 15 Nov 2008 14:41:32 -0600 Subject: patch: add sqlite3 backend support to the cyrus-sasl sql plugin In-Reply-To: <291f35090810280751w7f05df0eo520a3a849d0a0090@mail.gmail.com> References: <291f35090810280751w7f05df0eo520a3a849d0a0090@mail.gmail.com> Message-ID: <491F33FC.4020905@isode.com> Maxim Gorbachyov wrote: >Hello. > >Proposed patch (see attachment) adds sqlite3 backend support to the cyrus-sasl >sql plugin. The patch does not interfere with present sqlite(v2) code. Build >infrastructure is updated (tested on Debian Sid and on Ubuntu Hardy), but this >update does not address win32 systems. > > I've added Win32 support. The change compiles for me, so I will integrate your patch. I might clean it up a bit later. >It seems like this patch is a solution for: >https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2754 > Yes. I had my own version, but I never compiled it. >I've added the patch to bugzilla: >https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3112 > From bawood at umich.edu Wed Nov 19 12:43:57 2008 From: bawood at umich.edu (Brian Awood) Date: Wed, 19 Nov 2008 12:43:57 -0500 Subject: More special chars in mailbox names In-Reply-To: References: <48E28CFE.2020104@andrew.cmu.edu> <48E2D0FB.8040406@andrew.cmu.edu> Message-ID: <200811191243.57324.bawood@umich.edu> Either Wes jinxed us or we've finally demonstrated why allowing * in mailbox names is a bad idea. We recently had a user rename a parent mailbox containing a "*", to a name not containing the "*". At that point cyrus took the liberty of renaming all the sub mailboxes by removing the first couple of characters. So for example their mailboxes went from something like: *parent/child1 *parent/child2 after renaming "*parent" to "parent" they became: parent/ild1 parent/ild2 etc... In testing this I've also observed even more interesting behavior by renaming a mailbox while adding or removing a * to a mailbox that already has a "*". This originally occurred on a 2.3.12 machine, but I've reproduced it in 2.3.13 & 2.3.8. I suspect part of of this issue is code like the following in the "findall"/"findsub" functions in mboxlist.c /* Find fixed-string pattern prefix */ for (p = pat; *p; p++) { if (*p == '*' || *p == '%' || *p == '?' || *p == '@') break; } prefixlen = p - pattern; *p = '\0'; I thought about reversing the direction of the character search to see if that would help, but I suspect there are other issues as well. Also, since @ is normally allowed in GOODCHARS, it seems the above code could trigger unexpected behavior for people even if they are using the standard GOODCHARS. --- Brian Awood University of Michigan ITCS On Tuesday 30 September 2008 @ 22:15, Wesley Craig wrote: > On 30 Sep 2008, at 21:23, Ken Murchison wrote: > > Using list-wildcards would always be a bad idea IMHO. > > UMich has a lot of mailboxes with * in their names. It's not a > problem, tho you're probably right that it's a bad idea. I guess > IMAP implementations usually use literals to communicate. Which is > just what Cyrus does internally. The rest of that optional syntax is > gilding. > > :wes From hdembkowski at alcatel-lucent.com Mon Nov 24 10:29:09 2008 From: hdembkowski at alcatel-lucent.com (DEMBKOWSKI, Henryk (Henryk)) Date: Mon, 24 Nov 2008 16:29:09 +0100 Subject: New Cyrus 2.3.13 Message-ID: All, Is it possible to have two different versions of Cyrus installed on two different box and they can talk to each other? I see that function do_mailbox_single() is different between 2.3.7 and 2.3.13. I am wondering if replication will be working. Kind Regards, Henryk From wes at umich.edu Mon Nov 24 11:23:59 2008 From: wes at umich.edu (Wesley Craig) Date: Mon, 24 Nov 2008 11:23:59 -0500 Subject: New Cyrus 2.3.13 In-Reply-To: References: Message-ID: <3ACDADCE-A14D-4524-8C69-8CB0C436FD76@umich.edu> On 24 Nov 2008, at 10:29, DEMBKOWSKI, Henryk ((Henryk)) wrote: > Is it possible to have two different versions of Cyrus installed on > two > different box > and they can talk to each other? > > I see that function do_mailbox_single() is different between 2.3.7 and > 2.3.13. > I am wondering if replication will be working. It's something you need to test, generally. It's often the case that xfer from an older rev works to a newer rev, the other direction less so. Frontends & backends can often be different versions, tho again testing is important. Primary backends and replicas typically have to be the same version: the csync protocol is internal and changes are frequent. :wes From lee1551 at yahoo.com Fri Nov 28 03:37:20 2008 From: lee1551 at yahoo.com (Lee L) Date: Fri, 28 Nov 2008 00:37:20 -0800 (PST) Subject: ldapsearch for gss-spnego mechanism returns error? Message-ID: <657375.36712.qm@web111104.mail.gq1.yahoo.com> My ldapsearch for mechanism type "-Y GSS-SPNEGO" returns "Unknown mechanism" error. Is there anything I am missing in my installation. Pluginviewer command returned both NTLM and GSSAPI plugins are installed on the client side. Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20081128/9052a03a/attachment.html From alexey.melnikov at isode.com Fri Nov 28 06:35:47 2008 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Fri, 28 Nov 2008 11:35:47 +0000 Subject: ldapsearch for gss-spnego mechanism returns error? In-Reply-To: <657375.36712.qm@web111104.mail.gq1.yahoo.com> References: <657375.36712.qm@web111104.mail.gq1.yahoo.com> Message-ID: <492FD793.9030600@isode.com> Hi, Lee L wrote: > My ldapsearch for mechanism type "-Y GSS-SPNEGO" returns "Unknown > mechanism" error. > > Is there anything I am missing in my installation. Pluginviewer > command returned both NTLM and GSSAPI plugins are installed on the > client side. Any ideas? Yes, GSS-SPNEGO is a different SASL mechanism from GSSAPI.