Policies/Security Policy: Difference between revisions

From KDE Community Wiki
(We don't do dot.kde.org (unless the problem is huge) nor bugtraq because we don't even know what it is :D)
No edit summary
(5 intermediate revisions by 2 users not shown)
Line 5: Line 5:
If an immediate fix is not considered necessary a security alert is issued via [mailto:[email protected] [email protected]].
If an immediate fix is not considered necessary a security alert is issued via [mailto:[email protected] [email protected]].
   
   
If a fix is considered necessary, KDE release coordinators are contacted and KDE vendor packagers, Linux distributors and other prenotification mailing lists are informed once a fix is available that has passed review on [mailto:[email protected] [email protected]]. We then give them a reasonable amount of time to prepare binary packages. After that time we issue a security alert via dot.kde.org, bugtraq and [mailto:[email protected] [email protected]]. Patches in source form and any available updated binaries are published at the same time.
If a fix is considered necessary, KDE release coordinators are contacted and KDE vendor packagers, Linux distributors and other prenotification mailing lists (including [https://mail.kde.org/mailman/listinfo/kde-security-preannounce [email protected]]) are informed once a fix is available that has passed review on [mailto:[email protected] [email protected]]. We then give them a reasonable amount of time to prepare binary packages. After that time we issue a security alert via [mailto:[email protected] [email protected]]. Patches in source form and any available updated binaries are published at the same time.
   
   
All security alerts are published on http://www.kde.org/info/security/.
All security alerts are published on http://www.kde.org/info/security/.


KDE developers that want to join [mailto:[email protected] [email protected]] can send a motivated request to [mailto:[email protected] [email protected]]. Applications will be evaluated on a case by case basis by the current members. The main criteria is the extent to which someone can be helpful in executing the security policy as described here. That includes a willingness not to disclose issues prematurely.
KDE developers that want to join [mailto:[email protected] [email protected]] can send a motivated request to [mailto:[email protected] [email protected]]. Applications will be evaluated on a case by case basis by the current members. The main criteria is the extent to which someone can be helpful in executing the security policy as described here. That includes a willingness not to disclose issues prematurely.
==Process for the Security Team==
* Answer incoming e-mails as soon as possible so people know we are listening to their report
* If needed contact people that know the code in question to get the fix done/checked
* Get a CVE https://cveform.mitre.org/
* Contact [https://mail.kde.org/mailman/listinfo/kde-security-preannounce [email protected]] if we think it's important enough that binaries should be out the same moment of the security is disclosed to give distributors some heads up time
* Agree on an advisory text with the developers and ideally the reporter
* Add advisory announcement the website
** Check out svn+ssh://[email protected]/home/kde/trunk/www/sites/www/info/security
** Add new advisory as a txt file
** Edit index.php to add link to the new advisory, commit
* Issue security alert via [mailto:[email protected] [email protected]]
* Email reporter to make sure she knows the advisory is out


[[Category:Policies]]
[[Category:Policies]]

Revision as of 11:58, 12 November 2017

This policy describes how security related issues are handled after they have been reported to [email protected].

Issues that are brought to the attention of [email protected] are handled discreetly. The issue will be verified and the author/maintainer of the affected code will usually be contacted. If the issue is indeed considered to be a problem the need for an immediate fix is assessed. The security team will also notify affected parties which are known to reuse the affected code.

If an immediate fix is not considered necessary a security alert is issued via [email protected].

If a fix is considered necessary, KDE release coordinators are contacted and KDE vendor packagers, Linux distributors and other prenotification mailing lists (including [email protected]) are informed once a fix is available that has passed review on [email protected]. We then give them a reasonable amount of time to prepare binary packages. After that time we issue a security alert via [email protected]. Patches in source form and any available updated binaries are published at the same time.

All security alerts are published on http://www.kde.org/info/security/.

KDE developers that want to join [email protected] can send a motivated request to [email protected]. Applications will be evaluated on a case by case basis by the current members. The main criteria is the extent to which someone can be helpful in executing the security policy as described here. That includes a willingness not to disclose issues prematurely.

Process for the Security Team

  • Answer incoming e-mails as soon as possible so people know we are listening to their report
  • If needed contact people that know the code in question to get the fix done/checked
  • Get a CVE https://cveform.mitre.org/
  • Contact [email protected] if we think it's important enough that binaries should be out the same moment of the security is disclosed to give distributors some heads up time
  • Agree on an advisory text with the developers and ideally the reporter
  • Add advisory announcement the website
  • Issue security alert via [email protected]
  • Email reporter to make sure she knows the advisory is out