Future of Cyrus-SASL

[Ken Murchison]

On 07/12/2017 09:10 PM, Quanah Gibson-Mount wrote:
> Hi Bron, Ken, Jan,
>
> That's excellent news!  I look forward to the RC and putting it 
> through its paces. ;)  Are there additional resources beyond Ken that 
> will be working on the SASL project?

Alexey Melnikov still has commit access, but I'm not sure how much 
development time he has at the moment given that he is once again an 
Area Director at IETF.



>
> --Quanah
>
> --On Thursday, July 13, 2017 11:19 AM +1000 Bron Gondwana 
> <brong at fastmailteam.com> wrote:
>
>>
>> Thanks Jan,
>>
>>
>>
>> I wonder if we want to set up a second meeting time, either fortnightly
>> or weekly, that does the other cross over and allows us to more easily
>> include middle and west America.  Our current meeting time is 10pm for
>> Australia, so something that was during the Australian day and
>> afternoon/evening across the USA would work fine for everybody except
>> Europeans.
>>
>>
>>
>> As Ken has already noted - we still want to support SASL.  Now that we
>> have him full time, he's going to release a new version, and at our
>> scheduling meeting on Monday, Nicola bumped up the priority of updating
>> the SASL documentation and converting it to the sphinx-based build 
>> system.
>>
>>
>>
>> Regardless of whether Cyrus-* leaves CMU (which is still being discussed
>> with both CMU and potential new homes), the project intends to keep
>> supporting SASL.
>>
>>
>>
>> Bron.
>>
>>
>>
>>
>>
>> On Thu, 13 Jul 2017, at 09:40, jan parcel wrote:
>>
>>
>> On problem I have is that people in imap development seem to say 
>> (and, on
>> the web, too) that cyrus-sasl means imap, leaving cyrus-? to mean 
>> libsasl?
>>
>>
>>
>> Other than that....
>>
>>
>>
>> I cannot volunteer as a regular contributor because my  regular job uses
>> up all my time.  However, company policy requires us to send "upstream"
>> all relevant bug fixes we create, and to file bugs we find to upstream
>> regardless of whether or not we need to fix them -- for instance,  I
>> might never fix the bug with  failing to exclude ldapdb when so
>> configured,  unless a customer demands that plugin, which I suspect will
>> not happen.    We are also required to SECRETLY and SECURELY report
>> security bugs upstream.
>>
>>
>>
>> Company policy definitely encourages us to have a relationship with
>> upstream developers.
>>
>>
>>
>> But I'm also in the U.S. west coast timezone (Pacific Time) and 4am is
>> not doable for me except in extreme emergencies (such as a high-scoring
>> CVE that needs immediate attention, for instance.)
>>
>>
>>
>> So,  I don't quite know what you will find acceptable in the way of
>> participation from me, but I want to be cooperative to a libsasl
>> community and contribute where I can, and participate if there are
>> meetings that I can reasonably attend.  I'd say times between 6:00 AM -
>> 1AM would be doable.
>>
>>
>>
>> And if the libsasl project were to lose all upstream support, I would be
>> required to report that to my management, and abide by any decisions 
>> they
>> make wrt whether to look for a supported alternative.
>>
>>
>>
>> sendmail can also profitably use libsasl2.
>>
>>
>>
>> So, thanks for including me in this thread.
>>
>>
>>
>> Jan Parcel
>>
>> Software Developer
>>
>> Oracle Systems Server & Cloud Engineering
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>>
>>   Bron Gondwana, CEO, FastMail Pty Ltd
>>
>>   brong at fastmailteam.com
>>
>>
>>
>>
>
>
>
> -- 
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>

-- 
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd