SHARE
TWEET

Untitled

a guest Nov 2nd, 2015 72 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. andreasn        #startmeeting
  2. sub-mod i'm here
  3. mvollmer        .hi mvo
  4. andreasn        .hello andreasn
  5. mvollmer        .hello mvo
  6. andreasn        uh, did it start?
  7. mvollmer        nope
  8. dperpeet_       has it really started?
  9. andreasn        did I run the wrong command?
  10. mvollmer        zodbot isn't here
  11. andreasn        oh
  12. mvollmer        let's do it manually
  13. stefw   .hellomynameis Stef Walter
  14. andreasn        sure, I'll try to collect the notes in a manual fashion
  15. stefw   copy paste?
  16. andreasn        pretty much I guess
  17. stefw   just turn off join/leave notifiactions
  18. and you'll have what you need
  19. andreasn        #topic Agenda
  20. mvollmer        * SOS
  21. stefw   * Continuous Delivery ... while Stef is away
  22. andreasn        * systemd services
  23. mvollmer        * hubbot
  24. let's go?
  25. andreasn        sure
  26. #topic SOS-reports
  27. mvollmer        ok, I have started hacking
  28. first thing was to download big files from a remote machine
  29. this is pretty similar to how we load packages
  30. so I made a cope of that and reduced it to be a simple file server
  31. not sure if that is overkill, but doesn't look too bad
  32. one open issue is that we might want to read files as superuser
  33. i haven't looked into that yet
  34. there is a 'standard' trick that might be an alternative
  35. data:// urls
  36. they can be driven by javascript
  37. but it's going to be ugly for big data
  38. stefw   and there's limits on it
  39. isn't there?
  40. mvollmer        somebody said 4 GiB
  41. stefw   wow, even in IE?
  42. mvollmer        newer versions
  43. stefw   if it works that would be best, no?
  44. dperpeet_       how compatible is that across browsers and platforms?
  45. mvollmer        i don't know
  46. first we need to load the 50 Mibs into the browser, turn it into a 70 Mibs base64 endoced string, and then let the user download it.
  47. i don't think one can feed such a data url incrementally
  48. but it would allow us to get away without changing the bridge
  49. but that's not a huge issue, or is it?
  50. dperpeet_       I think the ability to download stuff would be valuable to have in the bridge
  51. stefw   yeah
  52. dperpeet_       are there security issues around this?
  53. stefw   we have to carefully look at security
  54. mvollmer        so I am using URLS like https://f22:9090/cockpit/@localhost//var/tmp/sosreport-f22.mvo.lan-20151019165830.tar.xz
  55. note, empty package name
  56. maybe too trick
  57. y
  58. stefw   i don't think that'll fly security wise
  59. dperpeet_       downloader package?
  60. stefw   i as an attacker can check for the existence of any file on the victim's system (at the very least)
  61. dperpeet_       that could be disabled
  62. mvollmer        you need to be authenticated
  63. stefw   yes the victim is authenticated
  64. and the attacker is not
  65. dperpeet_       if it's a separate package, an admin could choose to disable it
  66. stefw   but can use the victim's authentication
  67. mvollmer        but the attacker can't open a websocket?
  68. stefw   the victim does that
  69. already has it open
  70. dperpeet_       you could hijack the browser session, right?
  71. stefw   no
  72. just GET requests with the user's cookie
  73. dperpeet_       or just the connections therein
  74. what would be a better way to access the files?
  75. mvollmer        so the fsread1 payload is safe, but the files server is not?
  76. stefw   mvollmer, yes, because it transits the WebSocket which the attacker has no access to
  77. mvollmer        cant you get a new one with the cookie?
  78. stefw   GET requests are broadly accessible ... there's a hundred ways
  79. mvollmer, no, there's origin protection on WebSockets
  80. mvollmer        okay
  81. stefw   that's one of the only reasons WebSockets can be safe
  82. otherwise they would be a routine disaster
  83. we probably need to use a POST
  84. that reposts data received from the server
  85. er, from cockpit-ws
  86. so given all of this it may be worth examining how bad using data:// urls really are
  87. mvollmer        right
  88. what about adding a "publish" method to the bridge, which gives you back a random string, and you can use that random string with a GET?
  89. stefw   yup, or POST is better
  90. mvollmer        okay
  91. stefw   but that's what i'm talking about there ... i think cockpit-ws needs to be involved though
  92. to tighten up security properly
  93. if we were to do this
  94. dperpeet_       we could see if data:// works at all
  95. stefw   dperpeet_, yup
  96. dperpeet_       if it's "only for SOS" I think we're talking about a "minor" usage path for Cockpit
  97. frequency-wise, not import
  98. dperpeet_       so it'd be safe to impose higher requirements regarding the browser
  99. i.e. enough memory
  100. petervo how big are these sos files?
  101. i think that max length varies quite a bit from browser to browser
  102. mvollmer        the one I made without options is about ) Mib
  103. hah
  104. petervo though at least they pretty much support it
  105. mvollmer        9 Mib
  106. dperpeet_       I think this is more of a convenience feature anyway... if you're going to produce 100MiB of data, I think you could copy the data some other way if need be
  107. more important is triggering the report generation
  108. mvollmer        i don't know
  109. dperpeet_       maybe we should look at the limits a bit first?
  110. mvollmer        it would be embarassing to have a button to make the report, but no way to download it
  111. dperpeet_       for data:// urls
  112. mvollmer        yeah, I can do that
  113. dperpeet_       we can add the download file support to the bridge later on
  114. as a separate issue
  115. mvollmer        stefw, so we need to be secure even when the attacker has our cookie?
  116. dperpeet_       and target security concerns there
  117. stefw   mvollmer, the attacker should never get the cookie
  118. but the attacker is running in a browser that has the cookie
  119. mvollmer        i guess I don't have a good model of web security
  120. stefw   the attacker can make the browser do a GET with the cookie, even though the attacker does not have the cookie
  121. the attackers access to the results of the GET may be restricted
  122. but there's plenty that the attacker can infer from the GET request
  123. and only certain mechanisms of producing a GET request are restricted to the current javascript domain
  124. there's a reason we don't use GET for anything important
  125. mvollmer        could we just always return success?
  126. stefw   for example our "/ping" handler, on purpose, does not provide any information about cockpit
  127. mvollmer        but it also has the special cross-origin headers, no?
  128. anyway, I don't need to learn all this here.
  129. stefw   mvollmer, sure, but that's to make legitimate uses easier
  130. i would say we need to figure out the limitations of data:// urls
  131. before we sit down and design a mechanism to do safe GET or POST requests
  132. mvollmer        okay
  133. petervo this seems to say 2M on chrome
  134. https://code.google.com/p/chromium/issues/detail?id=44820#c1
  135. but maybe that's old
  136. mvollmer        I'll try
  137. next topic?
  138. andreasn        yep
  139. # topic Continuous Delivery
  140. stefw   i'll be away at systemd.conf
  141. during the 0.83 release
  142. until now the CD container
  143. and cockpit credentials
  144. have been on my machine
  145. i'd like to move them somewhere else
  146. any suggestions?
  147. dperpeet_       files.cockpit.org?
  148. cockpit-project.org
  149. I mean
  150. stefw   the downside is that's a publicly accessible server
  151. is that a problem?
  152. dperpeet_       it should be fairly secure, as such things go
  153. stefw   yeah, i wouldn't be against that
  154. just figured i'd ask everyone
  155. dperpeet_       worst case is that someone kills the github repo, but we have local copies
  156. do we have another vpn protected server that we can all access?
  157. stefw   we do
  158. but even more people have access to it
  159. so i guess it's a tradeoff that way
  160. mvollmer        as root even, no?
  161. stefw   yup
  162. so i'll use files.cockpit-project.org for now? is everyone okay with that?
  163. mvollmer        yes
  164. dperpeet_       in that case I'm for files.cockpit-project.org, I think the security is sufficient for the current demand
  165. mvollmer        (it's not your personal signing key, right?=
  166. stefw   not mine
  167. cockpit users
  168. mvollmer        ok
  169. stefw   er
  170. cockpit user's
  171. the one that creates the releases, pushes them out, etc.
  172. dperpeet_       if we keep local copies and they become asynchronized, that would be bad
  173. stefw   all done?
  174. andreasn        #topic Systemd Services
  175. dperpeet_       so, I talked with andreasn last week
  176. basically we want to keep the design very close to what it is right now
  177. andreasn        for now at least
  178. dperpeet_       yes
  179. we use the listing pattern
  180. and the expandable rows for each entity (service, timer...)
  181. these then have the info you could previously see by clicking on the item
  182. stefw   do you have a screenshot?
  183. dperpeet_       but now it's tabbed (info, journal) and you don't lose your place in the list
  184. stefw   i can use in my talk?
  185. dperpeet_       I didn't make one before I broke the stuff earlier
  186. I'll have one by tomorrow morning
  187. stefw   cool
  188. andreasn        I'm happy to try things out as soon as you have a branch that works
  189. dperpeet_       the one thing we decided to get rid of is the partition into enabled/disabled/static
  190. instead this can go into the row as a column / extra info
  191. the goal is that besides the current buttons we can add one for "all"
  192. dperpeet_       so you can see the entire list, without bothering about the type
  193. stefw   right, we'll need filters for that shortly
  194. but i guess not in the first revision
  195. dperpeet_       exactly
  196. andreasn        yes
  197. dperpeet_       the current buttons are basically hardwired filters
  198. andreasn        next up?
  199. dperpeet_       on the implementation side, I've used petervo's work in https://github.com/cockpit-project/cockpit/pull/2884 as a template
  200. for the angular singleton pattern
  201. one last thing: poke me about that screenshot if you don't have one by tomorrow morning, stefw
  202. stefw   ok
  203. dperpeet_       thanks!
  204. dperpeet_       (end of topic)
  205. andreasn        #topic hubbot
  206. mvollmer        yep
  207. so
  208. I have shut down hubbot
  209. and run the cockpit-verify container instead
  210. works like a charm
  211. super work, stefw
  212. stefw   yay
  213. andreasn        neat
  214. stefw   i've been thinking of some next steps ... to be tackled later
  215. such as github scanning
  216. mvollmer        yeah
  217. stefw   and coordination between servers, etc
  218. so they can all target all OS's essentially
  219. mvollmer        it's not essential, but still nice to see what the machine is up to
  220. stefw   but lets not get ahead of ourselves
  221. dperpeet_       stefw, we can collaborate some on that on Wednesday
  222. stefw   right, i imagined if we have github scanning
  223. mvollmer        I'd just like to have the output of testinfra.py somewhere
  224. stefw   then we can have the scanner publish a priority list somewhere
  225. mvollmer        yes
  226. stefw   anyway, are we okay with waiting on that for a week?
  227. dperpeet_       as long as the tests work, the status is just a nice addon I think
  228. mvollmer        and the sink could give some nicer view into what it currently running, and was has finished
  229. stefw   or we could put it in an issue
  230. and talk about it therte
  231. well, an idea is to make the sinks even less central to things ... so i hope we can avoid doing too much with the sink
  232. mvollmer        it would also be nice to automate the deployment of the infra-verify container even more
  233. stefw   yeah, maybe using the 'atomic' command
  234. dperpeet_       the scanner could very well be a separate container
  235. stefw   dperpeet_, yes it would be
  236. mvollmer        so I'll properly put hubbot to rest in the next days
  237. stefw   anyway ... i think we've passed a massive milestone
  238. distributed testing is hard ... has been hard ... but we've made it work ... so far
  239. mvollmer        yes, this very very nice
  240. heh, our challange is to test concurrently on a single system :-)
  241. stefw   i'd like to move away from that target
  242. and have each check-verify --github=next pick an OS that the scanner has singled out
  243. mvollmer        by just cranking up the jobs?
  244. stefw   so the scanner goes through github
  245. and marks what needs to be tested
  246. there can be two scanners if we like failover
  247. and then the verify containers, just pick things that need to be tested, and work their way through the list
  248. dperpeet_       stefw, we have to keep an eye on github API calls (there are limits)
  249. it's better to have hooks somewhere
  250. stefw   well that's a separate issue imo
  251. but we can use fedmsg
  252. to proxy github webhooks into messages
  253. as other projects do
  254. anyway, so i guess my point here is that we should do these things one step at a time ... i don't think this is a "stop the presses" style work anymore
  255. mvollmer        I have one more topic: fancy logs
  256. stefw   oh, they're nice
  257. andreasn        sure, end of topic for hubbot?
  258. stefw   and the fact that they can be updated by anyone
  259. mvollmer        yes
  260. andreasn        #topic fancy logs
  261. mvollmer        so, there is now a simple log.html file in .../test/files
  262. it will be dropped into the directory with the log, right from the start
  263. and the "Details" links on github point to it
  264. the idea is that we evolve that page into something really nice
  265. whenever we need a break from the production code :-)
  266. stefw   great
  267. dperpeet_       I very much like the separation of log + display that we now have
  268. stefw   yes, most of the logic is there
  269. just needs styling, right?
  270. dperpeet_       yes
  271. andreasn        I can take a look
  272. stefw   mvollmer, can you link to an example?
  273. dperpeet_       https://fedorapeople.org/groups/cockpit/logs/pull-3112-8e19e155-fedora-22-x86_64/log.html
  274. listing pattern *cough*
  275. mvollmer        adding colors and links to the log might be slightly more involved
  276. mvollmer        yep, that one. :)
  277. andreasn        it's just a big <pre id="log"> right now, right?
  278. mvollmer        one known issue:
  279. the log.html file is pulled from the branch of the pull request
  280. that doesn't work sometimes
  281. and then it just reads "Not found"
  282. stefw   pull from master?
  283. mvollmer        then you can't see your change in action
  284. stefw   i guess it's hard to test out changes
  285. right
  286. so why does it sometimes not work?
  287. mvollmer        i think it's a ..... race
  288. stefw   i would suggest that the urllib call in the sink is doing the wrong thing
  289. it should throw an error
  290. instead of output the contents of 404
  291. mvollmer        raw.github.com might be a slightly slow
  292. dperpeet_       we should catch that an fallback on master... or try again / longer?
  293. mvollmer        yep
  294. stefw   mv,
  295. mvollmer, if the urllib call fails (and we should be able to detct that properly)
  296. leave the extras statement in
  297. and process it again at status end
  298. mvollmer        yes, that'll work
  299. okay, eot
  300. andreasn        # topic Open Floor
  301. stefw   my systemd.conf talk ...
  302. it's short, so it'll show some screenshots of Cockpit
  303. but then dive right into how we remote System APIs
  304. and go then deeper into DBus
  305. talk about Introspect()
  306. used with making Method calls
  307. then about how we monitor properties
  308. talk about ObjectManager
  309. and tell them to use it
  310. what happens if no ObjectManager
  311. Introspect() salat
  312. talk about making sure DBus apis ar eremotable
  313. asking for networkd API
  314. Suggest splitting out sdbus
  315. talking amout message catalog + journal and our issues dashboard
  316. that's really what i'm going to cover in a nutshell
  317. andreasn        sounds good
  318. andreasn        how long is the talk? 20 mins? 30 mins?
  319. stefw   20 min
  320. will be tight
  321. andreasn        yep
  322. dperpeet_       sounds compact
  323. stefw   may have to cut something
  324. dperpeet_       I can take a look at the slides tomorrow if you want
  325. stefw   ok, they're very basic, but i'll send them around tomorrow
  326. will be done with them today
  327. dperpeet_       great, thanks
  328. andreasn        I can take a look to
  329. too
  330. ok, I guess that was it
  331. #endmeeting
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!
 
Top