[13:23:58] infobliss: so any updates? [13:24:22] yeah I am almost done with writing the code [13:24:27] k [13:24:35] should be posting it on github today [13:24:40] ok [13:24:58] experimenting with some inheritance related things now [13:25:14] k [13:26:13] also https://github.com/infobliss/sibutest2/blob/master/libraries/infobox_templates.py#L59 [13:26:43] passing a simple dictionary may not work here [13:27:46] I ma formatting it appropriatedly so that the data can be filled as desired. [13:28:15] I am formatting it appropriately so that the data can be filled as desired. [13:28:42] I still don't think a single .format worth an entire function [13:29:25] may be [13:30:00] some more work is necessary other than a single .format [13:30:17] such as? [13:31:27] I mean just passing a dict with the given keys is not doing the job of getting the template filled [13:32:00] why not? [13:32:13] it's supposed to [13:32:33] do you think 'parameters' is a dict? [13:32:41] ok [13:32:49] yeah [13:33:16] or you can def fill_art_photo_template(**parameters): [13:33:40] I wrote some tests where it did not get the values as desired [13:33:44] ok I will try [13:33:52] can I see? [13:34:00] I mean the tests [13:34:07] the expected and actual results [13:34:13] let me check where I placed the files [13:34:22] it should be in this machine [13:34:25] k [13:36:06] unfortunately not in this machine but give me a minute [13:36:12] I will rewrite here [13:36:14] k [13:43:37] https://gist.github.com/infobliss/d2bcb4498c0b211069fa5f3df8d4415a [13:44:01] * zhuyifei1999_ tests [13:45:17] ... [13:45:28] you printed the template itself [13:45:44] not with the filled data [13:46:28] ok yes [13:46:47] :P [13:47:13] very silly [13:47:24] lol [13:51:20] oh fyi I broke the security of one part of tool labs today ;) [13:51:31] * zhuyifei1999_ admits that I'm showing off [13:51:59] hahaha how did you do that horrible thing? [13:52:52] that's not horrible when you don't abuse it but rather report it so it can be fixed [13:53:57] * zhuyifei1999_ was trying to prove the print that https://wikitech.wikimedia.org/wiki/Help:Tool_Labs#Security (redis) is bad security [13:54:04] I mean you saved horrible things from happening [13:54:42] I don't think I can reveal how to do it until it get fixed, probably in a few hours [13:55:16] aah yes :D [13:55:59] the report is https://phabricator.wikimedia.org/T169957 [13:56:23] "Access Denied: Restricted Task" [13:56:53] yeah, it might be un-hide once it is fixed [13:57:26] ok good security measure [13:58:13] but it is literally three lines, one to a documentation page, one to tool labs configuration demonstrating how it is wrongly configured, one says "Proof of concept:", and after that is a paste [13:59:25] the paste literally contains forever-sensitive data (live redis keys), so I don't imagine it ever gets un-hide [14:00:48] what are the possible security breaches if this remained unfixed? [14:01:06] it's probably the third tool-labs-wide security ticket I submitted [14:01:24] oh, I can control the cache of some tools [14:01:47] if some tools use redis as session storage, I might be able to steal sessions [14:02:15] basically anything you can use redis for I can corrupt it [14:02:36] so v2c is also under threat [14:02:42] redis is a fast key-value storage if you are unaware [14:02:57] v2c use another password-protected redis server [14:03:08] video-redis, under video project [14:03:12] so it is unaffected [14:03:36] this bug affect those using the non-password protected server tools-redis [14:04:55] ok I see [14:04:57] oh and my first ticket is an NFS setuid exploit, basically setuid to anyone on tool labs :) [14:05:12] which was fixed but never got un-hide [14:06:23] the second has not been fixed due to the difficulty of fixing, and I don't think I can say too much about it [14:06:31] you could have been a great detective ;) [14:06:36] oh :P [14:07:26] all I can say about the second ticket is that it will allow you to act on another user's behalf on tool labs tools without them noticing [14:08:24] first is https://phabricator.wikimedia.org/T153073 second is https://phabricator.wikimedia.org/T157450 [14:08:28] I am not aware of many things. So is it possible for you to change code of sibutest in toollabs? [14:08:44] with? [14:09:46] I mean just access and chage [14:10:09] oh about second ticket I meant oauth users [14:10:45] without finding and exploiting more bugs I'm afraid I can't cange code of sibutest [14:10:53] *change [14:11:06] hahaha :) [14:11:15] the first bug will allow it though [14:11:15] well said [14:12:05] the second, I might be able to spam using your account on some wikis :P (that's the extreme case) [14:12:39] without getting discovered as a later stage? [14:12:45] at [14:13:22] oh the attack could be made hard to discover [14:13:40] if I can "decorate" it as if I'm innocent [14:13:54] cold-hearted :P [14:14:20] nah I won't do that of course [14:14:35] Yeah I know. [14:14:43] but some real bag guys may do so [14:14:47] *bad [14:15:06] won't you fix it ? [14:15:48] fix what? [14:16:00] 2nd one [14:16:26] I don't think I can tell you why it cannot be fixed at the current stage [14:17:22] ok [14:17:40] the task depends on a visible task [14:18:26] I think I will need a strong cup of coffee to understand the details. [14:18:41] and may be more experience [14:18:58] it isn't that complicated [14:19:32] let me find a random task that has a dependency [14:22:03] man, that's harder than I thought [14:22:30] ok [14:23:17] ok, so https://phabricator.wikimedia.org/T154102 depends on https://phabricator.wikimedia.org/T153488 [14:23:35] um, this task graph is more complex than usual [14:24:33] https://phabricator.wikimedia.org/T169774 depends on https://phabricator.wikimedia.org/T169736 [14:24:52] oh, "tool labs" is being renamed to "toolforge" fyi [14:25:16] nice [14:25:49] what is the philosophy behind the name though? [14:25:49] just imagine a public ticket, like "https://phabricator.wikimedia.org/T169736", but in the task graph, you don't see "Open None T169774 Toolforge data loss for permissive data July 2 2017" [14:26:05] in its place you see "Restricted Task" [14:26:43] the renaming? https://wikitech.wikimedia.org/wiki/User:BryanDavis/Rebranding_Cloud_Services_products [14:28:04] I don't see "Restricted Task" either [14:28:15] ? [14:28:26] sorry it was another task [14:29:11] I mean bug #2 depends on a public task, and if you view the task graph of that public task you'll see a "Restricted Task" [14:30:09] and that public task is why bug #2 cannot be fixed [14:30:38] I think I can see the task "T169774 Toolforge data loss for permissive data July 2 2017" too [14:30:52] in the task graph [14:30:53] well, it's an example of a task dependency [14:31:40] if you see a task dependency that have "Restricted Task" in the place of "T169774 Toolforge data loss for permissive data July 2 2017" you might be at the right place :P [14:32:20] got it [14:33:12] I cannot tell you which task it is because I think you're smart enough that given all the information I told you and the information available in that public task you might be able to figure out what bug #2 is about [14:33:20] :P [14:34:20] may be but rest assured that I won't exploit anything in any case. [14:34:59] oh well you'll lose trust in tool labs if you see it :P just kidding [14:35:59] now we will have 'toolforge' :P [14:36:34] oh yeah it's part of the plan in 'toolforge' migration [14:36:47] so right 'toolforge' will fix it [14:37:20] yeah foreseeable [14:37:39] oh wait, I think I can give you an example of what the "restricted task" dependency looks like [14:40:50] yeah https://phabricator.wikimedia.org/T104453 is an example [14:40:57] but not this one [14:41:19] ok [14:42:55] oh and that "restricted task" in https://phabricator.wikimedia.org/T104453 is not a security task, but an nda (privacy-related) task [14:43:30] ok I see [14:45:49] I think I can show you the first bug though, if you want [14:46:54] I honestly don't know why it is still hidden and I didn't get a response when I asked to unhide it (I don't have the permission to unhide it myself) [14:47:46] ok [14:48:45] need a brb [14:49:28] https://usercontent.irccloud-cdn.com/file/V170DhsP/Firefox_Screenshot_2017-07-07T14-49-06.920Z.png [14:50:02] ok nice [14:50:17] will come back and look deep [14:50:22] k [14:50:36] tell me how you think about it :P [15:11:20] I am back [15:11:27] sure let me check now [15:12:14] k [15:20:10] ok NFS is Network File System [15:20:15] yeah [15:20:53] tool labs use nfs to make sure every instance gets the same files for /data/project, /home, /data/scratch [15:21:23] see https://wikitech.wikimedia.org/wiki/Help:Shared_storage [15:21:24] ok [15:22:11] hmm I only knew NFS=Need For Speed ;) [15:22:18] o.O [15:22:28] I didn't know that [15:22:49] a video game [15:22:56] oh [15:23:54] well, coc=code of conduct and clash of clans :) [15:24:21] one is what you see on tech places, one is a video game [15:24:55] haha yep [15:25:00] fyi, tool labs may get rid of nfs in the very distant future [15:25:17] so yours was a good trick [15:25:37] a few years ago, almost every single labs outage was caused by NFS meltdown [15:25:42] ? [15:25:47] mine what? [15:26:00] to read the secret data [15:26:42] um, it's more of an exploit than a trick I'd say [15:27:33] yes may be [15:27:44] I don't know the exact usage of the two [15:28:04] i.e., when to call a trick and when an exploit [15:28:15] imo, trick = good, exploit = bad [15:28:29] aah ok