14:03:04 <mvollmer> #startmeeting
14:03:04 <zodbot> Meeting started Mon Nov  9 14:03:04 2015 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:09 <mvollmer> .hello mvo
14:03:09 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:03:27 <stefw> .hello stefw
14:03:28 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
14:03:57 <dperpeet_> .hello dperpeet
14:03:58 <zodbot> dperpeet_: dperpeet 'None' <dperpeet@redhat.com>
14:04:06 <mvollmer> #topic Agenda
14:04:21 <mvollmer> * SOS, downloading
14:04:27 <mvollmer> * Mock in VM
14:04:31 <mvollmer> * Debian
14:04:39 <stefw> * Custom SELinux policy
14:04:50 <dperpeet_> * cockpit on debian
14:04:52 <stefw> * Sideband channels
14:05:30 <petervo> 5
14:05:44 <stefw> 6
14:05:50 <petervo> sry
14:06:18 <mvollmer> let's go
14:06:25 <mvollmer> #topic SOS, downloading
14:06:53 <mvollmer> Pull request: https://github.com/cockpit-project/cockpit/pull/3119
14:07:15 <mvollmer> it's still WIP since we need to figure out how to securely download files from the managed machine
14:07:25 <mvollmer> some UI tweaks might be done
14:07:32 <stefw> yup ... was thinking about how to do the downloading
14:07:48 <stefw> by finishing the work on sideband channels to work for both WebSocket and HTTP GET
14:07:48 <mvollmer> we have two attack points:
14:07:51 <mvollmer> browser
14:07:56 <mvollmer> and local users on the machine
14:08:09 <mvollmer> (or users in the local network of the machine)
14:08:46 <mvollmer> the latter should be fixable since we control all the code that is involved
14:08:51 <stefw> yup
14:09:02 <mvollmer> but I have no good idea yet
14:09:14 <mvollmer> use a unix socket?
14:09:31 <stefw> no we can use sideband channels for the downloading
14:09:42 <stefw> essentially for a sideband channel:
14:09:50 <mvollmer> okay, should we postpont this discussion until then
14:09:52 <mvollmer> ?
14:09:55 <stefw> sure
14:10:17 <mvollmer> so, we solve the downloading with sideband channels? :)
14:10:52 <mvollmer> i was asking for feedback about a API
14:11:00 <dperpeet_> after talking (offline) about the security implications a bit, sideband channels seem like a good solution
14:11:09 <mvollmer> to get progress info, and final archive name out of SOS
14:11:21 <stefw> ah very good
14:12:02 <mvollmer> i got redirected, but I need to find out where to continue the discussion
14:12:06 <mvollmer> let's not block on that.
14:12:16 <mvollmer> but the current approach is rather fragile
14:13:05 <mvollmer> hopefully it will not be much work, so maybe I return to that and propose a patch
14:13:46 <mvollmer> there is also a demo: https://youtu.be/-6rfWUoOQbs
14:13:59 <mvollmer> next?
14:14:17 <dperpeet_> good work mvollmer!
14:14:21 <mvollmer> thanks!
14:14:29 <dperpeet_> and nice to have the video :)
14:14:32 <mvollmer> ahh, one more thing that I should mention:
14:15:11 <mvollmer> if the user closes the browser, we are leaking sosreport processes and archives on the machine
14:15:56 <mvollmer> they will eventually finish and be deleted, though.
14:15:58 <stefw> can we put them in XDG_RUNTIME_DIR?
14:16:03 <stefw> that should be removed when the user logs out, no?
14:16:06 <mvollmer> they are in /var/tmp/
14:16:22 <stefw> but actually, the archives should stay around no?
14:16:30 <mvollmer> good question
14:16:45 <mvollmer> the sosreport guys say that it makes sense to delete them when the dialog closes
14:16:52 <mvollmer> and the code does that
14:17:03 <stefw> interesting
14:17:04 <dperpeet_> I think if the user wants to keep them, they have to copy them somewhere else
14:17:11 <mvollmer> yeah
14:17:44 <mvollmer> ne idea is to have a cockpit-sosreport.service unit that does the work
14:18:03 <mvollmer> and we can manage that across browser reloads
14:18:23 <dperpeet_> with a dbus interface?
14:18:28 <mvollmer> no
14:18:32 <dperpeet_> :)
14:18:46 <mvollmer> this doesn't fit a dialog very well UI-wise
14:19:02 <mvollmer> I am happy with the current state of things
14:19:07 <dperpeet_> I guess this depends on how long it could take
14:19:23 <dperpeet_> but switching pages will keep the status, correct?
14:19:33 <dperpeet_> i.e. as long as you don't close the session
14:19:41 <mvollmer> yes, it should, good point
14:19:59 <dperpeet_> as long as we have that, I don't think the process cleanup matters that much
14:20:11 <dperpeet_> given the infrequency of use (probably anyway)
14:20:31 <mvollmer> yes
14:21:06 <mvollmer> ok, let's move on...
14:21:19 <mvollmer> #topic Mock in VM
14:21:27 <mvollmer> i am slowly making progress
14:21:35 <mvollmer> iterating is slow :-)
14:21:57 <mvollmer> there are details to figure out, but it fundamentally works
14:22:15 <mvollmer> so we do "mock --init --installdeps" during vm-create
14:22:35 <mvollmer> and "mock --offline --no-clean --rebuild" during testuite-prepare
14:22:53 <mvollmer> haven't checked yet how big the images are now
14:23:07 <mvollmer> but scrubbing away just the right things is also tricky
14:23:11 <mvollmer> so I leave that for later
14:23:31 <dperpeet_> we didn't use --offline before, right?
14:23:35 <mvollmer> no
14:23:37 <mvollmer> right
14:23:45 <mvollmer> correct
14:23:46 <mvollmer> genau
14:23:49 <dperpeet_> so the behavior changes, but I think this is better
14:23:54 <dperpeet_> exactement!
14:24:00 <mvollmer> yes, the behavior change is the point
14:24:11 <dperpeet_> I just wanted to point that out :)
14:24:20 <mvollmer> a secondary point is that building debs is probably better done inside debian
14:24:45 <dperpeet_> might be easier
14:24:47 <mvollmer> although there is pbuilder in fedora
14:25:06 <dperpeet_> I think we should first try it without adding debian, but let's discuss that in the debian topic
14:25:13 <mvollmer> yep
14:25:40 <mvollmer> i am not making this generic right now
14:25:58 <mvollmer> so Ill just continue with this
14:26:14 <dperpeet_> would it be cleaner to get rid of mock entirely?
14:26:18 <dperpeet_> and build natively?
14:26:29 <mvollmer> with rpmbuild?
14:26:33 <mvollmer> or "make install"?
14:26:42 <dperpeet_> rpmbuild
14:26:49 <mvollmer> i don't think that's easier
14:27:00 <mvollmer> especially if you want to do it in a chroot
14:27:06 <dperpeet_> true
14:27:15 <dperpeet_> and if mock works, we have fewer images
14:27:30 <mvollmer> also, we will use the mock from the target itself
14:27:39 <mvollmer> and just use default.cfg, hopefully
14:27:52 <mvollmer> but we didn't have trouble regarding this
14:28:00 <dperpeet_> no, I think it's good
14:28:18 <mvollmer> okay, next?
14:28:19 <dperpeet_> also it's easier to clean up the files mock leaves behind
14:28:22 <dperpeet_> yes, next
14:28:27 <mvollmer> #topic Debian
14:28:42 <dperpeet_> so, last weekend we hacked a bit on Cockpit/Debian with the help of mbiebl
14:29:07 <dperpeet_> the good news: cockpit builds (dev-build) on debian 8.2 without pulling anything extra
14:29:45 <dperpeet_> there are a few issues that need attention, but I want to write that up a bit instead of just listing it here
14:30:04 <dperpeet_> the major points are that debian has a different system of user privilege escalation
14:30:11 <dperpeet_> (no wheel, use sudo or su)
14:30:24 <dperpeet_> and that there is no storaged
14:30:54 <dperpeet_> I've started discussing and looking at debian packaging
14:31:27 <dperpeet_> the consensus was that the relevant bits should probably end up in the cockpit git repo
14:31:41 <mvollmer> oh, interesting
14:31:59 <dperpeet_> the reasoning behind that is we want to make sure pull requests don't break debian
14:32:21 <dperpeet_> I guess we'll see how much work it actually is to get this up and running, but it shouldn't be too bad
14:32:25 <mvollmer> so it's gonna be a primary, like fedora and rhel?
14:32:37 <dperpeet_> I believe this would be a good thing, yes
14:32:40 <stefw> if we can, it would be nice
14:32:51 <mvollmer> yeah
14:32:53 <stefw> i guess we're working towards that
14:32:57 <dperpeet_> we need a maintainer for the packages
14:32:58 <stefw> but if there's some fundamental problem
14:33:03 <stefw> then obviously we'd have to stop short
14:33:14 <dperpeet_> and I think that job is easier if it doesn't diverge from upstream cockpit
14:33:27 <mvollmer> sounds like we are closer than I thought.
14:33:41 <dperpeet_> the debian way apparently includes having the necessary patches in the tree
14:33:58 <stefw> which is zero patches for upstream
14:33:59 <dperpeet_> so if we need "debianisms", we could integrate that into our runners
14:34:32 <dperpeet_> there don't seem to be real blockers to packaging
14:34:45 <dperpeet_> we need to pay attention to the way we bundle js libraries, but that shouldn't be a big deal
14:35:31 <dperpeet_> and we need to look at a few license notes
14:35:45 <dperpeet_> e.g. https://github.com/cockpit-project/cockpit/issues/3130
14:36:22 <dperpeet_> I think we can do this fairly quickly
14:36:43 <dperpeet_> once we build packages I think we should call for a maintainer
14:37:41 <dperpeet_> I think this is it for now on Debian
14:37:50 <mvollmer> would we aim for "CD" to Debian?
14:37:53 <dperpeet_> yes!
14:38:00 <dperpeet_> to unstable, anyway
14:38:04 <mvollmer> sure
14:38:13 <mvollmer> okay
14:38:28 <mvollmer> next!
14:38:36 <mvollmer> sounds great, btw!
14:38:51 <mvollmer> #topic Custom SELinux policy
14:39:14 <stefw> i've been thinking of throwing away our custom SELinux policy
14:39:32 <stefw> it's become more of a hindrance ... since we don't end up testing on a system that matches what the user will see
14:39:57 <stefw> selinux issues would be like other issues in the system
14:40:02 <stefw> they would cause problems until they are fixed
14:40:05 <stefw> what do you guys think?
14:40:14 <mvollmer> we test master without a custom policy
14:40:36 <stefw> RHEL-7 master was failing for a long time
14:40:38 <stefw> due to SELinux
14:40:41 <stefw> and we didn't fix it
14:40:42 <stefw> :S
14:40:46 <mvollmer> yeah
14:40:56 <mvollmer> i agree
14:41:19 <mvollmer> ideall, we should hold back a release until selinux works, too.
14:41:32 <dperpeet_> I agree
14:41:39 <mvollmer> should we hold back the individual PRs as well?
14:41:41 <dperpeet_> we shouldn't need a custom policy
14:41:45 <mvollmer> i would say so.
14:41:50 <stefw> yeah, i think so
14:41:52 <mvollmer> but we need changes to the policy
14:42:23 <stefw> at least one
14:42:26 <stefw> i filed it today
14:42:30 <stefw> but i'm working on a work-around
14:42:34 <stefw> since we won't have it backported
14:42:36 <dperpeet_> we could keep it for testing purposes
14:42:53 <dperpeet_> nevermind, unclean
14:43:06 <dperpeet_> like the workarounds we keep in the tree
14:43:19 <mvollmer> we expect the policy to stabilize, right?
14:43:55 <mvollmer> e.g., once we have access to /run/cockpit-ws/, we don't need to worry about which individual files we put there, right?
14:43:57 <dperpeet_> what would happen to our releases if we threw out the custom policy today?
14:44:17 <dperpeet_> would this negatively impact what we release right now?
14:44:20 <stefw> we don't expect people to install cockpit-selinux
14:44:27 <stefw> so i don't think that it would have any effect on users
14:44:58 <dperpeet_> then I don't see a good reason to keep it around
14:46:56 <mvollmer> yep, we should feel the pain; otherwise we don't seem to care enought to fix the real policy
14:47:52 <mvollmer> btw, this is the https://github.com/cockpit-project/cockpit/pull/3134
14:47:55 <mvollmer> and it's a bit red
14:48:05 <mvollmer> which is expected I guess
14:48:15 <stefw> right, i need to work through it
14:48:46 <dperpeet_> yeah, but opposed to just test races these will include real fixes :)
14:49:53 <stefw> that's it for that topic i think
14:50:30 <mvollmer> #topic  Sideband channels
14:52:17 <stefw> we have a feature called sideband channels right now
14:52:28 <stefw> and it seems we need to adjust it a bit and use it for downloading of files
14:52:35 <stefw> the basic idea is that one can open a cockpit channel
14:52:50 <stefw> and the payloads go over some other transport
14:52:57 <stefw> such as a different WebSocket, or an HTTP response
14:53:28 <stefw> currently we only allow the payload to go over a WebSocket, but I would like to add HTTP response support
14:53:43 <stefw> The reason to use sideband channels (instead of inventing our own file downloading access mechanisms)
14:54:01 <stefw> is that it ties the HTTP response (or external WebSocket) to the original main WebSocket
14:54:23 <stefw> if you don't have access to the main WebSocket one cannot trigger an HTTP response (which would be an attack vector)
14:54:56 <stefw> it should also be able to implement the HTTP resource stuff in cockpitwebservice.c with some of the same code
14:55:00 <stefw> as it is essentially doing the same thing
14:55:20 <stefw> so once this is done the SOS report stuff could be completed
14:55:49 <dperpeet_> is there anything related we could use this for? before we set this in stone...
14:55:56 <mvollmer> what do we use the sideband channels for currently?
14:56:50 <stefw> just example code
14:56:56 <stefw> nothing should be using them for real
14:57:00 <stefw> so we would change how they work and start using them
14:57:05 <mvollmer> okay
14:57:15 <dperpeet_> sounds good
14:57:30 <mvollmer> so how would that work in detail?
14:57:41 <stefw> i've started to write documentation
14:57:47 <mvollmer> browser makes a GET request and opens a Save dialog for the response
14:57:51 <stefw> there are two approaches to choose from:
14:58:08 <stefw> 1. the caller { command: "open" } a channel with a "sideband": tag
14:58:20 <stefw> cockpit-ws responsd with a control message containing the target url
14:58:32 <stefw> one connects to that target url using either websocket or HTTP request
14:58:36 <stefw> and consumes the payload
14:58:42 <stefw> so in the download case, we would use that url in a link
14:58:48 <stefw> the url is obviously unpredictable
14:58:51 <stefw> second approach:
14:59:15 <stefw> instead of the above, we register a "channel open template", ie: the set of options to use
14:59:21 <stefw> cockpit-ws passes back a target url in a control message
14:59:30 <stefw> and *whenever* we connect to that target url (not just once)
14:59:35 <stefw> a new channel is created with the given options
14:59:52 <stefw> ie: the second allows multiple "downloads"
15:00:09 <stefw> of the same thing
15:00:42 <stefw> the latter approach has a lot in common with how our resource urls work
15:00:52 <mvollmer> would we use the existing fsread1 payload for downloads?
15:00:58 <stefw> mvollmer, yes
15:00:59 <mvollmer> or do we need a new payload type?
15:01:01 <mvollmer> right
15:01:02 <dperpeet_> the second seems more in line with what I would expect from a download mechanism
15:01:02 <stefw> nope
15:01:40 <mvollmer> encoding the open options in the URL is a no-go because security
15:01:51 <stefw> yup
15:02:02 <stefw> the roundtrip is necessary
15:02:08 <stefw> doing it via a websocket gives us that security
15:02:27 <stefw> previously when we only had WebSockets in sideband channels, we could rely on WebSocket origin security to protect it
15:02:34 <stefw> but now that we're talking about HTTP responses
15:02:42 <stefw> we need to tie it to a websocket or some other round trip to the server
15:03:09 <mvollmer> websocket origin protectiong is stronger than the usual same-origin-policy?
15:03:42 <stefw> HTTP GET has no same origin policy
15:04:11 <stefw> in addition, our channels can perform actions, etc.
15:04:27 <mvollmer> but we have the cookie
15:04:39 <stefw> anyone in the browser can use the cookie
15:04:40 <mvollmer> but, yes, I think I get it
15:05:07 <dperpeet_> I still think the second option is more what I would expect of a download mechanism (with the template), why don't you agree stefw?
15:05:25 <stefw> i don't disagree
15:05:35 <dperpeet_> ah, I thought your "nope" was directed at my comment
15:05:36 <stefw> but we're designing something here broader than a download mechanism
15:05:54 <stefw> so we have to decide what characteristics we want
15:05:59 <dperpeet_> if we have a template, we can use that for more listeners
15:06:24 <dperpeet_> without having to set up the channel beforehand
15:06:38 <stefw> well the channel still needs to be setup
15:06:42 <stefw> that's the point of the security
15:06:58 <stefw> but the question is whether to set it up before each request or not
15:07:14 <stefw> i need to think about this some more, but there is a point that URLs should expire
15:07:19 <stefw> they use an nonce for security
15:07:27 <stefw> and nonces should be used once
15:07:28 <dperpeet_> yeah
15:07:48 <stefw> these are not stable urls anyway
15:07:59 <dperpeet_> I guess it's just a question of where the logic will reside anyway
15:08:10 <stefw> i tend to think logic should reside in javascript
15:08:24 <stefw> and we give it the building blocks that it needs to do what it can't do by itself
15:08:34 <stefw> all of this is a work around for the browser's inability to synthesize a download
15:08:46 <stefw> from javascript
15:08:50 <dperpeet_> I agree with js
15:09:00 <dperpeet_> it's just a question of the workflow
15:09:24 <dperpeet_> e.g. with sos reports: make it availble when the report is generated or have something that works like "make this available now"
15:09:44 <dperpeet_> so create a new channel for each attempt (option 1) or allow several tries within a reasonable timeout
15:09:59 <stefw> well each attempt would have its own channel for sure
15:10:11 <dperpeet_> yeah, but the question is how that is setup
15:10:18 <stefw> actually now that we're talking about this, i think the first option is more appropriate
15:10:29 <stefw> i'll work on that first
15:10:32 <dperpeet_> if we want to make sure it's only used once, then probably
15:10:36 <stefw> we can adjust in flight once the WIP is therte if necessary
15:10:44 <dperpeet_> ok
15:10:49 <dperpeet_> let's see how it works out
15:12:02 <mvollmer> ok, so the sosreport PR blocks on the sidechannels, right?
15:12:15 <stefw> i think so
15:12:21 <mvollmer> yes, makes sense
15:12:22 <dperpeet_> I think it wouldn't make sense to have this in before it works properly
15:13:05 <mvollmer> (hrr, virt-builder can't resize xfs filesystems, so we have been running with a 5G root in a 8G image the whole time.)
15:13:29 <stefw> ha ha ha
15:13:33 <stefw> ok, is the meeting done?
15:13:33 <mvollmer> (and now we run out, of course.)
15:14:15 <mvollmer> i'd say so.
15:14:21 <mvollmer> thanks!
15:14:30 <mvollmer> any other business?
15:14:47 <mvollmer> #endmeeting