- 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:
- T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki
- T75953: RFC: MediaWiki HTTPS policy
- T123753: Establish retrospective reports for #security and #performance incidents
- (other candidates nominated last week, but maybe slightly off-topic: T91137, T351, T96384, T382)
(further discussion: {Z425} and on wikitech-l)
| Architecture meetings | ||
|---|---|---|
| 13:00 PT ArchCom Planning Meetings | upcoming | all since 2016-03-30 |
| 14:00 PT ArchCom-RFC Meetings | upcoming | all 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.
| 1 | 21:01:08 <robla> #startmeeting ArchCom Security RFC meeting https://phabricator.wikimedia.org/E198 |
|---|---|
| 2 | 21: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. |
| 3 | 21:01:08 <wm-labs-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 4 | 21:01:08 <wm-labs-meetbot`> The meeting name has been set to 'archcom_security_rfc_meeting_https___phabricator_wikimedia_org_e198' |
| 5 | 21:01:09 <brion> just a note -- phab folks are actually pretty responsive to small feature reqs if we pay them. ;) |
| 6 | 21:01:24 <brion> we may or may not have used up our existing contracting credits, check with qgil :) |
| 7 | 21: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/ |
| 8 | 21:01:51 <robla> hi folks! |
| 9 | 21:01:53 <Matthew_> brion: Noted. I may open a task later asking for exactly that. |
| 10 | 21:01:57 <brion> +1 |
| 11 | 21:02:51 <jzerebecki> will we do T123753 first? |
| 12 | 21:02:52 <stashbot> T123753: Establish retrospective reports for #security and #performance incidents - https://phabricator.wikimedia.org/T123753 |
| 13 | 21:03:14 <robla> jzerebecki: that'd be wonderful.... |
| 14 | 21: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 |
| 15 | 21:04:31 <jzerebecki> these days https://coreos.com/blog/security-brief-coreos-linux-alpha-remote-ssh-issue.html has gone around |
| 16 | 21:04:45 <jzerebecki> a retrospective on a grave security bug |
| 17 | 21: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) |
| 18 | 21:05:03 * robla looks at jzerebecki's link |
| 19 | 21: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," |
| 20 | 21: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." |
| 21 | 21:06:17 <gwicke> the first steps of the CSP RFC are low consequence preparations / information gathering, which I think are pretty uncontroversial |
| 22 | 21: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. |
| 23 | 21:07:30 <jzerebecki> ah yes that CSP seems like a worthwhile thing on first look is pretty uncontroversial |
| 24 | 21:07:31 <TimStarling> where should the reports go? |
| 25 | 21:07:37 * robla gets his 6-digit numbers confused |
| 26 | 21:07:56 <bawolff> TimStarling: The CSP violation reports? |
| 27 | 21:08:16 <TimStarling> sorry, I am one RFC behind, the retrospective reports for security incidents |
| 28 | 21:08:18 <robla> TimStarling: I'm not sure. I could be convinced of either wikitech.wikimedia.org or mediawiki.org |
| 29 | 21: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. |
| 30 | 21:08:47 * bd808 is on the wrng topic |
| 31 | 21:08:58 <TimStarling> yeah, I'm sure it was a good comment for any RFC |
| 32 | 21:08:58 * robla fails at chairing |
| 33 | 21:09:11 <robla> #topic T123753 |
| 34 | 21:09:11 <stashbot> T123753: Establish retrospective reports for #security and #performance incidents - https://phabricator.wikimedia.org/T123753 |
| 35 | 21:09:34 <brion> :) |
| 36 | 21:09:37 <bawolff> I actually have a response to that question, but I'll wait until we get to that rfc |
| 37 | 21:09:45 <robla> (we'll spend no more than 10-15 minutes on this one, and then move to the CSP one) |
| 38 | 21:09:53 <brion> ok do we need things like: where do the reports go ;), how long before they get made, etc |
| 39 | 21:10:24 <robla> #action robla propose a location for where reports go |
| 40 | 21:10:24 <Platonides> I think wikitech |
| 41 | 21:10:25 <brion> and if a report falls behind, do we need a fallback path? |
| 42 | 21:10:46 <Platonides> some would be suited for mediawiki too, but others will be wmf-specific |
| 43 | 21:10:47 <brion> eg who gets poked until it gets done ;) |
| 44 | 21:10:55 <brion> or who does the poking, alternately |
| 45 | 21: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. |
| 46 | 21:11:11 <robla> brion: I think it's sort of a percentage score thing. Some reports may never get done, and that's ok |
| 47 | 21:11:43 <bawolff> What sort of actionables do you have in mind? |
| 48 | 21: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'? |
| 49 | 21:12:06 <jzerebecki> brion: yes |
| 50 | 21:12:09 <bawolff> There's a big difference between - introduce automated testing for this type of security issue, vs fix the XSS in particular |
| 51 | 21:12:16 <bawolff> *this particular xss |
| 52 | 21:12:19 <bawolff> or whatever the issue is |
| 53 | 21:12:47 <robla> I think postmortems are still useful even if we don't have anyone slavishly enforcing "strict adherance" to the process |
| 54 | 21: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 |
| 55 | 21:13:30 <robla> gwicke: they should probably be more same than different |
| 56 | 21: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?) |
| 57 | 21:14:05 <bawolff> what? |
| 58 | 21:14:13 <gwicke> robla: would it make sense to rephrase it as a refinement on post-mortem policies in general? |
| 59 | 21:14:43 <jzerebecki> bawolff: robla i agree that postmortems are useful anyway |
| 60 | 21:14:45 <gwicke> what works well / what doesn't, proposed changes etc |
| 61 | 21: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 |
| 62 | 21:14:53 <stashbot> T123753: Establish retrospective reports for #security and #performance incidents - https://phabricator.wikimedia.org/T123753 |
| 63 | 21:15:05 * robla goes to find the CSP task num |
| 64 | 21:15:11 <robla> T135963 |
| 65 | 21:15:12 <stashbot> T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki - https://phabricator.wikimedia.org/T135963 |
| 66 | 21:15:17 <robla> #topic T135963 |
| 67 | 21:15:17 <stashbot> T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki - https://phabricator.wikimedia.org/T135963 |
| 68 | 21: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?) |
| 69 | 21:15:36 <robla> Scott_WUaS: probably not a great topic for this meeting |
| 70 | 21:15:39 <SMalyshev> re CSP, is this supposed to be configured somehow in wiki settings? |
| 71 | 21:16:06 <Scott_WUaS> (@robla - thanks) |
| 72 | 21: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 |
| 73 | 21:16:23 <SMalyshev> if so, how and who gets to define them (i.e. wiki admins, ops, etc.)? |
| 74 | 21:16:26 <bawolff> SMalyshev: yes |
| 75 | 21:17:04 <bawolff> SMalyshev: I imagine that all Wikimedia would basically have a consistent setting, where wikimedia sites are allowed and others aren't |
| 76 | 21:17:14 <brion> presumably ops defines them, in consultation with the community as we progress through the steps outlined in the rfc |
| 77 | 21: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 |
| 78 | 21:17:32 <Platonides> 0.01% of users → most of them will be given to users unable to understand/fix it |
| 79 | 21: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 |
| 80 | 21:18:09 <brion> but yes, i would not expect different settings per wiki or anything |
| 81 | 21: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) |
| 82 | 21:18:23 <TimStarling> I suppose existing uses of inline scripts would be migrated to use the nonce feature? |
| 83 | 21: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 |
| 84 | 21:18:56 <bawolff> TimStarling: The existing inline scripts RL uses would be. Stuff extensions do would be changed to use standard RL functions |
| 85 | 21:18:59 <brion> some gadgets and user js will break that uses offsite resources, and will need to be updated. |
| 86 | 21:19:14 <bawolff> I've already implemented a change for CharInsert extension to make it work with this |
| 87 | 21:19:18 <brion> \o/ |
| 88 | 21:19:29 <bawolff> Any inliney stuff that user scripts do will break |
| 89 | 21:19:30 <MaxSem> I think that we should eventually forbid cross-wiki script loading at all, this would drastically shrink the proposed header |
| 90 | 21: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 |
| 91 | 21:19:51 <MaxSem> this would require Gadgets 2.0 |
| 92 | 21:20:12 <DanielK_WMDE__> would it make sense to test this on logged in users first? they know better how to communicate issues |
| 93 | 21:20:18 <DanielK_WMDE__> (and are used to suffering...) |
| 94 | 21:20:36 <brion> DanielK_WMDE__: logged in users are most likely to use gadgets or scripts that would break |
| 95 | 21:20:43 <brion> logged out users by definition have no gadgets or user scripts |
| 96 | 21:20:45 <gwicke> to me, anything up to including CSP on upload (images, SVG etc) seems fairly low-risk |
| 97 | 21:20:56 <brion> upload is super safe yeah |
| 98 | 21: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. |
| 99 | 21:21:07 <brion> i have plans to make svg more flexible but i think this shouldn't break that |
| 100 | 21:21:13 <TimStarling> mashup gadgets might not always be able to change the domain name they use for resources |
| 101 | 21:21:22 <brion> DanielK_WMDE__: *nod* sensible |
| 102 | 21:21:33 <brion> that reminds me -- |
| 103 | 21:21:36 <TimStarling> we would have to either break them or whitelist them |
| 104 | 21:21:37 <SMalyshev> yeah makes sense for logged-in users... |
| 105 | 21:21:55 <DanielK_WMDE__> TimStarling: or proxy them |
| 106 | 21:22:00 <brion> is there a way to opt in to a break through the policy, perhaps isolated in iframes, under specific circumstances? |
| 107 | 21: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/ |
| 108 | 21:22:10 <DanielK_WMDE__> not that i like that option. but it's an option |
| 109 | 21: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 |
| 110 | 21: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 |
| 111 | 21:22:24 <TimStarling> then you can't even proxy |
| 112 | 21:22:29 <gwicke> stage 5 (enforce CSP on testwiki) looks like the first one that might be controversial |
| 113 | 21:22:44 <TimStarling> unless you intercept document modifications or something |
| 114 | 21:22:54 <bawolff> gwicke: I agree, that's when things start to become hairy |
| 115 | 21:22:59 <brion> i've looked into DOM proxying it looks like hell ;) |
| 116 | 21:23:13 <DanielK_WMDE__> TimStarling: ick. do we even want them to work?... |
| 117 | 21:23:20 <bawolff> brion: Stuff in an iframe is mostly controlled by that documents CSP |
| 118 | 21:23:33 <gwicke> does anyone have general concerns about stages 0 - 4? |
| 119 | 21:23:35 <bawolff> except for the part of csp that limits what iframe's to use |
| 120 | 21: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? |
| 121 | 21:24:08 <brion> so we'd need an opt-in of some kind? |
| 122 | 21:24:36 <bawolff> brion: yep, but that's really the tail end of this proposal |
| 123 | 21:24:41 <brion> i suppose we could tweak the iframe permissions in the header per-user after a confirmation checkin |
| 124 | 21:24:49 <brion> yeah i'll ponder that and propose an amendmend for late stages |
| 125 | 21:25:13 <gwicke> if there are no concerns about 0-4, then we could record that fact & start moving on those |
| 126 | 21: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!) |
| 127 | 21:25:30 <brion> +1 |
| 128 | 21:26:06 * robla doesn't know how to communicate partial approval of RFCs |
| 129 | 21:26:11 <gwicke> this is reporting & enforcing for upload |
| 130 | 21:26:26 <DanielK_WMDE__> robla: "no objections raised"? |
| 131 | 21:26:34 <bawolff> stage 4 is actually reporting on testwiki |
| 132 | 21:27:03 <TimStarling> it would suck to have to include *.wikimedia.org, maybe better to just move all those wikis? |
| 133 | 21:27:18 <TimStarling> find a new 2LD for them? |
| 134 | 21:27:24 <gwicke> bawolff: yeah, I had a different associativity in mind ;) |
| 135 | 21:27:52 <DanielK_WMDE__> TimStarling: give commons a new domain? uuuuhhhhhh.... |
| 136 | 21:27:53 <TimStarling> for the less important ones anyway, commons can probably stay where it is |
| 137 | 21: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) |
| 138 | 21:28:23 <TimStarling> I'm searchcom, for example, which IIRC is the search committee for ED selection which chose Sue Gardner |
| 139 | 21: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 |
| 140 | 21: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) |
| 141 | 21:28:39 <TimStarling> *I'm thinking |
| 142 | 21:29:03 <bawolff> maybe instead of moving wikis off *.wikimedia.org we could move everything else to *.wikimedia-etc.org or something |
| 143 | 21:29:20 <brion> qgil: thx! |
| 144 | 21:29:41 <TimStarling> don't forget there is *.wiki now |
| 145 | 21:29:59 <DanielK_WMDE__> bawolff: like wikimedia-files.org, wikimedia-bits.org, etc? |
| 146 | 21:30:10 <bawolff> Well bits is dead now (I think) |
| 147 | 21:30:15 <bawolff> but yeah |
| 148 | 21:30:21 <TimStarling> could have searchcom.wmf.wiki |
| 149 | 21:30:28 <SMalyshev> there will be w.wiki for url shortener IIRC |
| 150 | 21:30:29 <DanielK_WMDE__> TimStarling: do we have any .wiki domains? |
| 151 | 21:30:35 <bawolff> e.g. ganglia.wikimedia.org being on not *.wikimedia.org |
| 152 | 21:30:38 <Platonides> DanielK_WMDE__: better to use wikimedia.bit |
| 153 | 21:30:48 <TimStarling> DanielK_WMDE__: we have some I think |
| 154 | 21:30:49 <DanielK_WMDE__> heh |
| 155 | 21:30:55 <mutante> DanielK_WMDE__: yes, we have each language code in .wiki |
| 156 | 21:30:59 <mutante> until recently |
| 157 | 21:31:29 <DanielK_WMDE__> mutante: but not pedia.wiki? shame... |
| 158 | 21:31:31 <mutante> maybe they got dropped now and we just keep w.wiki, that is for sure for the url shortener |
| 159 | 21:31:31 <SMalyshev> w.wiki actually works :) |
| 160 | 21: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 ) |
| 161 | 21:32:26 <mutante> SMalyshev: yep, but it needs the rules to becoma shortner |
| 162 | 21:32:55 <bawolff> So umm, this is kind of getting off topic... |
| 163 | 21:33:41 <bawolff> Can we move to discussing stages 4-6 of rfc? |
| 164 | 21: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? |
| 165 | 21:34:13 <bawolff> I think so, I'd like to know if anyone see's any major show stoppers though |
| 166 | 21:34:56 <brion> bawolff: nothing scaring me beyond what's already mentioned |
| 167 | 21: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 |
| 168 | 21: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 |
| 169 | 21:35:11 <brion> we'll have to work with folks on updating gadgets and scripts though |
| 170 | 21:35:16 <bawolff> yes |
| 171 | 21:35:21 <brion> and/or provide an opt-in compatibility mode that reduces the restrictions |
| 172 | 21:35:39 <bawolff> I expect it will be a long haul for getting this fully enabled |
| 173 | 21:35:49 <brion> i say yes definitely merge the code in |
| 174 | 21:35:55 <brion> the better to test it in real-ish places |
| 175 | 21: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 |
| 176 | 21: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) |
| 177 | 21:36:59 <gwicke> and that balance might change gradually over time, in response to alternatives becoming available etc |
| 178 | 21: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 |
| 179 | 21:38:46 <SMalyshev> CSP code meaning generating code or reporting code or both? just curious |
| 180 | 21:38:53 * bawolff meant both |
| 181 | 21:39:07 <SMalyshev> ah, ok. |
| 182 | 21:39:23 <SMalyshev> RFC says some CSP will be in Varnish, so I wasn't sure |
| 183 | 21:39:44 <gwicke> a reporting end point would be useful for RB CSP reports as well; currently, we only enforce, but don't report |
| 184 | 21:39:56 <bawolff> RB? |
| 185 | 21:40:01 <robla> #info <SMalyshev> CSP code meaning generating code or reporting code or both? <bawolff> meant both |
| 186 | 21:40:03 <gwicke> RESTBase / the REST API |
| 187 | 21:40:50 <bawolff> ah, should have been able to guess that acronym |
| 188 | 21:41:08 <gwicke> for example, all the SVG math images are served with CSP headers disallowing any kind of JS already |
| 189 | 21:41:21 <gwicke> same with HTML |
| 190 | 21:41:25 <brion> nice |
| 191 | 21:41:26 <bawolff> RB can certainly use the endpoint if it wants to |
| 192 | 21:43:21 <TimStarling> I will have some comments on the "Initial support for CSP" change in gerrit |
| 193 | 21:43:57 <bawolff> \o/ |
| 194 | 21: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? |
| 195 | 21:44:49 <bawolff> dpatrick is not in channel afaik |
| 196 | 21:44:58 <dapatrick> I'm in the channel. |
| 197 | 21:45:01 <dapatrick> Lurking. |
| 198 | 21:45:04 <robla> :-) |
| 199 | 21:45:10 <bawolff> ah, I didn't see your username on the list |
| 200 | 21:45:32 <dapatrick> I defer to bawollf. |
| 201 | 21:45:41 * bawolff thinks the current topic is pretty much discussed out |
| 202 | 21:45:41 <dapatrick> *bawolff |
| 203 | 21:46:26 <robla> I'd be pretty happy if y'all set the agenda for the next few ArchCom meetings, to be honest :-) |
| 204 | 21:46:56 <TimStarling> I assume we're not going to have CSP next week now |
| 205 | 21:47:16 * robla gives dapatrick and bawolff license to be extra pushy in https://phabricator.wikimedia.org/Z425 |
| 206 | 21: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) |
| 207 | 21: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) |
| 208 | 21:48:56 <dapatrick> bawolff Can you give an example of such an extension? |
| 209 | 21:48:56 <gwicke> often, the question is exactly about the "who is responsible" bit |
| 210 | 21:49:14 <bawolff> I'm thinking specificly about recent issue in mobile frontend |
| 211 | 21:49:29 <bawolff> where there was a lot of unclarity over who has responsibility, and what best practises are |
| 212 | 21:49:39 <robla> #link https://phabricator.wikimedia.org/T135963 CSP RFC |
| 213 | 21:49:53 <jzerebecki> the same issue comes up with every non-feature work |
| 214 | 21:50:00 * bawolff is trying to find the bug |
| 215 | 21:50:16 <gwicke> related: https://phabricator.wikimedia.org/T122825 |
| 216 | 21:51:02 <bawolff> https://phabricator.wikimedia.org/T133735 |
| 217 | 21:51:33 <gwicke> at some point, we need to establish clearer minimum maintenance / ownership requirements for anything in production / semi-production |
| 218 | 21:51:40 <robla> gwicke: are you proposing that the Security team should own services? ;-) |
| 219 | 21:51:44 <gwicke> and enforce those |
| 220 | 21:52:40 <jzerebecki> gwicke: suggestion for the point? |
| 221 | 21: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 |
| 222 | 21: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 |
| 223 | 21: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 |
| 224 | 21:54:29 <gwicke> robla: yup, we are familiar with that discussion (ex: OCG) |
| 225 | 21:54:31 <SMalyshev> last committer owns it ;) |
| 226 | 21:54:49 <dapatrick> bawolff I fully agree with the need to figure this out. |
| 227 | 21:54:50 <robla> we should probably start winding up though, since we have potential to wind into another long discussion |
| 228 | 21: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) |
| 229 | 21:55:50 <robla> #link https://phabricator.wikimedia.org/E203 <-next week's conversation |
| 230 | 21:56:01 * bawolff also certainly hasn't prepared a concrete proposal for sec release of non-bundled extensions |
| 231 | 21:56:06 <gwicke> bawolff: agreed, it's easier to enforce for new things |
| 232 | 21:56:36 <gwicke> we definitely treat clear ongoing ownership as a requirement for new service deploys we are part of |
| 233 | 21:56:37 <TimStarling> we can have T89331 next week if you like |
| 234 | 21:56:38 <stashbot> T89331: Replace Tidy in MW parser with HTML 5 parse/reserialize - https://phabricator.wikimedia.org/T89331 |
| 235 | 21:56:50 <brion> +1 i like |
| 236 | 21:57:38 <robla> TimStarling: that seems reasonable. maybe we can follow up on postmortems the following week? (just penciled in) |
| 237 | 21:58:05 <TimStarling> ok |
| 238 | 21:58:13 <robla> #info next week's discussion T89331 Replace Tidy in MW parser with HTML 5 parse/reserialize |
| 239 | 21:58:13 <stashbot> T89331: Replace Tidy in MW parser with HTML 5 parse/reserialize - https://phabricator.wikimedia.org/T89331 |
| 240 | 21:58:23 <TimStarling> and the week after that will be wikimania |
| 241 | 21:59:04 <robla> great! I think that may be a wrap. we can end dozens of seconds early this week too! \o/ |
| 242 | 21:59:13 <TimStarling> subbu: we are bringing forward the depurate discussion, see above |
| 243 | 21:59:43 <subbu> sounds good. |
| 244 | 21:59:44 <robla> priority discussions can happen on Z425 |
| 245 | 21:59:50 <robla> #endmeeting |