Re: Future of Cyrus-SASL

2017-07-13 Thread 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 
 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

  br...@fastmailteam.com








--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:




--
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd

Re: Future of Cyrus-SASL

2017-07-12 Thread Quanah Gibson-Mount 

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?


--Quanah

--On Thursday, July 13, 2017 11:19 AM +1000 Bron Gondwana 
 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

  br...@fastmailteam.com








--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: Future of Cyrus-SASL

2017-07-12 Thread Bron Gondwana 
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
  br...@fastmailteam.com

Re: Future of Cyrus-SASL

2017-07-12 Thread Ken Murchison 
Now that I am employed by FastMail, I will have more time to work on 
SASL.  In fact, I plan to have a 2.1.27 release candidate available by 
the end of this week.



On 07/12/2017 07:09 PM, Quanah Gibson-Mount wrote:

Hi all,

I started a small discussion on this in cyrus-sasl issue #433, but the 
discussion better belongs here. :)


While I know that Fastmail is taking on the Cyrus-IMAPD project now 
that CMU is divesting itself of it, there does not seem to be a strong 
plan around Cyrus-SASL.  My general understanding is that it is not 
something that Fastmail generally uses.  However, there are many other 
projects where cyrus-sasl is a critical part of the software.


Those include:
OpenLDAP
Postfix
Apache2 (Sasl module)
SSSD
autofs (ldap integration)
Squid proxy
qemu
memcached
Exim
PHP
mutt
389 directory server
subversion

It has been 5 years since the last release of Cyrus-SASL, and 
unfortunately it had a number of bugs.  There have been a large number 
of patches sent to the list in that time, as well as some 142 issues 
on the Github site (hard to know full correlation at this time).  
There has been some work towards a 2.1.27, but it seem stalled at this 
time.


I'm not sure if keeping SASL tied to the IMAPD project makes 
particular sense anymore, given the overall changes that have 
occurred.  Regardless of that particular question, the SASL project 
needs a dedicated development team to start churning through what has 
come in via the list in the last few years, as well as what's in github.


Generally, for the path going forward, perhaps an inquiry to the 
cyrus-sasl list to see if there are individuals willing to commit/join 
the SASL project?  I certainly would be willing to help with the 
release engineering portion, as I do for the OpenLDAP and Heimdal 
projects.


I look forward to hearing people's thoughts.

Warm regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:




--
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd

Re: Future of Cyrus-SASL

2017-07-12 Thread jan parcel 
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

Future of Cyrus-SASL

2017-07-12 Thread Quanah Gibson-Mount 

Hi all,

I started a small discussion on this in cyrus-sasl issue #433, but the 
discussion better belongs here. :)


While I know that Fastmail is taking on the Cyrus-IMAPD project now that 
CMU is divesting itself of it, there does not seem to be a strong plan 
around Cyrus-SASL.  My general understanding is that it is not something 
that Fastmail generally uses.  However, there are many other projects where 
cyrus-sasl is a critical part of the software.


Those include:
OpenLDAP
Postfix
Apache2 (Sasl module)
SSSD
autofs (ldap integration)
Squid proxy
qemu
memcached
Exim
PHP
mutt
389 directory server
subversion

It has been 5 years since the last release of Cyrus-SASL, and unfortunately 
it had a number of bugs.  There have been a large number of patches sent to 
the list in that time, as well as some 142 issues on the Github site (hard 
to know full correlation at this time).  There has been some work towards a 
2.1.27, but it seem stalled at this time.


I'm not sure if keeping SASL tied to the IMAPD project makes particular 
sense anymore, given the overall changes that have occurred.  Regardless of 
that particular question, the SASL project needs a dedicated development 
team to start churning through what has come in via the list in the last 
few years, as well as what's in github.


Generally, for the path going forward, perhaps an inquiry to the cyrus-sasl 
list to see if there are individuals willing to commit/join the SASL 
project?  I certainly would be willing to help with the release engineering 
portion, as I do for the OpenLDAP and Heimdal projects.


I look forward to hearing people's thoughts.

Warm regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: