[00:17:16] 10Phabricator: Request for updates to Discovery-related phabricator herald rules - https://phabricator.wikimedia.org/T129954#2120978 (10ksmith) [00:24:43] 10Phabricator: Determining whether and when to close an open Phabricator Maniphest task - https://phabricator.wikimedia.org/T129952#2121012 (10greg) That's a fair skepticism. Is there a situation where someone other than the reporter could close it when the reporter disagrees? [00:41:21] 10Phabricator: Determining whether and when to close an open Phabricator Maniphest task - https://phabricator.wikimedia.org/T129952#2121033 (10Krenair) Absolutely, yes. Assuming that all tasks are software-related (I know that's not the case now, which makes these things a little more complicated - although perh... [16:13:06] 10Phabricator, 6Operations, 6Project-Admins, 6Triagers: Requests for addition to the #acl*Project-Admins group (in comments) - https://phabricator.wikimedia.org/T706#2122884 (10mcruzWMF) Hi, me and @Ocaasi would like to become project managers. We are working together on the Wikimedia Resource Center, a si... [16:15:40] 10Phabricator, 6Operations, 6Project-Admins, 6Triagers: Requests for addition to the #acl*Project-Admins group (in comments) - https://phabricator.wikimedia.org/T706#2122904 (10Aklapper) @mcruzWMF, @Ocaasi: Are you planning to regularly create projects in Phabricator or change the settings of those project... [16:20:12] 10Phabricator, 6Operations, 6Project-Admins, 6Triagers: Requests for addition to the #acl*Project-Admins group (in comments) - https://phabricator.wikimedia.org/T706#2122918 (10mcruzWMF) >>! In T706#2122904, @Aklapper wrote: > @mcruzWMF, @Ocaasi: Are you planning to regularly create projects in Phabricator... [17:25:56] twentyafterfour: greg-g ostriches have you seen https://secure.phabricator.com/T10262 [17:26:12] my instinct is upstream is going to nuke the protected files setup [17:27:47] nope haven't seen it but I thought all along that it would cause "universal performance problems" [17:27:48] might need csteipp input too? :-/ [17:30:03] yeah, I'm sub'd, we should interact on that ticket :) [17:30:03] bad idea from the start [17:30:19] * twentyafterfour agrees with epriestley on this one [17:30:25] Also, ew, I don't like the new task screen there [17:30:33] it does make me uneasy for security attachments to be hard to discovery vs impossible to access [17:30:39] but I don't have a good solution either atm [17:31:44] everything I've thought comes down to don't do that as in stop attachments in the open to sec tickets and put them elsewhere [17:31:58] I think when we looked into it there were not that many [17:32:02] it's a shitty problem [17:33:17] patches (literal .patch files) are the main use-case I think, sometimes there's screenshots with sensitive info, but I think we can optimize for one over the other (/me would want csteipp to confirm) [17:33:37] I can't think of another place we control securely that non-NDA'd people could drop a potentially leaky security report into. [17:34:06] Like, anyone with an NDA could potentially drop them on $SOME_HOST, but that doesn't work for reporters who often want to view or have such files themselves. [17:35:04] right it's turtles all teh way down [17:35:23] iirc and twentyafterfour could confirm teh status quo was a lot of negotiation w/ csteipp [18:15:55] ostriches: thanks for https://gerrit.wikimedia.org/r/#/c/275855/ that was a total tick from my last job and gave me some nastalgia but yeah silly [18:16:13] Hehe :) [19:56:39] twentyafterfour: chasemp: i merged a change that is supposed to whitelist some domains to create tickets in a project, like it works for an existing project. 1 line change https://gerrit.wikimedia.org/r/#/c/276923/4/modules/role/manifests/phabricator/main.pp [19:56:46] just that it seems this does not take effect yet [19:56:57] is it possible that a service has to be restarted manually? [19:57:26] i know that email ticket creation works in principle.. as long as it comes from @wikimedia.org [19:57:29] mutante: no it doesn't work like that, i can take a look but for some reason I thought we weren't goin to whitelist here for complexity sake [19:57:45] but it changes a config file on disk that gets read if a mail triggers that rule essentially [19:57:53] so it's point in time [19:58:46] i really don't know, i just fixed the part in exim, added a rewrite rule [19:58:53] that makes phabricator accept the mails now [19:59:10] and then i could show it works when we send the mail ourselves [19:59:21] and then i was pointed to that whitelist [20:00:41] I don't think maint-announce is using this, i think it's using the stock phab behavior [20:01:25] I think instead of direct comments you want [20:01:27] # Direct route an email to new tasks associated with [20:01:27] # a project. [20:01:27] [address_routing] [20:01:29] = [20:03:03] ok, so maint-announce is not using anything yet, because phabricator did not accept mail tickets in general because the 'phabricator' part was missing in the to: headers [20:03:36] ah, also that changeset is changing direct comment which is for vendors you probably want address_routing which is for anon task creation [20:03:36] fyi [20:03:54] ohhh, yeah [20:03:58] that makes sense. [20:04:08] mutante: so i always create the task in advance for procurement vendor CCing [20:04:15] in fact, it was a requirement, as we didnt want them making tickets. [20:04:39] where for maint-announce, we do in fact want to allow task creation into that space, but not wholly anon. [20:04:51] we'd like to whitelist it to specific domains since we know the vendors in advacne. [20:05:12] if we opened it up to the world, it would get a lot of spam. rt already does. [20:05:48] So, we want a little bit of the general task creation by email, but restricted in a similar domain list to #procurement (but not identical). [20:05:57] i'm not sure i follow [20:06:30] the code we updated for maint-announce only allows those vendors to comment onto existing tasks by emailing the task#@phabricator.wikiemdia.org [20:06:49] which isnt what we wanted, we want them to generate a new task by emailing maint-announce@ [20:07:35] (not sure if that clarifies?) [20:07:59] becausse we just copied what #procurement does. [20:08:45] a little bit, yea, so i don't know how that can be added. maybe we could first just migrate the feature like in RT? [20:09:13] thts what chase was pointing out, we have to look at address routing, i have not messed with it either [20:09:20] but we already implement it to allow anon task creation [20:10:18] * robh is assuming. [20:10:28] i'm reverting my change. i also note you guys know a lot more details than i do [20:10:43] well, i just realized what chase was pointing out sooner [20:10:51] it didnt connect until he explained it just now. [20:12:53] not sure how to implement said recommendation, still reading through our config but i dont see it yet [20:13:51] from https://secure.phabricator.com/T10262: "Naive question, but would it be possible to have a new "disable security theater" setting and have Phab then do "Unique URL Hash + Fully Cacheable Resources" like everyone else?" [20:16:29] Sorry I would would help with the email routing stuff but I am even more clueless, I haven't ever used RT and wasn't involved in the phab email setup [20:16:53] it has not much to do with RT at this point [20:17:57] yea, nothing to do with rt. we just wanna way to email into maint-announce@phabricator.wikimedia.org and have it generate tasks in the right project and space. [20:18:15] which already works [20:18:20] as long as the emails come from wikimedia.org [20:21:25] (in this space, too) [21:07:22] 10Differential, 7Documentation: Document use of Owners in Phabricator and advertise it - https://phabricator.wikimedia.org/T128372#2124418 (10greg) [21:07:26] 5Gerrit-Migration, 10Gitblit-Deprecate, 10Phabricator, 10ArchCom-RfC, and 4 others: [RfC]: Migrate code review / management to Phabricator from Gerrit - https://phabricator.wikimedia.org/T119908#2124417 (10greg) [21:07:40] 10Differential, 5Gerrit-Migration, 7Documentation: Document use of Owners in Phabricator and advertise it - https://phabricator.wikimedia.org/T128372#2072003 (10greg) [21:07:52] 10Differential, 5Gerrit-Migration, 7Documentation: Document use of Owners in Phabricator and advertise it - https://phabricator.wikimedia.org/T128372#2072003 (10greg) p:5Triage>3Normal [21:18:33] 10Differential, 10Phabricator-Upstream: Differential notification emails lack headers for repository and state change - https://phabricator.wikimedia.org/T117186#2124449 (10greg) After reading Evan's reply upstream again (https://secure.phabricator.com/T9891#146631) I don't think this should be a hard blocker... [21:53:13] 5Gerrit-Migration, 10Phabricator, 13Patch-For-Review, 7Puppet, 7WorkType-Maintenance: Configure backula to backup the /srv/phab/repos directory - https://phabricator.wikimedia.org/T120045#2124601 (10Dzahn) ``` [helium:~] $ sudo bconsole Connecting to Director helium.eqiad.wmnet:9101 1000 OK: helium.eqiad... [21:54:08] 5Gerrit-Migration, 10Phabricator, 7Puppet, 7WorkType-Maintenance: Configure backula to backup the /srv/phab/repos directory - https://phabricator.wikimedia.org/T120045#2124604 (10Dzahn) [21:57:37] ^ no real backup without showing how to restore :p [22:03:50] mutante: :) :) [22:04:37] 5Gerrit-Migration, 7Documentation: Update Commit Message Guidelines for phab - https://phabricator.wikimedia.org/T123081#2124655 (10greg) p:5Triage>3Normal [22:14:31] 5Gerrit-Migration: Ability for a privileged application to provide test status of a commit - https://phabricator.wikimedia.org/T190#2124683 (10greg) This actually happens right now with Jenkins and the rMSCA repository, see eg D145. {F3639909} Done via buildplans, eg https://phabricator.wikimedia.org/harbormast... [22:15:05] 10Differential, 5Gerrit-Migration: Ability for a privileged application to provide test status of a commit - https://phabricator.wikimedia.org/T190#2124685 (10greg) [23:02:40] 5Gerrit-Migration, 6Repository-Admins, 10pywikibot-core: Migrate Pywikibot to Differential code review - https://phabricator.wikimedia.org/T95526#2124900 (10greg) >>! In T95526#2124446, @greg wrote: > (NB: I removed that project from here because except for odd circumstances we won't have a task per reposito... [23:03:31] I redid the #gerrit-migration workboard to use type-of-task columns instead of backlog->doing->done: https://phabricator.wikimedia.org/project/board/9/ [23:03:50] I think it makes it easier to see what we have left to do [23:19:31] yea, so i looked at this again. i don't think it's phabricator::mailrelay and address_routing afaict [23:19:58] because mail already ends up in this project [23:21:06] and i don't understand yet how "phab_bot" is related to this [23:25:55] mutante: eh? [23:28:50] we would like to whitelist some domains that can create tickets, in addition to wikimedia.org [23:28:55] then we could stop using RT [23:28:59] (for context) [23:29:08] ah [23:29:15] it's like 95% of it works [23:29:20] oh, sorry, I missed the convo due to all of my spam :) [23:29:23] except just from wikimedia.org [23:30:14] and i found this example for using phabricator::mailrelay [23:30:20] and that has this part: [23:30:27] 24 # phab_bot => { root_dir => '/srv/phab/phabricator/', [23:30:28] 25 # username => 'phabot', [23:30:33] that's why i said phab_bot [23:36:08] the mailrelay class i got pointed to is already used in the phab role class. that's the change i reverted. so yea, i don't know how this works