Cyrus IMAPd 2.2.13p1 & 2.3.15 Released

[Bron Gondwana]

On Sat, Sep 19, 2009 at 04:12:02PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 19 Sep 2009, Dave McMurtrie wrote:
> > Henrique de Moraes Holschuh wrote:
> > >>Which I'm afraid was my fault for saying "it's already been
> > >>committed to CVS, so it's out there" to them.  Sorry about
> > >>that.  *sigh*.
> > 
> > I already spoke with Bron off-list at great length about this.
> > There's really no need for any apology on his part.  We greatly
> > appreciate the work that Bron puts into Cyrus imapd.
> 
> Indeed we do!  Bron, thank you very much for the work you've been doing on
> Cyrus IMAP.

Aww, shucks.
 
> We are also *very* thankful to CMU for Cyrus IMAP and all the work done on
> it over the years.

Yeah, it's a nice system (mostly, it does have its warts!)  We certainly
appreciate it here at FastMail.

> > When you say that CERT did not contact the correct people, can you
> > be more specific?  Feel free to respond off-list if you feel that's
> > necessary.  I have no problem getting back in touch with CERT to
> > provide updated contact information for them.
> 
> Well, when you warn all downstream maintainers about an issue, you have to
> keep them all in the loop.  This was not done for whatever reason.  Unless
> told differently, CERT will only contact the security contact points for a
> given distro or package, which is likely not going to include all of us...

I should have fed that information back to you guys too, since I sent
the initial heads-up to the people I knew were maintaining packages.
I didn't realise that CERT contacts wouldn't be forwarded to you.

> > As far as this not having been handled in a timely manner, I don't
> > think that's a fair criticism.  This bug has existed in the code
> 
> I was complaining about the embargo request from CERT coming too late,
> that's all.  And explaining why Debian had releases out before the embargo
> lift date: the Debian maintainers were never told about the embargo until
> it was too late.

We'll have to be more careful about this one next time.

> > If you have any additional suggestions on how to better handle
> > security issues in the future, please let me know.
> 
> 1. If it is going to be embargoed, tell everyone upfront and don't commit to
> public cvs.  This will avoid leaks before the embargo is lifted.

This is somewhat interesting actually - I made my initial commit to my
github tree before I realised the security implications.  That's a whole
lot less public than CVS, but it's still out there.  My workflow always
goes via the public space, even to get commits onto our testbed.  For
backups!  If we did move to using git then it would be good to have a
"private branch" that didn't get exported to the public repository or
notified to anybody until we cherry-picked the commits over to mainline!

Bron.

> 2. If it is semi-public for whatever reason, make it clear to CERT, and
> don't embargo.
> 
> -- 
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh