Handling Security Issues

(Harlan thinks the following is true. He may be right...)

Please edit this page and add comments or post questions.

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

We 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:

  • Exactly what is a security issue?
  • 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: r3 - 2007-06-29 - 06:41:51 - 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