HomePhabricator

RFC Meeting: Security is all of our jobs (2016-06-01, #wikimedia-office)
ActivePublic

Hosted by daniel on Jun 1 2016, 9:00 PM - 10:00 PM.

Description

  • Location: #wikimedia-office IRC channel
  • Meeting type: Problem definition
  • Time: Weekly, Wednesday 21:00 UTC (2pm PDT, 23:00 CEST)

Agenda

Theme this week: Security:

(further discussion: {Z425} and on wikitech-l)

Architecture meetings
13:00 PT ArchCom Planning Meetingsupcomingall since 2016-03-30
14:00 PT ArchCom-RFC Meetingsupcomingall since 2015-09-09

T123753: Establish retrospective reports for Security and Performance-Team incidents

Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-06-01-21.01.html
Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-06-01-21.01.txt
Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-06-01-21.01.wiki
Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-06-01-21.01.log.html

#wikimedia-office: ArchCom Security RFC meeting https://phabricator.wikimedia.org/E198

Meeting started by robla at 21:01:08 UTC (full logs).

Meeting summary

Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (robla, 21:01:36)
T123753 (robla, 21:09:11)
ACTION: robla propose a location for where reports go (robla, 21:10:24)

T135963 (robla, 21:15:17)
Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (robla, 21:22:04)
<gwicke> if there are no concerns about 0-4, then we could record that fact & start moving on those (no objections raised in response) (robla, 21:28:15)
<bawolff> Can we move to discussing stages 4-6 of rfc? [...] I'd like to know if anyone see's any major show stoppers (robla, 21:34:58)
bawolff asks if we can merge CSP code into MediaWiki, even if it isn't enabled. no objection seemed to be given (robla, 21:38:03)
<SMalyshev> CSP code meaning generating code or reporting code or both? <bawolff> meant both (robla, 21:40:01)
<bawolff> On the topic of retrospectives we were discussing earlier, for teams who have a specific extension they are responsible for, I think it would be nice to clarify their responsibilities for doing security releases of that extension (assuming its a non-bundled extension) (robla, 21:48:29)
https://phabricator.wikimedia.org/T135963 CSP RFC (robla, 21:49:39)
https://phabricator.wikimedia.org/T133735 (bawolff, 21:51:02)
https://phabricator.wikimedia.org/E203 <-next week's conversation (robla, 21:55:50)
next week's discussion T89331 Replace Tidy in MW parser with HTML 5 parse/reserialize (robla, 21:58:13)

Meeting ended at 21:59:50 UTC (full logs).

Action items

robla propose a location for where reports go

People present (lines said)

bawolff (49)
robla (43)
brion (36)
gwicke (27)
TimStarling (23)
DanielK_WMDE__ (12)
jzerebecki (11)
SMalyshev (10)
stashbot (7)
dapatrick (6)
mutante (4)
Platonides (4)
Scott_WUaS (3)
wm-labs-meetbot` (3)
bd808 (2)
MaxSem (2)
subbu (1)
Matthew_ (1)
qgil (1)

Generated by MeetBot 0.1.4.

121:01:08 <robla> #startmeeting ArchCom Security RFC meeting https://phabricator.wikimedia.org/E198
221:01:08 <wm-labs-meetbot`> Meeting started Wed Jun 1 21:01:08 2016 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot.
321:01:08 <wm-labs-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
421:01:08 <wm-labs-meetbot`> The meeting name has been set to 'archcom_security_rfc_meeting_https___phabricator_wikimedia_org_e198'
521:01:09 <brion> just a note -- phab folks are actually pretty responsive to small feature reqs if we pay them. ;)
621:01:24 <brion> we may or may not have used up our existing contracting credits, check with qgil :)
721:01:36 <robla> #topic Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/
821:01:51 <robla> hi folks!
921:01:53 <Matthew_> brion: Noted. I may open a task later asking for exactly that.
1021:01:57 <brion> +1
1121:02:51 <jzerebecki> will we do T123753 first?
1221:02:52 <stashbot> T123753: Establish retrospective reports for #security and #performance incidents - https://phabricator.wikimedia.org/T123753
1321:03:14 <robla> jzerebecki: that'd be wonderful....
1421:03:56 <robla> to be clear, we're not planning a consensus-based meeting on it, but Krinkle believes we can pull that off at next week's meeting
1521:04:31 <jzerebecki> these days https://coreos.com/blog/security-brief-coreos-linux-alpha-remote-ssh-issue.html has gone around
1621:04:45 <jzerebecki> a retrospective on a grave security bug
1721:04:50 <robla> gwicke felt like the first couple of steps of this RFC are really clear, but believes subsequent steps deserve more discussion (gwicke, please correct me if I have that right)
1821:05:03 * robla looks at jzerebecki's link
1921:05:25 <jzerebecki> "The issue went undetected during pre-merge review. To avoid situations like this in the future, we are concentrating on development of more comprehensive automated testing. Our verification tests now perform a series of additional security checks,"
2021:05:43 <jzerebecki> " We have also taken the opportunity to introduce stronger image validation during the system image build process, automatically flagging packages with reported security issues. We will also ensure that security-related changes are accompanied by appropriate tests."
2121:06:17 <gwicke> the first steps of the CSP RFC are low consequence preparations / information gathering, which I think are pretty uncontroversial
2221:06:40 <robla> jzerebecki: oops, I only just figured out you were talking about postmortems. Excellent, thank you! :-) I thought you were talking about the CSP one, and I suspect gwicke is commenting on that.
2321:07:30 <jzerebecki> ah yes that CSP seems like a worthwhile thing on first look is pretty uncontroversial
2421:07:31 <TimStarling> where should the reports go?
2521:07:37 * robla gets his 6-digit numbers confused
2621:07:56 <bawolff> TimStarling: The CSP violation reports?
2721:08:16 <TimStarling> sorry, I am one RFC behind, the retrospective reports for security incidents
2821:08:18 <robla> TimStarling: I'm not sure. I could be convinced of either wikitech.wikimedia.org or mediawiki.org
2921:08:29 <bd808> TimStarling: I think that's a good question. I'm a bit concerned that the current logging pipeline may melt with them being processed by an action api endpoint.
3021:08:47 * bd808 is on the wrng topic
3121:08:58 <TimStarling> yeah, I'm sure it was a good comment for any RFC
3221:08:58 * robla fails at chairing
3321:09:11 <robla> #topic T123753
3421:09:11 <stashbot> T123753: Establish retrospective reports for #security and #performance incidents - https://phabricator.wikimedia.org/T123753
3521:09:34 <brion> :)
3621:09:37 <bawolff> I actually have a response to that question, but I'll wait until we get to that rfc
3721:09:45 <robla> (we'll spend no more than 10-15 minutes on this one, and then move to the CSP one)
3821:09:53 <brion> ok do we need things like: where do the reports go ;), how long before they get made, etc
3921:10:24 <robla> #action robla propose a location for where reports go
4021:10:24 <Platonides> I think wikitech
4121:10:25 <brion> and if a report falls behind, do we need a fallback path?
4221:10:46 <Platonides> some would be suited for mediawiki too, but others will be wmf-specific
4321:10:47 <brion> eg who gets poked until it gets done ;)
4421:10:55 <brion> or who does the poking, alternately
4521:11:11 <jzerebecki> I think the most controversial thing on security incidents or even incidents reports in general is how to ensure that the actionables are done, as in being funded.
4621:11:11 <robla> brion: I think it's sort of a percentage score thing. Some reports may never get done, and that's ok
4721:11:43 <bawolff> What sort of actionables do you have in mind?
4821:11:47 <brion> jzerebecki: ah for 'next steps to prevent this crap from getting worse' vs just 'and here's what we did to fix it so far'?
4921:12:06 <jzerebecki> brion: yes
5021:12:09 <bawolff> There's a big difference between - introduce automated testing for this type of security issue, vs fix the XSS in particular
5121:12:16 <bawolff> *this particular xss
5221:12:19 <bawolff> or whatever the issue is
5321:12:47 <robla> I think postmortems are still useful even if we don't have anyone slavishly enforcing "strict adherance" to the process
5421:13:04 <gwicke> the thing I keep wondering about when I look at this RFC is how security and performance post-mortems should differ from regular outage / incident post-mortems
5521:13:30 <robla> gwicke: they should probably be more same than different
5621:13:33 <Scott_WUaS> (@jzerebecki and security-oriented Wikidatans - what planning is occurring in terms of MIT-informed bitcoin and blockchain and in all countries' main and official languages - and re code security ... as well as, to re-construe the word "security" a kind of financial security for WMF and Wikdiata, for example?)
5721:14:05 <bawolff> what?
5821:14:13 <gwicke> robla: would it make sense to rephrase it as a refinement on post-mortem policies in general?
5921:14:43 <jzerebecki> bawolff: robla i agree that postmortems are useful anyway
6021:14:45 <gwicke> what works well / what doesn't, proposed changes etc
6121:14:53 <robla> I think we've really handled as much of this topic as we should. Let's take further discussion back to Phab on T123753, and discuss CSP
6221:14:53 <stashbot> T123753: Establish retrospective reports for #security and #performance incidents - https://phabricator.wikimedia.org/T123753
6321:15:05 * robla goes to find the CSP task num
6421:15:11 <robla> T135963
6521:15:12 <stashbot> T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki - https://phabricator.wikimedia.org/T135963
6621:15:17 <robla> #topic T135963
6721:15:17 <stashbot> T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki - https://phabricator.wikimedia.org/T135963
6821:15:18 <Scott_WUaS> (@bawolff - Is there any planning with the WMF Foundation for possible engagement with MIT's Bitcoin and Blockchain - and re security?)
6921:15:36 <robla> Scott_WUaS: probably not a great topic for this meeting
7021:15:39 <SMalyshev> re CSP, is this supposed to be configured somehow in wiki settings?
7121:16:06 <Scott_WUaS> (@robla - thanks)
7221:16:15 <bawolff> To answer TimStarling's question, I imagine on initial deployment, we might only show the report-only header to say like 0.01% of users to prevent servers from melting wiht initial reports, until things start to become fixed
7321:16:23 <SMalyshev> if so, how and who gets to define them (i.e. wiki admins, ops, etc.)?
7421:16:26 <bawolff> SMalyshev: yes
7521:17:04 <bawolff> SMalyshev: I imagine that all Wikimedia would basically have a consistent setting, where wikimedia sites are allowed and others aren't
7621:17:14 <brion> presumably ops defines them, in consultation with the community as we progress through the steps outlined in the rfc
7721:17:25 <gwicke> I would expect there to eventually be defaults that just workTM, but the first steps are partly about figuring out what those defaults might be; admins / ops shouldn't need to worry about configuring CSP headers manually
7821:17:32 <Platonides> 0.01% of users → most of them will be given to users unable to understand/fix it
7921:18:01 <SMalyshev> ok, got it - but given the variety of weird code - including local and per-user JS - I wonder how much breakage this can cause
8021:18:09 <brion> but yes, i would not expect different settings per wiki or anything
8121:18:11 <bawolff> Platonides: I mean in so-called "report only" mode, where the web browser sends a json thingy to the api, but otherwise does not inform the user of the issue (unless they look in js console)
8221:18:23 <TimStarling> I suppose existing uses of inline scripts would be migrated to use the nonce feature?
8321:18:30 <brion> SMalyshev: have you read the rfc? there's some specific issues outlined, and a recommendation to use reporting mode to gather more info
8421:18:56 <bawolff> TimStarling: The existing inline scripts RL uses would be. Stuff extensions do would be changed to use standard RL functions
8521:18:59 <brion> some gadgets and user js will break that uses offsite resources, and will need to be updated.
8621:19:14 <bawolff> I've already implemented a change for CharInsert extension to make it work with this
8721:19:18 <brion> \o/
8821:19:29 <bawolff> Any inliney stuff that user scripts do will break
8921:19:30 <MaxSem> I think that we should eventually forbid cross-wiki script loading at all, this would drastically shrink the proposed header
9021:19:50 <gwicke> I would propose to defer the discussion on the later stages for now, as it would benefit from having more information gathered in the first stages
9121:19:51 <MaxSem> this would require Gadgets 2.0
9221:20:12 <DanielK_WMDE__> would it make sense to test this on logged in users first? they know better how to communicate issues
9321:20:18 <DanielK_WMDE__> (and are used to suffering...)
9421:20:36 <brion> DanielK_WMDE__: logged in users are most likely to use gadgets or scripts that would break
9521:20:43 <brion> logged out users by definition have no gadgets or user scripts
9621:20:45 <gwicke> to me, anything up to including CSP on upload (images, SVG etc) seems fairly low-risk
9721:20:56 <brion> upload is super safe yeah
9821:21:07 <DanielK_WMDE__> brion: there are default gadgets, but yea. that's kind of the point: test the cases that are most likely to break.
9921:21:07 <brion> i have plans to make svg more flexible but i think this shouldn't break that
10021:21:13 <TimStarling> mashup gadgets might not always be able to change the domain name they use for resources
10121:21:22 <brion> DanielK_WMDE__: *nod* sensible
10221:21:33 <brion> that reminds me --
10321:21:36 <TimStarling> we would have to either break them or whitelist them
10421:21:37 <SMalyshev> yeah makes sense for logged-in users...
10521:21:55 <DanielK_WMDE__> TimStarling: or proxy them
10621:22:00 <brion> is there a way to opt in to a break through the policy, perhaps isolated in iframes, under specific circumstances?
10721:22:04 <robla> #topic Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/
10821:22:10 <DanielK_WMDE__> not that i like that option. but it's an option
10921:22:14 <TimStarling> I'm thinking of closed-source scripts that are only available in minified form, that have domain names for secondary resources hard-coded within them
11021:22:18 <bawolff> DanielK_WMDE__: Ideally we put it in test mode first, so by the time its actually turned on in "real" mode, everything for anons (since they all have the same set of js) is fixed
11121:22:24 <TimStarling> then you can't even proxy
11221:22:29 <gwicke> stage 5 (enforce CSP on testwiki) looks like the first one that might be controversial
11321:22:44 <TimStarling> unless you intercept document modifications or something
11421:22:54 <bawolff> gwicke: I agree, that's when things start to become hairy
11521:22:59 <brion> i've looked into DOM proxying it looks like hell ;)
11621:23:13 <DanielK_WMDE__> TimStarling: ick. do we even want them to work?...
11721:23:20 <bawolff> brion: Stuff in an iframe is mostly controlled by that documents CSP
11821:23:33 <gwicke> does anyone have general concerns about stages 0 - 4?
11921:23:35 <bawolff> except for the part of csp that limits what iframe's to use
12021:23:59 <brion> bawolff: *nod* that'd be ideal for mashups that 'need' that sort of thing... but we don't want a generic attacker to inject iframes any more than we want them to inject tracker pixels do we?
12121:24:08 <brion> so we'd need an opt-in of some kind?
12221:24:36 <bawolff> brion: yep, but that's really the tail end of this proposal
12321:24:41 <brion> i suppose we could tweak the iframe permissions in the header per-user after a confirmation checkin
12421:24:49 <brion> yeah i'll ponder that and propose an amendmend for late stages
12521:25:13 <gwicke> if there are no concerns about 0-4, then we could record that fact & start moving on those
12621:25:28 <brion> (CSP also fixes the remaining hole in my crazy ideas for sandboxed JS widgets, so this is all very interesting to me!)
12721:25:30 <brion> +1
12821:26:06 * robla doesn't know how to communicate partial approval of RFCs
12921:26:11 <gwicke> this is reporting & enforcing for upload
13021:26:26 <DanielK_WMDE__> robla: "no objections raised"?
13121:26:34 <bawolff> stage 4 is actually reporting on testwiki
13221:27:03 <TimStarling> it would suck to have to include *.wikimedia.org, maybe better to just move all those wikis?
13321:27:18 <TimStarling> find a new 2LD for them?
13421:27:24 <gwicke> bawolff: yeah, I had a different associativity in mind ;)
13521:27:52 <DanielK_WMDE__> TimStarling: give commons a new domain? uuuuhhhhhh....
13621:27:53 <TimStarling> for the less important ones anyway, commons can probably stay where it is
13721:28:15 <robla> #info <gwicke> if there are no concerns about 0-4, then we could record that fact & start moving on those (no objections raised in response)
13821:28:23 <TimStarling> I'm searchcom, for example, which IIRC is the search committee for ED selection which chose Sue Gardner
13921:28:26 <bawolff> TimStarling: That would actually improve security generally, there's ways to use an XSS on foo.wikimedia.org to attack bar.wikimedia.org
14021:28:33 <qgil> brion, I just saw your ping. I don't know what is the problem with time conversion, but if it is related to Calendar, bug reports / feature requests are welcome (there are many filed already)
14121:28:39 <TimStarling> *I'm thinking
14221:29:03 <bawolff> maybe instead of moving wikis off *.wikimedia.org we could move everything else to *.wikimedia-etc.org or something
14321:29:20 <brion> qgil: thx!
14421:29:41 <TimStarling> don't forget there is *.wiki now
14521:29:59 <DanielK_WMDE__> bawolff: like wikimedia-files.org, wikimedia-bits.org, etc?
14621:30:10 <bawolff> Well bits is dead now (I think)
14721:30:15 <bawolff> but yeah
14821:30:21 <TimStarling> could have searchcom.wmf.wiki
14921:30:28 <SMalyshev> there will be w.wiki for url shortener IIRC
15021:30:29 <DanielK_WMDE__> TimStarling: do we have any .wiki domains?
15121:30:35 <bawolff> e.g. ganglia.wikimedia.org being on not *.wikimedia.org
15221:30:38 <Platonides> DanielK_WMDE__: better to use wikimedia.bit
15321:30:48 <TimStarling> DanielK_WMDE__: we have some I think
15421:30:49 <DanielK_WMDE__> heh
15521:30:55 <mutante> DanielK_WMDE__: yes, we have each language code in .wiki
15621:30:59 <mutante> until recently
15721:31:29 <DanielK_WMDE__> mutante: but not pedia.wiki? shame...
15821:31:31 <mutante> maybe they got dropped now and we just keep w.wiki, that is for sure for the url shortener
15921:31:31 <SMalyshev> w.wiki actually works :)
16021:31:32 <bawolff> (I have some more specific reasons why I think it'd be cool to move stuff off *.wikimedia.org, but they're written on secret https://phabricator.wikimedia.org/T113790#1676633 )
16121:32:26 <mutante> SMalyshev: yep, but it needs the rules to becoma shortner
16221:32:55 <bawolff> So umm, this is kind of getting off topic...
16321:33:41 <bawolff> Can we move to discussing stages 4-6 of rfc?
16421:33:49 <gwicke> bawolff: do you think it would make sense to go ahead with phases 0..4, and then revisit based on the information gathered in the process?
16521:34:13 <bawolff> I think so, I'd like to know if anyone see's any major show stoppers though
16621:34:56 <brion> bawolff: nothing scaring me beyond what's already mentioned
16721:34:58 <robla> #info <bawolff> Can we move to discussing stages 4-6 of rfc? [...] I'd like to know if anyone see's any major show stoppers
16821:35:10 <bawolff> Also, for having the support in MW, is there agreement enough that its a cool idea, to merge the CSP header generation code into mw, even if its not yet decided for sure how/when we'll enable
16921:35:11 <brion> we'll have to work with folks on updating gadgets and scripts though
17021:35:16 <bawolff> yes
17121:35:21 <brion> and/or provide an opt-in compatibility mode that reduces the restrictions
17221:35:39 <bawolff> I expect it will be a long haul for getting this fully enabled
17321:35:49 <brion> i say yes definitely merge the code in
17421:35:55 <brion> the better to test it in real-ish places
17521:36:15 <gwicke> I'm also not too worried in principle; we'll have to work out the exact CSP headers, but I'm optimistic that we can find something that strikes a good balance between functionality for gadgets etc & security
17621:36:46 <bawolff> Ideally I think I'd like to see this sort of thing happen wiki by wiki (Oh it appears that there are no more violation reports coming from frwiki, lets turn it on there, etc)
17721:36:59 <gwicke> and that balance might change gradually over time, in response to alternatives becoming available etc
17821:38:03 <robla> #info bawolff asks if we can merge CSP code into MediaWiki, even if it isn't enabled. no objection seemed to be given
17921:38:46 <SMalyshev> CSP code meaning generating code or reporting code or both? just curious
18021:38:53 * bawolff meant both
18121:39:07 <SMalyshev> ah, ok.
18221:39:23 <SMalyshev> RFC says some CSP will be in Varnish, so I wasn't sure
18321:39:44 <gwicke> a reporting end point would be useful for RB CSP reports as well; currently, we only enforce, but don't report
18421:39:56 <bawolff> RB?
18521:40:01 <robla> #info <SMalyshev> CSP code meaning generating code or reporting code or both? <bawolff> meant both
18621:40:03 <gwicke> RESTBase / the REST API
18721:40:50 <bawolff> ah, should have been able to guess that acronym
18821:41:08 <gwicke> for example, all the SVG math images are served with CSP headers disallowing any kind of JS already
18921:41:21 <gwicke> same with HTML
19021:41:25 <brion> nice
19121:41:26 <bawolff> RB can certainly use the endpoint if it wants to
19221:43:21 <TimStarling> I will have some comments on the "Initial support for CSP" change in gerrit
19321:43:57 <bawolff> \o/
19421:44:35 <robla> bawolff: dapatrick : would you like to keep discussing this issue, or do you think there are other security issues we should discuss here?
19521:44:49 <bawolff> dpatrick is not in channel afaik
19621:44:58 <dapatrick> I'm in the channel.
19721:45:01 <dapatrick> Lurking.
19821:45:04 <robla> :-)
19921:45:10 <bawolff> ah, I didn't see your username on the list
20021:45:32 <dapatrick> I defer to bawollf.
20121:45:41 * bawolff thinks the current topic is pretty much discussed out
20221:45:41 <dapatrick> *bawolff
20321:46:26 <robla> I'd be pretty happy if y'all set the agenda for the next few ArchCom meetings, to be honest :-)
20421:46:56 <TimStarling> I assume we're not going to have CSP next week now
20521:47:16 * robla gives dapatrick and bawolff license to be extra pushy in https://phabricator.wikimedia.org/Z425
20621:47:21 <bawolff> On the topic of retrospectives we were discussing earlier, for teams who have a specific extension they are responsible for, I think it would be nice to clarify their responsibilities for doing security releases of that extension (assuming its a non-bundled extension)
20721:48:29 <robla> #info <bawolff> On the topic of retrospectives we were discussing earlier, for teams who have a specific extension they are responsible for, I think it would be nice to clarify their responsibilities for doing security releases of that extension (assuming its a non-bundled extension)
20821:48:56 <dapatrick> bawolff Can you give an example of such an extension?
20921:48:56 <gwicke> often, the question is exactly about the "who is responsible" bit
21021:49:14 <bawolff> I'm thinking specificly about recent issue in mobile frontend
21121:49:29 <bawolff> where there was a lot of unclarity over who has responsibility, and what best practises are
21221:49:39 <robla> #link https://phabricator.wikimedia.org/T135963 CSP RFC
21321:49:53 <jzerebecki> the same issue comes up with every non-feature work
21421:50:00 * bawolff is trying to find the bug
21521:50:16 <gwicke> related: https://phabricator.wikimedia.org/T122825
21621:51:02 <bawolff> https://phabricator.wikimedia.org/T133735
21721:51:33 <gwicke> at some point, we need to establish clearer minimum maintenance / ownership requirements for anything in production / semi-production
21821:51:40 <robla> gwicke: are you proposing that the Security team should own services? ;-)
21921:51:44 <gwicke> and enforce those
22021:52:40 <jzerebecki> gwicke: suggestion for the point?
22121:52:52 <gwicke> robla: the RFC is pointing out the problem of needing clear ownership, and *not* pushing it to some catch-all team like services or security
22221:53:40 <bawolff> Anyways, in the event of a security incident in an extension that's used widely (but not bundled) and has a specific owner, I'd like to see the owner be responsible for doing official announcements of the security issue
22321:53:46 <robla> gwicke: sure, I'm just ribbing you :-) I think the catch is figuring out ownership of the hundreds of things already deployed
22421:54:29 <gwicke> robla: yup, we are familiar with that discussion (ex: OCG)
22521:54:31 <SMalyshev> last committer owns it ;)
22621:54:49 <dapatrick> bawolff I fully agree with the need to figure this out.
22721:54:50 <robla> we should probably start winding up though, since we have potential to wind into another long discussion
22821:55:06 <bawolff> gwicke: Maybe its difficult for the past, but it'd certainly be nice for that to be a requirement before deploying (although I was sort of under the impression that was already the case)
22921:55:50 <robla> #link https://phabricator.wikimedia.org/E203 <-next week's conversation
23021:56:01 * bawolff also certainly hasn't prepared a concrete proposal for sec release of non-bundled extensions
23121:56:06 <gwicke> bawolff: agreed, it's easier to enforce for new things
23221:56:36 <gwicke> we definitely treat clear ongoing ownership as a requirement for new service deploys we are part of
23321:56:37 <TimStarling> we can have T89331 next week if you like
23421:56:38 <stashbot> T89331: Replace Tidy in MW parser with HTML 5 parse/reserialize - https://phabricator.wikimedia.org/T89331
23521:56:50 <brion> +1 i like
23621:57:38 <robla> TimStarling: that seems reasonable. maybe we can follow up on postmortems the following week? (just penciled in)
23721:58:05 <TimStarling> ok
23821:58:13 <robla> #info next week's discussion T89331 Replace Tidy in MW parser with HTML 5 parse/reserialize
23921:58:13 <stashbot> T89331: Replace Tidy in MW parser with HTML 5 parse/reserialize - https://phabricator.wikimedia.org/T89331
24021:58:23 <TimStarling> and the week after that will be wikimania
24121:59:04 <robla> great! I think that may be a wrap. we can end dozens of seconds early this week too! \o/
24221:59:13 <TimStarling> subbu: we are bringing forward the depurate discussion, see above
24321:59:43 <subbu> sounds good.
24421:59:44 <robla> priority discussions can happen on Z425
24521:59:50 <robla> #endmeeting

Recurring Event

Event Series
This event is an instance of E66: ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office), and repeats every week.

Event Timeline

Relevant discussion occurred in last week's meeting (E187), which is logged in P3179 (last 15 minutes, starting around line 140).

Candidates discussed: T91137, T351, T96384, T382, T75953, T135963

The plan was to continue the conversation on Z425, and attempt to decide something there.

RobLa-WMF updated the event description. (Show Details)May 27 2016, 11:23 PM
RobLa-WMF renamed this event from RFC Meeting: <topic TBD> (<see "Starts" field>, #wikimedia-office) to RFC Meeting: <topic TBD> (2016-06-01, #wikimedia-office).
RobLa-WMF updated the event description. (Show Details)Jun 1 2016, 5:58 PM
RobLa-WMF renamed this event from RFC Meeting: <topic TBD> (2016-06-01, #wikimedia-office) to RFC Meeting: Security is all of our jobs (2016-06-01, #wikimedia-office).Jun 1 2016, 6:00 PM
RobLa-WMF updated the event description. (Show Details)Jun 1 2016, 10:09 PM
daniel renamed this event from RFC Meeting: Security is all of our jobs (2016-06-01, #wikimedia-office) to ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office).Nov 21 2016, 6:11 PM
daniel changed the host of this event from RobLa-WMF to daniel.
daniel invited: ; uninvited: .
daniel updated the event description. (Show Details)
daniel updated the event description. (Show Details)Dec 9 2016, 7:43 AM
daniel renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to RFC Meeting: Security is all of our jobs (2016-06-01, #wikimedia-office).