I think that we should start some documentation (e.g. a wiki) that documents the differences between our implementation and other browsers' implementations, along with a justification for the difference and/or a link to a bug about resolving the difference.
Examples of differences, off the top of my head: https://wiki.mozilla.org/Necko/Differences There are obviously many, many more. I think it is important to document at least the most important differences (security-related issues and/or compatibility issues and/or significant performance differentiators) ahead of our team priorities meeting, because I think this kind of explicit TODO list will likely have some impact on allocation of resources for various projects on the team and/or will reset our expectations on particular goals. Accordingly, please help fill in the list. (This invitation is extended to non-Moco-employees too; anybody can edit that wiki page.) I will probably end up filing a large number of sg:moderate bugs out of this list of differences, which will require much more than one quarter of work to clear. That is, it is probably the case that goals regarding reducing security bug counts of various severities to zero seem realistic now only because we are significantly undercounting security bugs. Enumerating the differences between implementations regarding network security features will help correct the undercounting, but we will also need to go back through existing bugs and ensure they have the correct rating--especially bugs that currently do not have any rating. Doing this triage will be a lot of work and we will have to come up with a plan as to how to do it. Definitely, I do not have time to do it all myself. So, it is a good idea for everybody on the team to become very familiar with the security bug severity rating system, and to rate as any existing security-related bugs in Necko they know of ahead of the team work week. The rating guide is here: https://wiki.mozilla.org/Security_Severity_Ratings If you have questions regarding the severity ratings, please ask on dev-security. Also, for any security bug that was introduced by a patch you wrote, or that you reviewed (if the patch was written by someone who isn't a Necko peer or MoCo employee), please assign the bug to yourself. The main guidelines I am going to recommend regarding security bugs in our components are: * Make sure security bugs are assigned to a Necko peer or MoCo employee if they are expected to be fixed in the current quarter. * The people who introduced a vulnerability are responsible, by default, for fixing that vulnerability. * The set of existing security bugs to fix is to be more-or-less set and clearly enumerated at the start of the quarter. Obviously, all of this is open for discussion. But, this is basically the foundation of what I will propose during the planned security bug meeting during the work week that I will be leading. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
