[00:01] <bryce> [minutes will be up shortly...]
[13:05] <ace_suares> hi anyone can bring me in contact with a speaker from canoncial for an open source conference ?
[13:06] <Hobbsee> ace_suares: speak to jono (he's on irc)
[13:07] <ace_suares> Hobbsee: Hi ! ty i'll contact.
[13:55] <pitti> hey hey
[13:56] <kwwii> hi
[13:57] <Hobbsee> oh noes, a pitti and a kwwii!
[13:57]  * pitti throws a chocolate bar at Hobbsee
[13:58] <pedro_> hi
[13:59] <MacSlow> yo there
[13:59] <kwwii> pitti: thanks for all the help with the hardy packages, I owe you a drink :-)
[13:59] <Keybuk> mvo, Riddell, seb128: ping
[13:59] <pitti> kwwii: heh, no problem
[14:00] <Riddell> hi
[14:00] <mvo> hello
[14:00] <pitti> was just talking to seb in -devel
[14:01] <Hobbsee> pitti: \o/
[14:01] <seb128> Keybuk: hey
[14:01] <Keybuk> ok, let's get started
[14:01] <Keybuk> https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-06-19
[14:02] <Keybuk> I actually put together the meeting agenda this time ;-)
[14:02] <MacSlow> hey mpt
[14:02] <seb128> Keybuk: let's see if you manage to write minutes too ;-)
[14:02] <Keybuk> I didn't note any actions from last week's meeting, did anyone think they took one?
[14:02] <MacSlow> Keybuk, the GtkStatusIcon/Tray-Icon stuff is solved?
[14:03] <mpt> Sorry, I didn't realize I was expected in the meetings until I was actually spending time on Ubuntu :-)
[14:03] <Keybuk> MacSlow: I was going to ask you ;-)
[14:03] <Keybuk> mpt: you're not expected, but welcome to attend if you wish ;P
[14:03] <MacSlow> Keybuk, I didn't remove it
[14:03] <Keybuk> MacSlow: err?  missing context here
[14:04] <seb128> I think he's speaking about the action item for this one
[14:04] <Keybuk> ah, right
[14:04] <Keybuk> [14:19] <MacSlow> Keybuk, I can try to ask around my contacts at Imendio to see if they have some short-term hireable man-power left over, ok?
[14:05] <MacSlow> last time I looked (earlier this day) there still was a buttlet-point regarding the tray-icon spec and GtkStatusIcon issue in regards to RGBA-theme-engines (murrine)
[14:05] <Keybuk> MacSlow: did you ask around?
[14:05] <MacSlow> Keybuk, yeah... but I didn't get any responses sofar... only from Ryan and he's only available no earlier than september
[14:06] <Keybuk> MacSlow: do you think that it's worth continuing to ask around?
[14:06] <Keybuk> can you think of any other approaches to solve the problem?
[14:06] <MacSlow> Keybuk, drop RGBA for intrepid is the only "solution" I currently see :/
[14:06] <ogra> Keybuk, there should be a good bunch of free OLPC people now, probably there is someone mong them
[14:06] <ogra> *among
[14:07] <Keybuk> MacSlow: you don't know anybody who could do the work, including yourself?
[14:07] <Keybuk> does the murrine author not have any input?
[14:07] <Keybuk> could the panel simply be not transparent? :p
[14:08] <mpt> A transparent panel? Why?
[14:08] <kwwii> until now I have not set it to be transparent anyway (and had no immediate plans to do so)
[14:08] <kwwii> until now only a few apps can do rgba natively anyway :-(
[14:08] <Keybuk> I'm maybe missing why this is a critical blocker
[14:08] <MacSlow> Keybuk, well I probably could, but considering the time I've left to deliver the face-browser... I don't see me getting the tray-icon spec and GtkStatusIcon fixed before Feature/UI freeze for Intrepid
[14:09] <mpt> I thought the idea was to make panel items work against an opaque-but-not-necessarily-flat-color panel
[14:09] <Keybuk> MacSlow: if we don't get changes to gtkstatusicon, what does that mean?
[14:09] <MacSlow> Keybuk, but like I said... my lack of experience in that domain will cause me to take quite some time on it
[14:10] <kwwii> mpt: yeah, that is part of it as well
[14:10] <Keybuk> MacSlow: it's your call ;)
[14:11] <MacSlow> Keybuk, we will not be able to have RGBA as default colormap for every created GTK+-widget... that will cause the the notification-area to go "haywire"
[14:11] <MacSlow> Keybuk, I rather stick to the face-browser and do scheduled work
[14:11] <Keybuk> ok
[14:12] <Keybuk> solved then :-)
[14:12] <MacSlow> Keybuk, if we want some RGBA in GTK+-apps still for intrepid we'll have to do it on a per-app basis... e.g. just like I did for the dialogs of libgksu, gnome-session logout
[14:12] <Keybuk> yours is the next agenda item too
[14:12] <Keybuk>  * MacSlow: Clutter version
[14:12] <Keybuk> For gdm-face-browser clutter-0.7/0.8 is needed, but from debian we only get 0.6.x
[14:12] <seb128> update ;-)
[14:12] <MacSlow> there are a lot of nice fixes in 0.7/0.8
[14:12] <seb128> nothing is using it in the archive anyway so that's not going to create issues
[14:13] <pitti> that's just a library, shouldn't be too hard?
[14:13] <Keybuk> seems a no-brainer
[14:13] <MacSlow> and I already started doing a PPA for clutter/clutter-cairo/clutter-gtk 0.7~svn20080619
[14:13] <Keybuk> MacSlow: update clutter at your leisure
[14:13] <MacSlow> and for intpreid most are compiled aready...
[14:13] <MacSlow> but for the some days to come I'll stick to hardy on my desktop box for coding
[14:14] <mvo> MacSlow: you could upload it to your ppa against hardy
[14:14] <MacSlow> I'll have to cut the -doc stuff atm, because that would collide if installed in parallel with clutter 0.6.x & Co
[14:14] <Keybuk> MacSlow: don't worry about parallel install
[14:14] <MacSlow> mvo, I'm about to do that... but then meeting time came :)
[14:14] <Keybuk> just update the package
[14:14] <seb128> we don't need to install in parallel
[14:15] <mvo> I initially suggested to have them installable in parallel, but maybe we don't need that
[14:15] <seb128> nothing is using 0.6 anyway
[14:15] <MacSlow> seb128, Keybuk: well but I want to do it right :)
[14:15] <Keybuk> MacSlow: doing it right is updating the package ;)
[14:15] <MacSlow> seb128, indeed
[14:15] <seb128> doing it right is not keeping old non maintainer code in the archive
[14:15] <seb128> so just update
[14:15] <MacSlow> Keybuk, what's nearly done already :)
[14:15] <seb128> s/maintainer/maintained
[14:15] <MacSlow> Keybuk, first time package-training really paid off for me :)
[14:16] <Keybuk> ok, action for you:
[14:16] <Keybuk>  * MacSlow to update clutter to appropriate version, not worrying about parallel install
[14:16] <MacSlow> if anybody is interested -> https://edge.launchpad.net/~macslow/+archive
[14:16] <MacSlow> outch clutter-gtk quirked
[14:17] <seb128> MacSlow: feel free to ask questions on #ubuntu-desktop if you have issues during the update
[14:17] <MacSlow> ok
[14:17] <MacSlow> seb128, sure... thanks!
[14:17] <Keybuk> nothing I can see in the sponsoring queue that requires attention
[14:17] <Keybuk> and no desktop bug list for intrepid yet
[14:18] <Keybuk> Merges.
[14:18] <seb128> "clean your items before than Daniel jump from a roof because there is too many things to sponsor"? ;-)
[14:18] <pitti> "scott (41)" ... tsk :)
[14:18]  * MacSlow rushes to the loo
[14:18]  * kwwii hopes he makes it
[14:18] <pitti> but we really don't want to keep readahead-list, do we?
[14:18] <Keybuk> pitti: I keep unsubscribing the team, and he keeps putting it back
[14:18] <pitti> Keybuk: right, what I figure; we want prefetch in intrepid for real?
[14:19] <pitti> (pleeease...)
[14:19] <Keybuk> maybe
[14:19] <Keybuk> prefetch is ...
[14:19] <Keybuk> well, let's talk about that outside of the meeting if you're interested ;)
[14:19] <Keybuk> anywa
[14:19] <pitti> right
[14:19] <Keybuk> MERGES
[14:19] <Keybuk> 200+ to go
[14:19] <MacSlow> kwwii, Du Tuppes! :)
[14:19] <Keybuk> and not long left to do them
[14:20] <mvo> 203!
[14:20] <Keybuk> all hands on deck for them please, including MacSlow ;)
[14:20]  * pitti is happy that he grinded through all of his now
[14:20] <pitti> but I can help out with some others if required
[14:20]  * mvo is attacking them since this morning
[14:20] <MacSlow> Keybuk, what does that mean?
[14:20] <Keybuk> MacSlow: http://merges.ubuntu.com/main.html
[14:20] <seb128> speaking about those there is quite some done by contributors waiting for sponsoring ;-)
[14:20] <mvo> (well since a couple of days of course, but with more force since this morning)
[14:21]  * ogra wonders if tedg is on vacation, there is a xscreensaver merge sitting on MOM
[14:21] <mvo> I think seb128 has a point, we should go over our sponsoring tiem again
[14:21] <seb128> ogra: there is a sponsor request open for this one
[14:21] <ogra> i was perpared to upload that for him ...
[14:21] <Keybuk> ogra: he's moving house
[14:21] <ogra> seb128, well, i didnt see any yay or nay from ted on it
[14:21]  * mvo is guilty of letting those slip too
[14:21] <seb128> ogra: bug #229618 has your name on the sponsoring list
[14:22] <Keybuk> seb128: Colin already covered those last night ;)
[14:22] <Keybuk> unless there's new ones that I missed
[14:22] <ogra> seb128, yes, i asked dholbach  million times to not put me on it but ted, i dont do xss gss since 3 releases now
[14:22] <seb128> ogra: ted doesn't have upload rights to sponsor it though
[14:22] <ogra> seb128, right, but he should review it
[14:23] <seb128> alright
[14:23] <pitti> so I volunteer for going over the list and pick a few from non-canonical folks, but I don't want to do too many any more; I spent plenty of time on merges already
[14:24] <MacSlow> How is it decided who does what?
[14:24] <dholbach> ogra: subscribed Ted - excusez-moi
[14:24] <Keybuk> MacSlow: do any that you can
[14:24] <Keybuk> and don't feel limited by packages you've touched before
[14:24] <dholbach> ogra: and "million times" is a bit much
[14:24] <Keybuk> merges are a great way to learn packaging
[14:25] <MacSlow> Keybuk, I expected a comment like this :)
[14:25] <ogra> dholbach, well, three i think, sorry if i wouldnt be that busy i would have pinged him already, not really your fault :)
[14:26] <Keybuk> do people want to go down the merge list and assign them out?
[14:26] <MacSlow> what's with the color-coding there?
[14:26] <Keybuk> or are you happy to grab them as you can?
[14:27] <Keybuk> MacSlow: mostly meaningless
[14:27]  * mvo is happy with just grabbing them
[14:27]  * MacSlow has no idea what to address...
[14:27] <pitti> MacSlow: if you have questions about whether a patch is still necessary, procedure, or sponsoring, feel free to ask me; if you merge, you'll eventually learn more about packaging, indeed
[14:27] <MacSlow> but I feel I don't want to tackle huge stuff like gcc or gimp
[14:27]  * MacSlow is scared like hell
[14:27] <pitti> MacSlow: that's the package's Priority: field, but it's not very interesting
[14:27] <mvo> MacSlow: gtk+!
[14:27] <Keybuk> MacSlow: gimp should be easy for you, it's just a GTK+ app with a couple of small patches
[14:27] <pitti> MacSlow: nah, start with easy stuff
[14:27] <Keybuk> and it looks like there's a bug in the sponsor queue for it already ;)
[14:28] <Keybuk> MacSlow: planner (another small GTK+ app)
[14:28] <MacSlow> oh... I'll do gtkglext!
[14:28] <Keybuk> gnome-pilot-conduits
[14:29] <dholbach> gimp is in the sponsoring queue already - who wants it?
[14:29] <MacSlow> and I'll take on gimp then
[14:29] <Keybuk> dholbach: macslow
[14:29] <Keybuk> gnumeric?  that's only a small patch
[14:29]  * MacSlow grows bold
[14:29] <Keybuk> gnome-netstatus also
[14:29] <dholbach> gimp is in the SPONSORING QUEUE already :-)
[14:29] <MacSlow> dholbach, which means?
[14:30] <Keybuk> MacSlow: http://people.ubuntu.com/~dholbach/sponsoring/
[14:30] <dholbach> MacSlow: the merge is done, waits for a review and upload
[14:30] <Keybuk> MacSlow: someone's already done the work, it just needs a review and an upload
[14:30]  * dholbach hugs Keybuk
[14:30] <MacSlow> ah ok
[14:30] <ember> dholbach i've filled that a minutes ago
[14:31] <Keybuk> MacSlow: that's a handful that should be easily doable by you :p
[14:32] <Keybuk> ok
[14:32] <Keybuk> any other business for today?
[14:32] <seele> yes
[14:32] <pitti> packagekit
[14:32] <Keybuk> seele: what's your agenda item?
[14:32] <MacSlow> dholbach, I tell you which merges I want to tackle?
[14:32] <Keybuk> pitti: explain?
[14:32] <Keybuk> MacSlow: no, just go ahead and do them
[14:32] <seele> Keybuk: jono pinged me back to you about usability testing swag for participants
[14:32] <seele> Keybuk: not sure if he talked ot you or not
[14:32] <dholbach> MacSlow: no, not necessary - I'll take care once it's in the sponsoring queue
[14:32] <pitti> I wanted to ask around who else is insterested in getting PK working in intrepid soon
[14:32] <Keybuk> seele: he asked me if I thought it was a good idea, I said yes
[14:33] <pitti> personally I'd really like to get it for jockey, and I need it for getting rid of more gksu desktop files
[14:33] <pitti> ATM it's in pretty non-working shape, so if we want it, we need to allocate some resources to it
[14:33] <pitti> I'm interested in doing it, but I wanted to know who else needs it, and maybe help out
[14:34] <james_w> pitti: I've got it vaguely working on a machine here.
[14:34] <pitti> james_w: 0.2.2? on intrepid then?
[14:34]  * pitti currently installs intrepid to try it out
[14:34] <james_w> pitti: i.e. pkcon install whatever works.
[14:34] <pitti> james_w: wow, didn't work for me; let's talk aobut it in #u-devel after the meeting, if you like?
[14:34] <mvo> pitti: there is a bzr report/git repo for that with the 0.2.x branch
[14:34] <james_w> pitti: intrepid, and something around 0.2.2, with a couple of patches to the apt backend.
[14:34] <james_w> pitti: sure.
[14:34] <seele> Keybuk: ok.. we were hoping to do this mid-July.  is it possible to get something by then or is it too soon?
[14:34] <pitti> ah, ok
[14:35] <seele> Keybuk: shoudl i go back to jono about this now that you've blessed it?
[14:35] <Keybuk> seele: I'm not going to have any capacity to help with it, so Jono is your best bet
[14:35] <seele> Keybuk: ok thanks
[14:35] <Keybuk> seele: my blessing isn't required ;)  I don't have budget approval
[14:37] <mvo> james_w: is your branch based on the git branch of glatzor?
[14:37] <Keybuk> pitti: sounds like it needs more testing to determine what work is required?
[14:38] <pitti> Keybuk: yeah; I'll talk with James and try to get it working for me first, then I'll talk to glatzor about updating the package to 0.2.2
[14:38] <Keybuk> pitti: ok, great
[14:38] <james_w> mvo: no, on trunk
[14:38] <pitti> it was mainly an "oh, I need that too" straw poll
[14:38]  * mvo nods
[14:39] <Keybuk> ok
[14:39] <Keybuk> any other any other business? :-)
[14:39] <seb128> pitti: gnome-control-center 2.23 upstream code can use it to install themes, that would be nice to have too
[14:39] <pitti> seb128, mvo: it would be useful for upstreamizing easy-codec-installation, too, I figure?
[14:39] <seb128> yes
[14:40] <seb128> though we have a working solution there so that's not high priority
[14:40] <mvo> pitti: yes, we just need to solve the problem to figure out how the packages are called on different plattforms
[14:40] <mvo> distros I mean
[14:40] <mvo> but that is a general pk problem
[14:40] <pitti> right, at least the UI part, I mean
[14:40] <mvo> yes
[14:41] <pitti> mvo: maybe with particular provides? "Provides: video-codec-mpeg-4" or whatever
[14:41] <pitti> mvo: that's similar how OpenSuSE and RedHat encode driver vendor/product IDs to pacakges
[14:41] <ogra> pitti, i think plokit should be fixed before we rely on it wth more apps ... the missing password caching is *massively* nnoying
[14:41] <ogra> *polkit
[14:41] <pitti> password caching?
[14:42] <pitti> first time I hear about such a problem? what is the problem?
[14:42] <mvo> pitti: yeah, I think there are some plans for this from debian already, so that fits nicely
[14:42] <ogra> you have to give your password for *every* action ... unlike gksu which caches it for 10 min
[14:42] <pitti> ogra: no, that's not true
[14:42] <Keybuk> ogra: that's configurable in the policy
[14:42] <ogra> well, then we should fix the policy
[14:42] <pitti> you can say that you keep a privilege for the session, or forever
[14:42] <Keybuk> ogra: which policy requires you to prompt each time?
[14:42] <pitti> it's a checkbox, and mostly enabled by default
[14:42] <ogra> david told me in prague it wouldnt be possible at al since he thinks its a sceurity breach
[14:43] <Keybuk> ogra: I think you possibly confused him by referring to it as password caching
[14:43] <ogra> but if thats possible now, i'm fine, lets just enable it
[14:43] <Keybuk> when what you really meant was that PK authorizations shouldn't expire immediately
[14:43] <pitti> it's already there
[14:43] <ogra> for me it asks every time here on a clean hardy
[14:43] <Keybuk> ogra: for which authorization?
[14:43] <ogra> Keybuk, any that polkit is involved with
[14:43] <Keybuk> ogra: not true
[14:43] <james_w> g-s-t uses auth_admin, not auth_admin_keep_*, so they will show it
[14:43] <pitti> yes, for g-s-t
[14:43] <Keybuk> each authorization is configured differently
[14:44] <ogra> open time-admin ... click on unlock ... close time-admin
[14:44] <Keybuk> g-s-t does happen to just use "Admin Authentication"
[14:44] <pitti> but that's just g-s-t's very weird usage of PK
[14:44] <ogra> you will need to unlock again if you open it again now
[14:44] <pitti> ogra: check it with mounting an internal disk
[14:44] <Keybuk> if you do system -> admin -> authorizations -> manage system config -> Implicit Auth -> Edit -> Admin Auth (keep session)
[14:44] <Keybuk> then you'll only be asked once
[14:44] <ogra> i dont want to be asked once ... i want consitent behavior
[14:45] <pitti> so that should indeed be fixed in g-s-t
[14:45] <Keybuk> ogra: the bug here is that g-s-t doesn't use PK properly
[14:45] <ogra> gksu times ut after ten mins
[14:45] <ogra> pk will alllow it al the time or not
[14:45] <pitti> g-s-t needs to split the privileges, and have more sensible defaults for how long ot keep them
[14:45] <ogra> there is no timeout mechanism
[14:45] <Keybuk> a timeout would not be hard or invalid to add
[14:45] <ogra> right
[14:46] <Keybuk> though gksu doesn't have a timeout ;)
[14:46] <ogra> thats what i was after :)
[14:46] <ogra> well, inherited from sudo
[14:46] <Keybuk> (at least, I don't think it does -- I thought it was based on tty tickets :p)
[14:46] <Keybuk> oh, no, sudo does have that 15 minute thing doesn't it
[14:46] <ogra> yeah
[14:46] <pitti> right
[14:47] <Keybuk> pitti: do you see any reason why a (keep for 15 minutes) couldn't be added along with session and indefinitely ?
[14:47] <pitti> Keybuk: no, for corner cases like g-s-t that should be fine; however, it should be per-privilege, not global
[14:47] <Keybuk> pitti: agree
[14:47] <james_w> Keybuk: davidz was against it
[14:48] <Keybuk> james_w: any particular reason?
[14:48] <james_w> though perhaps only globally
[14:48] <Keybuk> it doesn't seem much different than "keep session"
[14:48] <james_w> I didn't ask for more details as we were in the middle of a session
[14:48] <ogra> Keybuk, he considered it a security issue, as i said above
[14:48] <Keybuk> ogra: as I said, I think you explained what you wanted wrong
[14:48]  * ogra dscussed it over a beer, no session involved ... but the outcome was the same
[14:49] <Keybuk> if you talked about caching passwords, then I can definitely see why he thought that was a security issue
[14:49] <Keybuk> the whole point of PK is that you _don't_ need a keyring for the passwords
[14:49] <ogra> yeah, might be since i referred to gksu which likely behaves different in fedora :)
[14:49] <Keybuk> what you actually wanted was for PK authorizations to timeout
[14:49] <pitti> ogra: they don't have gksu
[14:49] <pitti> or sudo
[14:49] <ogra> they do, but dont use it :)
[14:49] <pitti> F9 GUI is pure PK
[14:49] <Keybuk> right now, a PK authorization can be one shot (do action, and forget authorization)
[14:49] <pitti> well, not by default in the deskop, I mean
[14:50] <ogra> Keybuk, very scary
[14:50] <Keybuk> per-session (do action, and be able to repeat the action until you log out without being prompted)
[14:50] <Keybuk> and indefinite (do action, and never be prompted again)
[14:50] <ogra> right, like a graphical rootshell :)
[14:50] <Keybuk> what you should have asked for was another state between one shot and per-session
[14:50] <ogra> yeah, i see that now
[14:50] <Keybuk> which is an authorization granted for a short amount of time, or the end of the session, whichever is sooner
[14:51] <pitti> I think David didn't implement this so far because he thinks it's wrong design-wise
[14:51] <pitti> (I had a quick talk about PK with him)
[14:51] <ogra> that what he said as well
[14:51] <ogra> *thats
[14:51] <Keybuk> oh
[14:51] <Keybuk> I could definitely see that David doesn't like timeout authorizations :p
[14:51] <pitti> the idea of PK is that you auth for something once, and shoudlnt' be bothered about doing the same action henceforth
[14:52] <pitti> instead of gksu, which will ask you over and over again
[14:52] <pitti> since the fewer password request you get, the more attention you actually put to them
[14:52] <pitti> s/put/pay/ (I think)
[14:53] <Keybuk> we're almost out of time now :)
[14:53] <Keybuk> any other any other any other business? :-)
[14:53] <pitti> yeah, got sidetracked, sorry
[14:53] <pitti> KitKit!
[14:53] <ogra> pitti, well, its like the difference between su and sudo :)
[14:53] <pitti> ogra: yeah, su is worse
[14:54] <ogra> have a rootshell or use sudo
[14:54] <Keybuk> ok, adjourned
[14:54] <Keybuk> thanks everyone
[14:54] <pitti> thanks all
[14:54] <MacSlow> yipee.. food-time
[14:54]  * mvo waves
[14:54] <seb128> thanks
[15:16] <Zic> @schedule Paris
[15:16] <ubott2> Zic: Schedule for Europe/Paris: Current meeting: Desktop Team | 19 Jun 22:00: Security Team | 20 Jun 18:00: How to run a Bug Jam | 21 Jun 19:00: Xubuntu Community | 21 Jun 21:00: How to run a Bug Jam
[15:19] <Zic> hu :]
[15:20] <stgraber> @now
[21:07] <kees> i'm late, apologies
[21:08] <Casey_> Me too.
[21:08] <kees> hiya Casey_
[21:08] <kees> propagandist: around?
[21:08] <propagandist> heyya
[21:08] <jdstrand> hi!
[21:09] <propagandist> kees: yup
[21:10] <kees> #startmeeting
[21:10] <MootBot> Meeting started at 15:12. The chair is kees.
[21:10] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[21:10] <kees> [topic] CVE review
[21:10] <MootBot> New Topic:  CVE review
[21:10] <kees> just a quick overview on CVEs... anything anyone wants to bring up here?
[21:11] <jdstrand> I don't have anything
[21:12] <kees> [topic] SELinux update
[21:12] <MootBot> New Topic:  SELinux update
[21:12] <kees> propagandist: how're things in the Great Merge with Debian?  :)
[21:12] <propagandist> kees: heh, i think that i've narrowed down the changes to just a few minor ones in the main packages
[21:13] <propagandist> the one that needs to most changes will be refpolicy
[21:13] <kees> propagandist: cool.  I assume it makes sense to have a fork of refpolicy due to the differences between the OSs
[21:13] <propagandist> the last i talked with manoj though it sounded like we could get that squared away sooner or later
[21:13] <kees> ah, okay
[21:14] <kees> propagandist: anything you need from me or other ubuntu devs?
[21:14] <propagandist> mm true, there will probably be some forking
[21:14] <propagandist> kees: not at the moment, but i'll be sure to let you know if i do ;o]
[21:15] <kees> propagandist: heh, okay.  the auto-import-from-debian ends on the 26th, so after that (and before feature freeze) we just need to make sync requests (no justifications needed)
[21:16] <propagandist> ah, kk, i'll try to get as much done before that as i can
[21:16] <kees> [topic] Smack
[21:16] <MootBot> New Topic:  Smack
[21:16] <kees> Casey_: I read through the whitepaper you sent -- sounds like services need to be patched to use smack?
[21:16] <Casey_> Well ...
[21:16] <Casey_> No.
[21:17] <kees> heh, okay.
[21:17] <Casey_> That is, they don;t all need to.
[21:17] <Casey_> And it depends on the use you're putting them to.
[21:17] <kees> sure, understandable.
[21:17] <Casey_> The three uses (single, multiplexed, cognizant)
[21:17] <kees> fundamentally, we want to isolate the cups daemon from anything it doesn't need access to
[21:18] <propagandist> Is there any way to get the clients and an unmodified server running in different contexts without using the poly server?
[21:18] <Casey_> If you run system processess at "_"
[21:18] <Casey_> and users at "Blah"
[21:19] <Casey_> You can set up CUPS as either single level Blah or "mastered" at floor
[21:19] <kees> win 26
[21:19] <Casey_> There are cases for each
[21:19] <kees> eek
[21:20] <jdstrand> Casey_: I read the paper and the LWN stuff, but I haven't seen what an example access rules would be that you would load into /smack/load (or wherever)
[21:20] <jdstrand> Casey_: so I feel a bit of a disconnect
[21:20] <propagandist> I'm thinking of the case where we want CUPS at one level 'cups_blah' and the clients at another 'cups_c'
[21:20] <Casey_> Ok
[21:20] <Casey_> Here goes ....
[21:22] <Casey_> smackpolyport -c <wellknowncupsport> -m <port>:cups_blah ; cups --port <port> ,,,,
[21:23] <Casey_> Everyone will be able to talk to CUPS even though it's running at cups_blah
[21:23] <Casey_> smackpolyport does all the provileged stuff.
[21:23] <jdstrand> (this is multiplexed)
[21:24] <Casey_> Right. In particular, you're using a "safe" master for all client labels.
[21:24] <jdstrand> Casey_: can you give an example rule that tells what the safe master can do?
[21:24] <jdstrand> excuse me if my terminology is wrong
[21:25] <propagandist> Casey_: ah, kk, so the only way to do that is through the polyport yes?
[21:25] <Casey_> The cups process (not the cups program) is constrained to its label.
[21:25]  * jdstrand nods
[21:26] <Casey_> You could also do it using rules thus ....
[21:26] <kees> so all the files that it can touch need to be labelled with "cups_blah" ?
[21:26] <Casey_> Right
[21:26] <jdstrand> ah
[21:26] <jdstrand> lightbulb
[21:26] <kees> yeah, that was the leap I hadn't made yet
[21:26] <Casey_> cups_blah cups_c w
[21:27] <jdstrand> Casey_: so then there is Netlabel for the networking parts? or is that something different
[21:27] <Casey_> cups_c cups_blah w
[21:27] <Casey_> Those two rules in /etc/smack/accesses (writen to /smack/load)
[21:28] <Casey_> whould allow the processes to talk to each other
[21:28] <Casey_> without using a multiplexer
[21:28] <Casey_> Smack uses netlabel.
[21:29] <kees> Casey_: what do you see as "next steps" for Smack in Ubuntu?  The 2.6.26 kernel is in intrepid now, so people could boot with smack enabled now.
[21:29] <Casey_> With those two rules the processes can't access each others files, that needs read access.
[21:29] <jdstrand> Casey_: so your smackpolyport command is really for connecting processes for communication. you'd still need to define all the labels for the diferent files touched-- correct?
[21:30] <propagandist> Casey_: wouldn't that also allow the clients to write to the servers conf files?
[21:30] <jdstrand> (and therefore smackpolyport is optional)
[21:30] <Casey_> Write access to files requires read access as well
[21:30] <propagandist> ah
[21:31] <Casey_> This is a sneekly artifact that makes servers easier
[21:31] <Casey_> because you don't need read access for packets
[21:31] <kees> I'd still like to see a Wiki document (e.g. https://wiki.ubuntu.com/UsingSmack) that is similar to the docs for AppArmor: https://help.ubuntu.com/community/AppArmor
[21:31] <propagandist> interesting...
[21:31] <jdstrand> re wiki> me too
[21:31] <kees> especially for helping people enable it, tweak things in the right places, etc.
[21:32] <kees> helping people with how to label files is, I think, the critical bit
[21:32] <jdstrand> and for methods of contraining labels
[21:32] <Casey_> If y'all are willing to host it, I'm happy to populate a wiki
[21:32] <kees> AppArmor consolidates that into profiles, and SELinux (iiuc) has utilities to convert policies into labels
[21:32] <Casey_> Right.
[21:33] <Casey_> With Smack you don't define labels
[21:33] <Casey_> You use them
[21:33] <kees> Casey_: yeah, start at https://wiki.ubuntu.com/UsingSmack and explain it like https://help.ubuntu.com/community/AppArmor
[21:33] <Casey_> Ok on the wiki then.
[21:33] <kees> Casey_: without labels written to disk, processes aren't very useful, IIUC
[21:34] <Casey_> attr -S -s SMACK64 -V 'MyDogHasNoNose' foo
[21:34] <kees> propagandist: is that accurate, btw: "SELinux has utilities that convert a policy into on-disk labels"?
[21:34] <kees> Casey_: while that might be second-nature to you, that's exactly the information I need.  :)
[21:35] <kees> and where does the r/w access mark go?
[21:35] <propagandist> kees: mostly ;o]
[21:35] <Casey_> Smack does FS defaulting (usually to '_')
[21:35] <Casey_> The r/w is in the rule.
[21:35] <Casey_> The basic rule is that if labels don't match there's no access
[21:36] <Casey_> an explicit rule (/etc/smack/accesses) "foo bar rw"
[21:36] <Casey_> says any process at foo can read or write an object at bat
[21:36] <Casey_> s/bat/bar/
[21:37] <Casey_> There is no access spec attached to the file
[21:37] <kees> Casey_: so I could organize labels like   cupsd_rw for all the files cups needs r/w access to
[21:37] <jdstrand> Casey_: and all labels/constrainsts need to be written in one monolithic file, /etc/smack/accesses, or no?
[21:37] <kees> and cupsd_r for files cups only needs to read.
[21:37] <kees> and then   cups  cupsd_rw   rw                cups cupsd_r   r
[21:38] <kees> in the accesses file?
[21:38] <kees> and then label all the files with cupsd_rw and cupsd_r
[21:38] <kees> (or have generalized labels like  nameservice_r and define   cups  nameserver_r r
[21:38] <kees> ?
[21:39] <jdstrand> kees: I think we'd need to do the later for quite a bit
[21:39] <kees> jdstrand: yeah, all "abstractions".
[21:39] <jdstrand> kees: so other processes could get at them
[21:39] <kees> Casey_: it sounds like people (well, me) need a "recommended best practices" for how to go about choosing labels for on-disk files, and examples for shared files, etc
[21:39] <Casey_> In general, you can run all your system services at '_' and that will protect them from users, who may run at 'User'
[21:40] <Casey_> Yes,
[21:40] <jdstrand> I was thinking about the interaction between cups and cups-pdf, and this 'abstraction' idea might be the way to do it
[21:40] <kees> I want to protect my users from services.  ;)
[21:40] <Casey_> Ah
[21:40] <kees> but, yeah,
[21:40] <kees> same all around.
[21:40] <Casey_> Well, again, services at _ can't write users at User
[21:40] <kees> okay, I feel like I have a better understanding here.
[21:40] <jdstrand> well, I think protecting services is one thing, and users is another-- both are useful and desirable :)
[21:41] <Casey_> There are folks who think each way
[21:41] <Casey_> Both can be right
[21:41] <Casey_> If you think "different implies no implicit access" you're good
[21:41] <Casey_> Mostly
[21:42] <kees> okay, so docs with examples and maybe a "best practices" for people to follow is "next steps", how does that sound?
[21:42] <Casey_> No rest for the wicked.
[21:42] <kees> [action] Casey_ to build up https://wiki.ubuntu.com/UsingSmack into something resembling https://help.ubuntu.com/community/AppArmor, along with possible "best practices" and examples.
[21:42] <MootBot> ACTION received:  Casey_ to build up https://wiki.ubuntu.com/UsingSmack into something resembling https://help.ubuntu.com/community/AppArmor, along with possible "best practices" and examples.
[21:42] <kees> :)
[21:42] <jdstrand> Casey_: is /etc/smack/accesses is single monolithic file, or can it be broken out into smaller bits?
[21:43] <jdstrand> Casey_: this could be important for packaging
[21:43] <Casey_> smackaccesses should remain small.
[21:43] <Casey_> Do you really need to protect CUPS from SSH?
[21:43] <kees> why wouldn't we?
[21:44] <kees> or rather, in a perfect world, yeah.
[21:44] <kees> they deal with different protocols, software, users
[21:44] <jdstrand> maybe this is conceptually 'default deny' vs 'default allow'
[21:44] <Casey_> Ah, why should you?
[21:44] <Casey_> Really, what value do you obtain>
[21:44] <kees> Casey_: paranoia?  :)
[21:45] <kees> I've seen some admins really want very strict separations
[21:45] <kees> but I understand that Smack is supposed to fill the middle ground
[21:45] <Casey_> They have SELinux if they're Granularity Gremlins
[21:45] <kees> hehe
[21:46] <Casey_> 800,000 lines of policy
[21:46] <Casey_> Does that make you feel secure?
[21:46] <jdstrand> Casey_: is it safe to say that configuring cups for smack protects cups from others, rather than prtecting others from cups?
[21:46] <Casey_> It works both ways.
[21:47] <Casey_> DIfferent labels with controlled access between them (default == none)
[21:47] <jdstrand> yes, it *can*, but it sounds like the general practice is the former. perhaps I am missing something
[21:48] <Casey_> Well, services are an interesting problem ....
[21:48] <jdstrand> perhaps I should wait and read your wiki, and things will be more clear
[21:48] <Casey_> each seems to have it's own issues/
[21:48] <jdstrand> I feel I have a better understanding as is, but the practical application/best practices are what I'd like to see
[21:48] <Casey_> CUPS needs to to top&bottom labeling for LSPP
[21:49] <Casey_> It will need to be cognizant, eventually.
[21:49] <kees> sorry to possibly cut discussion short -- I've got to head off to other things.  Is meeting again in 2 weeks good?  that'd be the 3rd of July, same time.
[21:49] <jdstrand> Casey_: speaking of that, is this something you hope to get upstream, and if so, how are upstreams reacting to smack?
[21:50] <Casey_> Slowly. I have lots more work to do ....
[21:50] <propagandist> kees: the 3rd is good
[21:50] <Casey_> selling the value, they all would like to see a disto take the lead,
[21:51] <Casey_> so they don;t end up with dead code in a year
[21:51] <Casey_> The 3rd is ok by me, too.
[21:51] <kees> #endmeeting
[21:51] <MootBot> Meeting finished at 15:54.
[21:52] <kees> feel free to keep discussing -- I just have to split :)
[21:52] <Casey_> Ok, thanks. Anyone what to hear more?
[21:52] <propagandist> kees: good meeting, thanks kees
[21:52] <jdstrand> thanks kees!
[21:53] <propagandist> Casey_: ;o] of course
[21:53] <kees> thanks everyone for coming.  :)
[21:53] <Casey_> Thank you
[21:53] <jdstrand> Casey_: I'm quite interested in smack, but would like to read your wiki. then I'm sure to have a bunch of questions :)
[21:53] <Casey_> No doubt
[21:53] <propagandist> Casey_: Will all services need be smack aware under LSPP?
[21:53] <Casey_> Nope.
[21:53] <Casey_> Many will
[21:54] <Method> i think the correct question is "will smack ever be certifiable under LSPP"
[21:54] <Casey_> Some are just uninteresting, serving up "public" information
[21:54] <Casey_> Method: yes
[21:54] <Method> wrong answer
[21:54] <Method> :)
[21:54] <Casey_> DO tell
[21:55] <propagandist> Casey_: thanks, i'm looking forward to your wiki
[21:55] <Method> you can't implement both a lattice and category sets at the same time
[21:55] <Method> at least not easily
[21:56] <Method> selinux wouldn't have needed explicit mls support if TE alone was sufficient
[21:56] <Casey_> Method: I can describe how it's done, but it's more than one line.
[21:57] <Method> i'm aware, we've had this converstation before :)
[21:57] <Casey_> Well then.
[21:58] <Casey_> The issue is a complete set of labels implied by the lattice, which is large, verses the actual used set, which in practice is small.
[21:59] <Casey_> Real MLS installations use 3 site defined labels.
[21:59] <Casey_> Either 3 levels or 3 categories
[22:00] <Casey_> Since the late 1980's I have never sween them mixed.
[22:00] <Method> well, i'm working with someone now that uses several levels and hundreds of categories
[22:00] <Casey_> All at once?
[22:01] <Method> yep, on tsol currently
[22:01] <Casey_> Is anyone ever in more than one category at a time?
[22:01] <Method> most users are in most categories
[22:01] <Method> plus they are using some categories for releasibility
[22:01] <Method> their label_encodings file is scary :\
[22:02] <Casey_> I bet. In the end they just use the aliases I suspect
[22:03] <Casey_> For the accesses they really want, I have a beer says the smack rules would be simpler
[22:03] <Method> they use prefixes for releasibility
[22:04] <Method> which may be true, but that doesn't mean anyone will consider that sufficient for lspp ;)
[22:06] <Casey_> I've been through the LSPP (and B1) mill and had to do some serious education, and I think that this is simple enough to get the point through.
[22:06] <Casey_> Maybe a tool to generate rules based on B&L, or to check that a rule set doesn't violate B&L
[22:07] <Casey_> I've done sillier things
[22:07] <Casey_> Looks as if the next meeting here is ramping up.
[22:08] <Casey_> Thank you. Ta.
[22:09] <kees> (feel free to move to #ubuntu-hardened)
[22:09] <kees> oop