On Sun, Apr 13, 2014 at 7:41 AM, Michael Ströder <mich...@stroeder.com>wrote:
> Brian Smith wrote: > > I always thought that the CRL requirement was in there because long of go > > we expected that we'd eventually start fetching CRLs at some point, and > > then it was left in there due to inertia, mostly. > > > > Keep in mind that S/MIME and TLS have different requirements. > > I really wonder why this is discussed *after* quickly hunking out CRL > support > even from Thunderbird and Seamonkey. > I spent a long time talking with Brendan and also with my former managers at Mozilla about how we support Thunderbird while we improve Gecko for Firefox. Unfortunately, Mozilla hasn't done a good job of frankly explaining the policy. Basically, Gecko developers are allowed to basically work almost as though Thunderbird doesn't exist; if we break something in Thunderbird, it's up to the Thunderbird developers to fix it. It isn't clear if Gecko developers actually have a responsibility to help integrate fixes for Thunderbird, but I and others seem to all review patches to Gecko for the Thunderbird team to fix breakage we caused. In this instance, if we've broken something regarding S/MIME, it's up to the Thunderbird developers to notice and fix it. Unfortunately, there are no automated tests of S/MIME functionality (AFAICT) so it is likely that nobody will notice if/when we break anything with S/MIME in Thunderbird. AFAICT, the Thunderbird project is in need of somebody to volunteer to maintain the S/MIME functionality, and has been in need of somebody for a long time. For a long time I've been wanting to remove the S/MIME code from Gecko completely. It is likely that will happen the next time the S/MIME code inconveniences us during Firefox development. I would guess that the Thunderbird team would then import the S/MIME code into comm-central and maintain it there. Cheers, Brian _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
