Item12325: Tasks need a new priority for security items

The recent security fire drills have persuaded me that Tasks (the web work item) need a 'Security' priority and associated restricted permissions.

At present, it's too hard to work on a security issue without making the issue and any work in progress visible to anyone.

My recommendations:

• Add a 'Security' priority to tasks.
• Restrict 'Security' items to anyone on Reported By or Waiting For, and the security team.
• Restrict Trac access to the same list for any checkin to a Security item.
• Same for the github export, twiki-checkins mailing list and public IRC feed.
• Consider a restricted 'Security' branch - auto-synced to trunk, except for open security items. This is probably the easiest way to implement restrictions.
• Remove all these restrictions once a fix has been finalized and deployed.

This isn't ironclad - but it would go a long way toward making it easier to securely work on security issues...

-- TimotheLitt - 02 Jan 2013

This might more deserve a Development topic and then address individual issues in tasks. But at least for the Tasks system this seems all a good idea and could probably be implemented with a save handler

• Add a new priority: Security
• Add a plugin with a save handler.
  • If Priority = security, set a ALLOWTOPICVIEW for the original creator and the SecurityGroup.
  • If priority changed to not be Security, remove the ALLOWTOPICVIEW setting
  • When topic is "Closed", also remove the ALLOWTOPIC VIEW.

I believe that by controlling ALLOWTOPICVIEW, the WebNotify and RSS feeds would work themselves out.

The automatic email on checkin, I think the hooks are in SVN, and could possibly be changed to send email to the foswiki-security list for any checkin listing a task with the Security priority.

• tools/develop/hooks/commit-email.pl
• tools/develop/hooks/post-commit

As far as trac, and tie-in with git, and/or conversion from svn from git, I don't really know.

-- GeorgeClark - 02 Jan 2013

Yes, a save handler seems like a good hook for implementing this.

I think the ALLOWTOPICVIEW needs to include the creator, anyone added to "Reported by" (It can be a list of interested parties) and "Waiting for." That allows people with particular expertise, 'ownership' or who are impacted by an issue to be added to an item without expanding the security core team. Seems like a cheap way to form a focus team for the issue.

My point on e-mail is that checkins to security items should not be sent to the usual list, as they disclose an issue in process.

Unpatched security vulnerabilities are one area where the 'open' in open software has to compromised for a short time to serve the public interest.

Feel free to take this to the right forum.

-- TimotheLitt - 02 Jan 2013

FoswikiOrgPlugin implements the handler to set topic ACLs based on Priority: Security.

Given the move to github, we don't really have an easy way to generate private security repositories. They are a premium feature of github.

Closed.

-- GeorgeClark - 06 Jan 2015

Commenting is disabled while not logged in