- Initiating Contact
- If the Security Officers contact you
- The security-officer can always use help!
- Sequence of events in handling issues
Handling Security Issues
Initiating Contact (top)
If the Security Officers contact you (top)
When Security issues are brought to the attention of
<security-officer@NetBSD.org> one of the members
of that group may initiate contact with (a) developer(s)
considered to have expertise in the related area of the
- Copy the S-O on all related correspondence. If it is
necessary to discuss side issues with other persons, ask them to
CC: the S-O as well. Failure to do this could lead to
incomplete/incorrect announcements, if the S-O has not had the
benefit of understanding all the related issues. In the S-Os own
Please CC: *all* communications about a security issue, regardless of how trivial you think they are, to
- If you have any question about what's going on with an advisory, *ask*. Don't assume. People make mistakes. It's better to tweak the process and people's assumptions so that other people are more likely to catch mistakes.
In general, advisories are not sent out for review until they're almost ready to be distributed, and all relevant fixes in question are pulled up to all active release branches. If, when reviewing an advisory, you find something has been missed, message the S-O ASAP.
The security-officer can always use help! (top)
Doing the security officer job in an even vaguely close to correct way takes a *LOT* of time. It easily takes four to eight hours, and sometimes more, to do all the miscellaneous work needed to send out a given advisory.
If you find or fix a security issue, please make our jobs as easy as possible, including:
- arranging for pull-ups of the fixes to all active branches
- providing text for the security advisory, or writing the whole thing if at all possible.
Sequence of events in handling issues (top)
- Receive notification of a security issue.
- Investigate the nature of the issue.
- Determine the most appropriate handler(s) for that piece of the tree.
- Contact the handler(s), and get a promised resolution time. (if at all possible)
- Once the fix has been suggested, test it. (handlers may help, but it should be reviewed by someone other than the coder)
- If the issue involves a remote vulnerability, update the public NetBSD servers. In particular, this must be done before any CVS commits! This should happen with 24 hours (preferrably 12 hours or less) of notification being received. If the fix is not ready, apply a stopgap (hack!) fix to close the window of vulnerability.
- Prepare the Security Announcement, describing:
- The affected components
- The affected releases
- The nature of the security violation
- The method used in closing the vulnerability
- Commit the fix to the CVS repository
- Release the SA to NetBSD and appropriate external mailing-lists.
- Submit the SA for the web pages