join
donate

Handling Security Issues

Reporting Security Issues

We ask people to report security issues regarding the ntp codebase to security@ntp.org .

Exactly what is a security issue?

Life Cycle of Security Issues

  • Get report
    • If the reporter registers at our bugzilla we can easily keep them in the loop
    • Using security bugs also consolidates the information in the right places and gets the right people involved
  • Validate report
  • Start working on the fix
  • Determine its CVSS Score: https://nvd.nist.gov/cvss.cfm
  • Request a CVE: email cve@mitre.org and ask for a CVE Identifier
  • Write up the CVE report
  • Inform NTP Forum Institutional Members
  • Inform CERT
  • Schedule the release
  • ...

Discussion and Related Issues

We (used to) ask that people not directly create bugzilla items for security issues.

  • What were the reasons for this?
    • I thought one of them was because we were concerned that email might go to bugs@ and we only want it to go to security@
  • Are any of them still valid?
  • We should consider finding a Security Officer
  • Exactly what is the security@ address for?
    • Who should be on that list?

Here are some other issues:

  • At what point do we make patches for these issues publically available?
  • As we apply commits to ntp-dev or ntp-stable we automatically generate diff email, commit-log email, in addition to publishing the commits.
  • At what point can we remove the security restriction on the bugzilla issue?
    • I am inclined to do this when:
      • the (first?) patch for the problem is published in a public repo
      • after the bug is marked RESOLVED/READY

Is this an acceptable way to evolve a fix for a security issue:

  • clone a repo to deal with it
  • commit patches to this repo
  • make dist tarballs as needed to provide to people for testing
  • when ready:
    • commit these changes to the parent repo for public release
    • mark the issue as VERIFIED
    • remove the security restriction from the bugzilla issue

Also note that VERIFIED currently means "the published fix works" and we may want to use something else (flags?) to signify when a fix is know to work and is ready to be published. We might be able to use READY for this case.

Note that if this is a problem for ntp-stable then one should follow the normal workflow pattern and clone an ntp-dev repo as well. This includes grabbing changes from the parent repos as needed.

-- HarlanStenn - 25 Aug 2006


This topic: Dev > WebHome > HandlingSecurityIssues
Topic revision: r8 - 2011-05-27 - 16:16:27 - HarlanStenn
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback