14:09:43 <andreasn> #startmeeting Cockpit weekly meeting 2016-11-21
14:09:43 <zodbot> Meeting started Mon Nov 21 14:09:43 2016 UTC.  The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:09:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:09:43 <zodbot> The meeting name has been set to 'cockpit_weekly_meeting_2016-11-21'
14:09:50 <andreasn> #topic agenda
14:10:02 <stefw> * Translations
14:10:04 <stefw> * Debian builds
14:10:11 <stefw> * Simpler reauthorization
14:10:25 <larsu> * container image scanning
14:11:28 <andreasn> anything else? Did you have something too, dperpeet?
14:11:38 <dperpeet> that's good
14:12:15 <andreasn> all right
14:12:19 <andreasn> #topic Translations
14:12:36 <stefw> I've pretty much finished up all the work on making Cockpit translatable
14:12:49 <stefw> It wasn't fun ... but it's pretty much done
14:13:02 <mvollmer> .hello mvo
14:13:05 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:13:09 <stefw> Once #5442 #5443 and #5444 are merged
14:13:12 <andreasn> .hello andreasn
14:13:13 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
14:13:21 <andreasn> stefw: yay!
14:13:23 <stefw> so that includes being able to mark up all the different kinds of input that we use
14:13:33 <stefw> Mustache, React, javascript, HTLM
14:13:37 <stefw> scanning for and extracting strings
14:13:46 <stefw> and bringing them in ... including into Mustache and Angular
14:13:46 <andreasn> do we have any language with full coverage?
14:13:54 <stefw> no we just marked up the strings
14:13:57 <dperpeet> the change with double quotes in javascript surprised me
14:14:00 <stefw> unless someone went back in time and translated it
14:14:03 <stefw> dperpeet, that was not a change
14:14:06 <stefw> that was always the case
14:14:13 <stefw> at least as far as i know
14:14:19 <stefw> because of how xgettext extracts strings
14:14:41 <stefw> the very latest modern point version of xgettext knows about javascript
14:14:43 <stefw> but none of the others do
14:14:54 <stefw> and so our javascript is treated as C code
14:14:57 <dperpeet> interesting, I thought it was a new requirement... I'm certain I never reviewed that
14:14:59 <stefw> and always has been
14:15:16 <stefw> dperpeet, did you see the strings getting extracted before when you used _('string') ?
14:15:21 <stefw> did you run 'make update-po' and check the cockpit.pot file?
14:15:30 <stefw> so yes, there are all sorts of gotchas
14:15:31 <dperpeet> ahem :)
14:15:42 <stefw> if you run a development build of cockpit you can see "Translating" in the sidebar
14:15:50 <stefw> click there and you can see the various forms and rules for marking up strings.
14:15:58 <stefw> there's a lot of places in cockpit where things are/were wrong
14:16:03 <stefw> and i've done one pass fixing them
14:16:12 <stefw> other people can fix them as they notice them, and/or review new pull requests
14:16:22 <stefw> so i would encourage folks to get familiar with the forms if they're going to be reviewing text
14:16:35 <dperpeet> yes, thanks for that
14:16:36 <stefw> once we have a release including these changes, we should make a post to cockpit-devel asking for more translations.
14:16:49 <stefw> this is ugly horrible nasty work ... but i'm glad it's finished
14:17:06 <stefw> we also have tests, yay
14:17:10 <stefw> tests that check that translations work
14:17:14 <stefw> and extra bonus ....
14:17:21 <stefw> we even have the correct setlocale() and LANG in cockpit-bridge now
14:17:35 <stefw> so any libraries it links, or processes it calls will (by default) get the right language set
14:18:00 <stefw> one thing to note when adding a new language, is that a language_country code must be added to the shell manifest.json
14:18:04 <dperpeet> which means we have to be really careful when screen scraping output
14:18:09 <dperpeet> and one more reason to avoid that
14:18:13 <stefw> dperpeet, always use LC_ALL=C when screenscaping output
14:18:16 <stefw> then you can go wild
14:18:22 <stefw> but yeah, screenscraping is fugly
14:18:29 <dperpeet> of course, but I wouldn't place any bets on whether we actually do that everywhere
14:19:05 <stefw> someone interested could port the tests to run in no-english
14:19:09 <stefw> then you would catch those bugs
14:19:11 <stefw> but that's a lot of work
14:19:15 <stefw> since it affects both frontend and backend
14:19:18 <stefw> anyway ... as i was saying
14:19:24 <stefw> the "Display Language" selection in teh console
14:19:31 <stefw> actually affects locale *and* language
14:19:42 <stefw> so "de" is a language
14:19:50 <stefw> "de_DE" is a locale, "de_AT" is a locale
14:20:27 <stefw> so i think that's it ... mostly need to start thinking about this during review.
14:20:40 <stefw> and petervo has/may work on a script to automatically update/pull from zanata
14:21:26 <dperpeet> one more cockpituous job? =)
14:21:36 <stefw> yes, likely for a verify machine
14:21:51 <stefw> the two types of tasks that are run against github need to be refactored and broken out further
14:21:59 <stefw> not be so married into the same python code
14:22:04 <stefw> and then a third can be added
14:22:13 <stefw> ie: updating the po files will open a pull request
14:22:18 <stefw> so it goes in that bucket of fish
14:23:47 <stefw> next topic? or anyone want to talk about this one more?
14:24:29 <dperpeet> no, great job
14:24:36 <andreasn> #topic Debian builds
14:24:49 <stefw> So we're testing on Debian Jessie ... yay
14:24:55 <larsu> \o/
14:24:56 <stefw> mvollmer did a bunch of work to make that happen
14:25:07 <stefw> what didn't happen is updating the repo to include jessie deb files
14:25:12 <stefw> i need help with that
14:25:30 <stefw> reprepro gives me errors about deb files having the same names in unstable and jessie
14:25:38 <stefw> so someone who knows about this stuff needs to make a call
14:25:51 <stefw> i have an incomplete pull request
14:25:55 <stefw> here: https://github.com/cockpit-project/cockpituous/pull/57
14:26:03 <stefw> and I can paste instructions in there on where I'm stuck
14:26:05 <stefw> if it helps
14:26:40 <larsu> I can have a look
14:26:51 <stefw> ok, i'll put instructions in that pull request
14:26:54 <stefw> shortly after this discussion
14:27:03 <stefw> in addition
14:27:07 <stefw> this page has been updated: http://cockpit-project.org/running.html
14:27:17 <stefw> there are three sections, self explanatory
14:27:46 <larsu> neat :)
14:28:14 <larsu> it's a bit low contrast for my taste, but the sections are a great addition!
14:28:25 <stefw> you can work with andreasn to make it not so low contrast :)
14:28:30 <stefw> i'll review pull requests
14:28:36 <andreasn> what's low contrast exactly? The headers?
14:28:42 <andreasn> yeah, we can figure that out
14:29:22 <andreasn> just file it in the tracker here https://github.com/cockpit-project/cockpit-project.github.io
14:29:27 <andreasn> all right, net up
14:29:31 <andreasn> next up
14:29:52 <andreasn> #topic Simpler reauthorization
14:30:28 <stefw> the next big block of work i'm likely to get pulled into is simplifying our reauth structure
14:30:35 <stefw> just a heads up so people know what pull requests are about
14:30:48 <stefw> so rather than reinvent reauthorization using our src/reauthorize code
14:31:08 <stefw> i'm looking at just implementing a bog standard polkitagent that uses a login password and/or prompts when no password is available.
14:31:12 <stefw> likely this will be implemented in javascript
14:31:28 <stefw> so hence means adding the ability to export dbus objects over the bridge
14:31:33 <stefw> which is not that hard
14:31:38 <stefw> and i have most of the code written already
14:31:53 <stefw> this is the first related pull request: https://github.com/cockpit-project/cockpit/pull/5441
14:31:54 <dperpeet> will this touch on sudo authorizations that users might have?
14:31:56 <stefw> setting some of the background
14:32:07 <petervo> we'll likely have to keep the old way for backwards compatibility as well
14:32:14 <stefw> petervo, yup
14:32:17 <stefw> in cockpit-ws
14:32:54 <stefw> yes, the idea is in addition to having a polkitagent also listen for prompts on the tty on which we launch sudo, and percolate those up as well
14:33:12 <dperpeet> ok, great
14:33:15 <petervo> have you thought about the pattern you'll use on the frontend?
14:33:18 <stefw> fixing this is one of the biggest items on our LTS support
14:33:25 <stefw> petervo, i've given it some thought
14:33:28 <petervo> esp when dealing with multiple prompts?
14:33:37 <stefw> i like the 'lock/unlock' pattern
14:33:56 <stefw> the frontend UI implemented in such a way that either priveleged operations are possible (unlocked) ... or they're not (locked)
14:34:02 <stefw> and you can see in the top bar which is which
14:34:10 <stefw> you can see if privileged operations were required ... but not allowed
14:34:27 <stefw> and map that back to superuser: require and/or superuser: try respectively ... and obviously also polkitagent requests.
14:35:02 <stefw> petervo, worth thinking about: the sudo handling pattern could also extend to ssh if we wanted it to
14:35:08 <stefw> but that's a next step
14:35:16 <stefw> first thing would be to have a polkitagent in javascript
14:35:24 <petervo> yep, that would be nice
14:35:26 <stefw> currently although we invoke sudo, we never hand it a password
14:35:44 <stefw> currently we only include sudo support for cloud instances where sudo is a way to get root without a prompt
14:36:00 <stefw> so the upshot of this is:
14:36:07 <stefw> design ^^ andreasn, will want to listen in here
14:36:12 <stefw> when logging in
14:36:21 <andreasn> I'm listening :)
14:36:35 <stefw> you choose "Use my password for privileged tasks and to connect to other machines"
14:36:37 <stefw> on the login screen
14:36:43 <stefw> that's disabled by default
14:36:54 <stefw> once you choose it, it remains chosen via a cookie for further login attempts on this machine
14:37:06 <stefw> that sets the mode that you start off in whether locked or unlocked for priveleged operations
14:37:21 <stefw> the mode is displayed inconspicuously in the top bar next to your name
14:37:36 <stefw> clicking on the mode lets you change it, ie: type a password to go from locked -> unlocked for privileged operations
14:37:57 <stefw> if the ui tries to perform an action that requires a privileged operation ... the inconspicousness vanishes ... maybe it goes red up there
14:38:06 <stefw> indicates that action is required up there ... and that's the reason that permission was denied
14:38:27 <stefw> this is has some commonality with the gnome-control-center ...
14:38:57 <stefw> the last thing we want is password prompt dialogs flashing the screen on various actions, showing up right after login, or other dumb times
14:39:06 <andreasn> right
14:39:20 <stefw> by taking all these steps we can essentially model the escalating privileges model that linux has
14:39:32 <andreasn> so for an account that is wheel, will certain actions be locked by default?
14:39:41 <stefw> while taking into account the idea that many (most?) users will want to log into Cockpit in such a way that they can perform privileged operations
14:40:05 <stefw> andreasn, depending on whether you tell it to unlock on the login screen as you log in.
14:40:10 <andreasn> ah, right
14:40:31 <stefw> but dun dun dun .... here's the thing that everyone needs to be happy with
14:40:32 <stefw> once you do unlock
14:40:36 <stefw> your password is cached in javascript
14:41:01 <stefw> and this really isn't such a shocker ... when you think about security
14:41:24 <stefw> both sudo, pkexec and gnome-shell already make you type your password into processes within the user security context
14:41:26 <larsu> in javascript, but not in a cookie or session storage, right?
14:41:41 <stefw> not in a cookie
14:41:49 <stefw> but we need a way to get it from the login screen to the shell page
14:41:59 <stefw> in the case where you've selected the option on teh login screen
14:42:09 <andreasn> yeah, I guess the model become closer to the cli. A bit worried that it will make cockpit less usable "out of the box" though
14:42:14 <stefw> so if there's a good mechanism for that other than sessionStorage ... i'm all ears
14:42:24 <stefw> andreasn, yup ... slightly
14:42:41 <andreasn> how will it work in case I log in with the "root" account on a box?
14:42:53 <stefw> andreasn, it's always unlocked for privileged access
14:42:58 <andreasn> right
14:42:59 <stefw> er, privileged operations
14:43:03 <mvollmer> why do we change the default from "authorized" to not "authorized"?
14:43:31 <stefw> setting the default will be a single true/false change so we can debate that long after these changes happen.
14:43:40 <mvollmer> sure
14:43:53 <stefw> reinventing the reauthorization model for linux didn't work
14:44:02 <stefw> as much as the effort that i put in there
14:44:13 <larsu> andreasn: filed https://github.com/cockpit-project/cockpit-project.github.io/issues/51
14:44:20 <andreasn> larsu: thanks!
14:44:26 <stefw> and the reauthorization / privilege escalation model for linux sessions is to log in as unprivileged and then escalate privileges
14:44:32 <stefw> we offer to perform that task with a single checkbox
14:44:50 <stefw> and/or allow a log in directly as root
14:45:14 <stefw> which models the rest of the (rather dubious) linux security and privilege escalation model
14:45:38 <stefw> that said, if once thist is done, we really want to have that single checkbox start off as checked ... then we can discuss it at that point
14:45:49 <stefw> the main downside of it is that it passes the user's password into the user session
14:45:51 <andreasn> sounds good
14:46:01 <stefw> doing that without the admins consent ... is worth discussion ... at least
14:46:14 <mvollmer> make sense to me
14:46:23 <mvollmer> so, UI
14:46:53 <andreasn> yeah, we have the "your user is not allowed to do this because you're not in wheel" tooltips already
14:46:59 <mvollmer> the storage page for example turns into a million tooltips for unprivileged users
14:47:08 <andreasn> so something similar could work in this situation
14:47:29 <mvollmer> you can't move your mouse without triggering the same tooltip everywhere
14:47:40 <mvollmer> maybe that can be improved as well
14:47:44 <stefw> yeah, i think so
14:48:00 <stefw> we'll be more forced to think about the UI when non-privileged
14:48:02 <andreasn> are there any operations on the storage page that is permitted at all?
14:48:03 <stefw> which i think is a good thing
14:48:16 <stefw> andreasn, well viewing the state is usually permitted as non-privileged
14:48:18 <stefw> for most pages
14:48:20 <stefw> although therte are exceptions
14:48:21 <andreasn> right
14:48:29 <stefw> in the docker page, unless you're privileged your SOL
14:48:37 <stefw> because ... docker things
14:50:09 <andreasn> the unlock bar sounds like a good approach
14:50:41 <stefw> in key places we can point to it
14:50:42 <andreasn> but maybe need to discuss that outside this meeting, need to get around to container image scanning topic too
14:51:39 <andreasn> so lets do container image scanning now, before we run out of time
14:51:42 <andreasn> #topic container image scanning
14:52:16 <andreasn> larsu ^
14:52:31 <larsu> yes, sorry
14:52:51 <larsu> it's looking bleak
14:53:09 <larsu> the daemon stays around without owning the name (but exits after a while)
14:53:23 <stefw> so even display of the information is looking bleak?
14:53:51 <larsu> my idea was to poll the daemon every now and then
14:53:58 <andreasn> are there any parts of the design we can scale back on, to meet the technology?
14:54:05 <larsu> which is working right now, but you'll end up with a lot of processed
14:54:10 <larsu> *processes
14:54:18 <larsu> I could turn up the timeout, I guess
14:54:26 <stefw> yeah maybe for the initial version that would be good
14:54:31 <stefw> it would help to be able to demonstrate how shit it is
14:54:47 <stefw> with running code + pull requests that add simple features ... which don't yet exist ... and get people involved
14:54:49 <larsu> ok, makes sense
14:54:55 <stefw> in a vacuum ... nobody cares
14:55:14 <stefw> but once something exists everyone has an opinion ... and what's more some people have an interest
14:55:19 <larsu> people will care and blame cockpit if it starts all those dead processes though
14:55:24 <larsu> so we'll need to be careful there
14:55:32 <stefw> the processes don't say cockpit
14:55:38 <stefw> and also we have something for that:
14:56:05 <stefw> cockpit.onvisibilitychange
14:56:07 <stefw> that should help ^^
14:56:12 <stefw> so when they switch away we can kill shit
14:56:16 <stefw> maybe even log nasty messages to syslog
14:56:26 <stefw> see http://cockpit-project.org/guide/latest/cockpit-location.html
14:56:40 <larsu> ah, right
14:56:47 <larsu> yeah I'll do that and up the timeout
14:56:49 <stefw> http://cockpit-project.org/guide/latest/cockpit-location.html#cockpit-jump-hidden
14:57:00 <larsu> the services do exit after a while
14:57:07 <larsu> haven't figured out when, yet
14:57:29 <mvollmer> is the daemon "atomic_dbus.py"?
14:57:32 <larsu> yes
14:57:42 <mvollmer> can't we fix that?
14:57:57 <mvollmer> or am I misunderstanding?
14:58:04 <stefw> yup we can and should, right larsu
14:58:15 <larsu> they're not sure whether the atomic library "can handle multiple calls"
14:58:15 <stefw> it's not hard to fix as i understand it
14:58:25 <larsu> this is the actual response I got on the bug :/
14:58:32 <larsu> but yeah, of course I'm trying to fix it
14:58:43 <mvollmer> right, sorry for doubting that
14:58:47 <larsu> it's just all taking much longer than I though
14:58:50 <larsu> mvollmer: no worries :)
14:59:40 <stefw> yeah, it's a bummer
14:59:47 <stefw> but that's how it is with everything we have to touch :S
15:00:01 <larsu> ya :/
15:00:16 <larsu> anyway - just wanted to give that status update. end of topic :)
15:00:29 <andreasn> and that's 16:00 CET sharp
15:00:38 <larsu> perfect
15:00:40 <andreasn> no time for open floor today :/
15:00:43 <andreasn> #endmeeting