Security Procedures

Problems with Current Situation

1. We do not have a clear well defined route for security bug reports to reach us.
2. We do not have a defined way to release information about security issues.

3. Due to this we tend to suprise vendors that ship Exim making them scramble madly when we produce a security patch

4. Vendors then get CVE names and the like issued for security issues in Exim, and due to several people doing this at a late stage things get confused.

Proposed Solutions

Issue Reporting To Exim

I propose we have a couple of reporting points for issues and that we make these clear on the main website. The reporting points would be the email addresses:-

• bugs@exim.org - this already exists, however I'd like to make it feed a mailing list (as an initial short term fix) or, rather better, a bug tracking system.

• security@exim.org - a new address specifically for handling security related issues. This could feed a list or BTS or both.

The reasoning for using a mailing list rather than just an alias is to allow archiving and better handling of people being away etc (as long as we put a number of people on th list). The bugs list could be made fully public. Posting restrictions to the list need to be set appropriately to set an appropriate load and response requirements on the list owner/moderator, without making it difficult to post bugs or a list full of viagra adverts.

Longer term (hopefully shorter term) we point everyone to bugzilla - this needs to have appropriate settings to handle security sensitive issues - ie making the bug non-public at least at first.

Security Issue Disclosure

I propose we have a specific procedure for handling security issues:-

1. Initial pickup of issue report, and confirmation of problem with reporter
2. Early notification of problem to Vendors - we could do this via a co-ordinator - including expected timescale to produce a fix, and an intended public release date.
3. Produce a fix
4. Release fix to Vendors
5. Short hold period (I am thinking of 3 days) to allow Vendor build/test/release schedules
6. Public problem announcement and fix release. Vendors should sync to this.

We would need to get things like CVE names (there is one CVE name issued for each distinct bug - the recent set had 2 names issued because 2 of the 3 bugs were different aspects of the same bug) issued at stage 2.

Since we are not experts at handling the security disclosure side of things, one option is to subcontract this role. We could do this by getting (for example) Red Hat to do this - which I think they are happy enough to do), but they do have their own agenda, and keeping the *BSDs and debian informed may not be top of their priorities.

I have asked NISCC if they would be interested in this role - as a UK based software project with a significant presence in UK Infrastructure, both governmental and otherwise, we would appear to fit with their remit. They are basically positive, but want to set up a face-to-face meeting to discuss it. This is being arranged.

Set of notes on things we need to do...

CVE Names

Various options:-

• Mail "Steven M. Christey" <coley@linus.mitre.org> for names

• Get "Mark J. Cox (Security Response Team)" <mjc@redhat.com> to do it

• Put on RH bugzilla, mark private & security, and RH (probably Mark) will do it for us Could do similar via debian.