Security Issues
Handling Security Issues
Initiating Contact
If you find a possible vulnerability, please mail
security-officer@NetBSD.org.
For problems with packages, please mail
pkgsrc-security@NetBSD.org instead.
If the Security Officers contact you
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
system.
Correspondence
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
words:
Please CC: *all* communications about a security issue,
regardless of how trivial you think they are,
to security-officer@NetBSD.org.
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.
Advisories
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!
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
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