Architecture meetings/Security guidelines discussion 2014-06-13

From MediaWiki.org
Jump to navigation Jump to search

1500 UTC Friday 13 June at #wikimedia-office connect.


Text to review[edit]

Security for developers/Architecture

Summary and logs[edit]

Meeting summary[edit]

  • LINK: https://www.mediawiki.org/wiki/Security_for_developers/Architecture (sumanah, 15:02:23)
  • ACTION: csteipp "IP address or UserAgent of editors" should be rephrased. (sumanah, 15:04:27)
  • ACTION: : Update "stuff we're trying to protect" to be more clear about the threat model (csteipp, 15:11:22)
  • ACTION: threat models should call out private wikis-- where confidentiality is more important than integrity, vs. public wikis. (csteipp, 15:19:18)
  • IDEA: Sam Smith suggests: i think including security requirements (gathered during the assessment phase) should be part of the [Trello/Mingle/Phabricator/Bugzilla] ticket (sumanah, 15:31:16)
  • ACTION: "For a long time, MediaWiki" needs to be more specific (superm401, 15:36:40)
  • ACTION: Section about conflict between security and other requirements, and thoughts on where to address those in the process (csteipp, 15:37:30)
  • IDEA: bring up 'whenever a new card/ticket/thing is created with a user story and a requirements section simply add a distinct "Security requirements" section to it; as a team you'd have to commit to giving the security requirements the same weight as the other requirements' on https://lists.wikimedia.org/mailman/listinfo/teampractices ? (sumanah, 15:41:14)
  • IDEA: <parent5446> It'd be nice if Phabricator has some sort of security planning widget. I wonder if such an app exists. (sumanah, 15:41:58)
  • ACTION: csteipp add https://gerrit.wikimedia.org/r/#/c/138572/16/MathRenderer.php,cm as a bad example of "Secure (fail-safe) defaults" - the new Match CAPTCHA was used as a default (per mutante) (sumanah, 15:51:28)
  • <csteipp> sumanah: I think at the architecture level, we need to stress integration with anti-spam. But the exact methods there are going to be very narrow, and probably not applicable to 99% of developers. (sumanah, 15:52:14)
  • "Minimize the attack surface" - we've always been pretty stingy on allowed file types, partly for security. (sumanah, 15:53:55)
  • LINK: http://www.cs.virginia.edu/~evans/cs551/saltzer/ (sumanah, 15:56:57)
  • <zwol> closely related principle: in API design, the _easiest_, _most normal_ thing to do should also be the secure thing. Sometimes you need to allow people to do something unusual that is less secure, but then they should have to jump through extra hoops to demonstrate (to themselves and to future readers of the code) that they have thought about it and understand the implications. (sumanah, 15:59:11)
  • LINK: http://pyvideo.org/video/2647/designing-poetic-apis - the bit about building shoulders for the road is applicable here! http://www.slideshare.net/ErikRose/poetic-apis is the slides (sumanah, 15:59:35)
  • LINK: http://thecodelesscode.com/case/148 <-- nominally about caching, but just substitute security and it's the same principle (zwol, 16:05:08)
  • LINK: http://thecodelesscode.com/case/138 <-- why is computer so hard anyway? (zwol, 16:05:30)
  • LINK: http://thecodelesscode.com/case/140 <-- "Code as if everyone is the thief." (zwol, 16:05:43)


Action items[edit]

  • csteipp "IP address or UserAgent of editors" should be rephrased.
  • Update "stuff we're trying to protect" to be more clear about the threat model
  • threat models should call out private wikis-- where confidentiality is more important than integrity, vs. public wikis.
  • "For a long time, MediaWiki" needs to be more specific
  • Section about conflict between security and other requirements, and thoughts on where to address those in the process
  • csteipp add https://gerrit.wikimedia.org/r/#/c/138572/16/MathRenderer.php,cm as a bad example of "Secure (fail-safe) defaults" - the new Match CAPTCHA was used as a default (per mutante)


Action items, by person[edit]

  • csteipp
  • **UNASSIGNED** (but probably Chris Steipp)
    • Update "stuff we're trying to protect" to be more clear about the threat model
    • threat models should call out private wikis-- where confidentiality is more important than integrity, vs. public wikis.
    • "For a long time, MediaWiki" needs to be more specific
    • Section about conflict between security and other requirements, and thoughts on where to address those in the process


Full log[edit]