[08:58] <pitti> hi
[08:58] <seb128> hey pitti
[08:58] <ogra> mrning pitti 
[08:58] <pitti> seb128: here for the hide-admin-tools issue?
[08:59] <Seveas> ah, TB meeting
[08:59] <Seveas> that explains activity :)
[08:59] <ogra> wow, huge agenda :)
[08:59] <seb128> pitti: nop, just /j-ed because I've seen it was TB on my eds calendar and I'm around, I've not looked on the agenda :)
[09:00] <\sh> jumping from one meeting to another
[09:00] <seb128> pitti: because if you speak about hide-admin-tools I'm interested :)
[09:00] <ogra> edubuntu too :)
[09:00] <dholbach> mako wants to become a MOTU
[09:00] <ogra> finally
[09:00] <ogra> *g*
[09:01] <\sh> WHAT?
[09:01] <ogra> dholbach, tell him he has to send a $100 laptop to every MOTU first :)
[09:01] <dholbach> https://launchpad.net/people/ubuntu-dev/+members
[09:01] <dholbach> yeah
[09:01] <dholbach> that'd make sense
[09:02] <\sh> hmm...i never worked with him, I saw him never in #ubuntu-motu..,)
[09:02] <ogra> did mdz forget us ? 
[09:02] <mdz> no
[09:02] <ogra> :)
[09:02] <mdz> workrave waits for no man
[09:02] <ogra> lol
[09:02] <Seveas> hehe
[09:02] <mjg59> I'm actually here on time, for once
[09:02] <Seveas> workrave is a bitch ;)
[09:02] <mdz> Keybuk said he probably wouldn't be able to make it
[09:03] <mdz> and I expect the same for sabdfl as he's travelling
[09:03] <ogra> Seveas, obviously self chosen
[09:04] <mdz> I think we can call this a quorum though
[09:04] <mdz> there is one candidate for the core development team, Sebastian Drge
[09:04] <mjg59> Shall we get on with things, then?
[09:04] <mdz> is that slomo?
[09:04] <dholbach> slomo, are you there?
[09:05] <dholbach> mdz: yes
[09:05] <mdz> launchpad says yes
[09:05] <ogra> yup, thats slomo 
[09:05] <mdz> slomo_: hello
[09:05] <mdz> we were just looking for you
[09:05] <slomo_> hi everybody, hi mdz :)
[09:06] <slomo_> mdz: yes, ogra told me... sorry
[09:07] <mdz> slomo_: you mention on your wiki page that you maintain a package in Debian; are you a DD or do you have a sponsor?
[09:07] <slomo_> mdz: currently i only have some sponsors but i want to apply for NM in some months/weeks
[09:08] <mdz> slomo_: who are your sponsors?
[09:08] <slomo_> mdz: dajobe, ajmitch and lool
[09:08] <mdz> are any of them present?
[09:09] <mdz> maybe ajmitch, I'd like to hear from him
[09:09] <sistpoty> ajmitch said he'd be on his way to work 10mins ago
[09:09] <slomo_> he left only some minutes ago afaik :/ and the others are not present
[09:09] <mjg59> slomo_: Your wiki page lists a couple of packages that are also in Debian (the musepack ones, from a quick search) - what the situation there?
[09:10] <mdz> slomo_: do you have any specific plans which require upload privileges for main?
[09:10] <slomo_> mjg59: i definitly have to update my wiki page ;) the xmms-musepack was uploaded by someone else some weeks ago... but i plan to get my bmp-musepack package in when i find a sponsor with some time... the other's are ubuntu only atm and i've itps for them
[09:11] <mjg59> slomo_: Ok, cool
[09:11] <slomo_> mdz: i want to work mostly on mono specific packages, helping ajmitch and tseng... but if some help is needed elsewhere i'm happy to help out wherever i could be useful
[09:11] <ogra> mdz, we could drop xine on him ;)
[09:11] <ogra> slomo does a lot with multimedia packages
[09:12] <\sh> slomo is a tough guy for the hard nuts ... MOTU owe him a few 
[09:12] <mdz> slomo_: which packages, and what sort of work?
[09:13] <ajmitch_> morning
[09:13] <slomo_> mdz: for mono? the complete mono stack from ground up... i.e. cli-common, mono, gtk#, monodoc, etc
[09:15] <ogra> Keybuk!!
[09:15] <mdz> slomo_: what would you like to change about those packages presently?
[09:16] <mdz> Keybuk: (slomo, https://launchpad.net/people/slomo applying for ubuntu-core-dev)
[09:16] <slomo_> mdz: get the latest stuff in, get everything working fine together and we plan to get some more mono specific packages like gtk#2 for example to main for dapper
[09:17] <ajmitch_> mdz: what would you like to ask about the sponsored packages or other work?
[09:17] <mdz> slomo_: what is needed in order to get everything working well together?
[09:17] <mdz> ajmitch_: yes, feel free
[09:18] <ajmitch_> ok, slomo has done most of the mono work for dapper that was required for merging debian changes
[09:18] <ajmitch_> he's worked well with the debian mono team to get issues sorted out
[09:19] <ajmitch_> and the packages I've had time to sponsor have been very clean, with few things to fix up or clarify
[09:19] <ajmitch_> I'd like to see him able to upload the mono stuff directly to main, especially as we get more of it in
[09:20] <mdz> ajmitch_: thanks
[09:20] <seb128> mdz: slomo_ works on gst-plugins-multiverse, he seems to be good job to coordinate with the main package and work with the Debian maintainer on changes too
[09:20] <seb128> s/seems//
[09:20] <mdz> seb128: that's great ,thanks
[09:20] <seb128> s/seems to be/do/
[09:20] <ogra> and slomo mainly maintains mplayer nowadays
[09:21] <ogra> and ffmpeg etc ...
[09:21] <mdz> slomo_: are you still there?
[09:21] <slomo_> mdz: mostly dependencies between those packages... they're very closely tied. or for example when when updated to mono 1.1.9 some packages broke because of stricter compiler so these needed to be fixed too
[09:21] <mdz> slomo_: what can we do to make that situation better?
[09:22] <slomo_> mdz: sure, i needed to sort my thoughts a bit... i wasn't really prepared for this right now ;) i didn't know there was a meeting
[09:22] <mdz> slomo_: if you would prefer to wait until the next meeting, that's no problem
[09:22] <slomo_> mdz: mostly work with upstream to get everything in a stable state
[09:23] <mdz> slomo_: I'm looking for specific and concrete actions that you would like to take in main, as examples of what we could expect from you
[09:23] <ajmitch_> upstream being debian or real upstream of the programs that break?
[09:24] <slomo_> mdz: ok... well, you could expect from me that i get the latest versions in until UVF, trying to keep breakages at the lowest level possible and get some more mono specific packages from universe to main and caring for them there
[09:25] <mdz> slomo_: how would this relate to the work that tseng is currently doing on mono?
[09:26] <slomo_> mdz: i would do exactly the same stuff he does... we would share the work between us to get more work done in shorter time
[09:27] <slomo_> ajmitch_: both
[09:27] <slomo_> mdz: also ogra's idea about working on multimedia packages appeals to me... for example i maybe could help seb128 with the transition to gst 0.10 later if he wants it... so if there is some work to be done in this area i would gladly help out
[09:28] <mdz> slomo_: have you seen https://launchpad.net/distros/ubuntu/+spec/video-playback ?
[09:28] <mdz> I would like to hear your ideas about how we could provide the best unencumbered video playback capability in the default install
[09:29] <slomo_> mdz: not yet, but i know that problem but haven't thought about a appropriate solution for it yet... but a/v sync problems should become better with gst 0.10 afaik
[09:30] <seb128> slomo_: are you interested by splitting xine for this? :)
[09:31] <mjg59> slomo_: We don't have a terribly good reputation as a multimedia distribution at the moment. Given the constraints we have (patents, free software) how do you see us changing that?
[09:31] <slomo_> seb128: why not? but what exactly needs to be split off? well, let's talk about this later
[09:31] <mdz> slomo_: he's talking about the video-playback spec I referred to earlier
[09:32] <mdz> slomo_: do you have some ideas for any feature goals you would be interested in working on during the Dapper cycle, either something already in the spec tracker or an idea of your own?
[09:32] <seb128> slomo_: the "Split xine such that only the Xiph codecs (and perhaps additional, unencumbered ones) are supported in main, the others will be shipped in universe" of the spec
[09:33] <slomo_> mjg59: in regards to patents we currently support the most formats we are allowed to... improving on them would imho be the only way to get better. and these are most problems i heard people had with ubuntu.... i.e. they can't play their dvds out of the box
[09:33] <mjg59> slomo_: Do you think we can do a better job of making it clear why they can't?
[09:33] <slomo_> mdz: mostly the avahi goal but this is obviously completly unrelated to everything i talked about yet
[09:34] <slomo_> seb128: sure, i could try splitting it that way
[09:34] <seb128> would be nice :)
[09:34] <seb128> thanks!
[09:34] <slomo_> mjg59: only by writing more documentation... i see no other way. but currently the wiki already includes all this informations so no idea :/
[09:35] <mjg59> slomo_: At the moment, I think we're integrating the technical side of multimedia into the distribution fairly well, but the social side is less clear
[09:36] <slomo_> mjg59: yes but except doing more documentation, maybe writing a "multimedia guide" or something similar i see no way to let the people know why we can't support for example dvd playback out of the box
[09:37] <mjg59> It would be good to think about ways we can improve that in the distribution, rather than just referring people to the wiki
[09:37] <Burgwork> totem/rb needs to be able to tell people what specific codec they need
[09:37] <mjg59> The totem user experience in Ubuntu is currently fairly dire
[09:37] <mdz> slomo_: on your wiki page you mention that you find FreeBSD to be a superior server platform.  can you elaborate on this, and suggest specific improvements which could make Ubuntu a more natural choice for servers?
[09:38] <slomo_> and for general improving of playback of all kinds of formats i think we should try to get more tests done... some of the issues which showed up after release like the dvd playback problem caused by gst-ffmpeg would be detected much earlier and could be tried to fix
[09:38] <slomo_> mjg59: yes, i know nobody who uses totem atm because it's too unstable for them :( that needs to be improved somehow
[09:39] <mdz> I use totem and have not found it unstable
[09:40] <Burgwork> slomo, is that something we can push on to the laptop testing team? They already have the hardware
[09:40] <slomo_> mdz: i think ubuntu is on the best way to be better on the server side. i started using freebsd on servers already some time ago and the biggest advantage i saw was that you had a main system which is perfectly integerated and almost bug free... but imho the same already applies to ubuntu now... in fact i'm already using ubuntu on one server now
[09:41] <slomo_> mdz: it's mostly the applet or when playing wmv/quicktime... for "normal" formats it works well... normal beeing xvid, theora, vorbis, etc
[09:42] <mdz> slomo_: what do you think we could do to better test multimedia support as you propose?
[09:44] <slomo_> mdz: get a bunch of people who regurlary test popular and unpopular formats... and report their problems ;) maybe make a list of formats we can play and check if it works regularly
[09:45] <ogra> slomo_, volunteering to make a testplan ? ;)
[09:45] <dholbach> ogra: add it to: https://wiki.ubuntu.com/TestPlans :)
[09:45] <ogra> hehe
[09:46] <ogra> dholbach, only if he says he does ;)
[09:46] <slomo_> ogra: sure... i think i can try to get something reasonable done soon :)
[09:46] <ajmitch_> ogra: why? just volunteer him for it
[09:47] <ogra> ajmitch_, i'm the evil recruiter, but not *that* evil :)
[09:47] <mdz> slomo_: what I would suggest is to extend https://launchpad.net/distros/ubuntu/+spec/test-plans to include a simple multimedia test in the test plan
[09:47] <ajmitch_> ogra: go on, take the next step ;)
[09:47] <mdz> slomo_: perhaps you could work with dholbach on this
[09:47] <dholbach> i'm happy to
[09:48] <slomo_> mdz: sure... sounds good :)
[09:48] <mdz> slomo_: and also to help with https://launchpad.net/distros/ubuntu/+spec/example-content to ensure that we have a good test video stream in the default install to facilitate that
[09:48] <mdz> mjg59: do you have any further questions you'd like to ask?
[09:48] <mdz> if not, I'm ready to call a vote
[09:49] <mjg59> I think I'm done
[09:50] <mdz> ok, votes?
[09:50] <ogra> +1 (if i could)
[09:50] <mdz> ogra: please leave the voting to the board
[09:51] <mjg59> I think +1, based on the discussion of a testing regime and thinking about improving the entire user experience
[09:51] <mdz> +1 from me based on positive feedback from the development team and the potential for solid contributions to main
[09:52] <mdz> slomo_: congratulations, thanks and welcome
[09:52] <ajmitch_> well done slomo_ 
[09:52] <slomo_> thanks everybody :)
[09:52] <dholbach> EXCELLENT
[09:52] <seb128> slomo_: congrats
[09:52] <seb128> slomo_: I'll ping you for gst0.10 so :)
[09:52] <\sh> I read correctly: only two votes? was it the first time that a main dev had only two votes?
[09:52] <mdz> \sh: no, we have many times had 2/3 votes
[09:52] <dholbach> slomo_: now if i might invite you to #ubuntu-desktop, we have some things to discuss ... :-p (seb: we have him)
[09:53] <mdz> but today we have only 2/4 present and 2/2 votes
[09:53] <\sh> mdz: oh ok :)
[09:53] <sistpoty> congrats slomo
[09:53] <\sh> dholbach: don't take him away from the motu...
[09:53] <mdz> janimo: you proposed yourself for core-dev during the meeting; did you intend to apply during this meeting or for the next one?
[09:53] <slomo_> dholbach: sure, but i don't have that much time today anymore ;) need to do some university stuff now... only made a break for the meeting now ;)
[09:53] <slomo_> \sh: don't worry :)
[09:53] <janimo> mdz, no hurry, as long as xfce is still in universe
[09:53] <janimo> next time is fine
[09:54] <mdz> janimo: since we've been here an hour already and have more agenda already, if you don't mind waiting, I think that would be better
[09:54] <janimo> ok, np
[09:54] <mdz> we seem to have 3 new MOTU candidates since the last meeting
[09:55] <dholbach> mako :)
[09:55] <mdz> zakame doesn't seem to be here
[09:55] <mdz> mako: ping
[09:55] <mdz> bojan doesn't seem to be here
[09:55] <ajmitch_> sadly, since zakame has been doing a fair bit of work lately with merges
[09:55] <\sh> hmmm...
[09:55] <mdz> mjg59: I'm comfortable considering mako in absentia if you are, since we know him quite well already
[09:56] <dholbach> what happened to bmonty?
[09:56] <\sh> bmonty can't be here again.....but I would like to propose a vote in absentia 
[09:56] <mjg59> Yup
[09:56] <\sh> because bmonty did now a great work during the merge etc. and I really like to see him in the team.
[09:56] <mdz> +1 from me for mako, no-brainer based on past contributions to both Debian and Ubuntu
[09:56] <mjg59> +1 for mako, too
[09:57] <mdz> done and done
[09:57] <ajmitch_> that was a quick appointment :)
[09:57] <\sh> mako: do some merges asap :) 
[09:57] <Seveas> wow, fastest ever I guess :)
[09:57] <ogra> yes, bmonty was postponed several times ...
[09:57] <dholbach> \sh: i watched his work too, and i was impressed, by how much bmonty did during those merges
[09:58] <mdz> mako has been contributing to Ubuntu since its inception and has only now decided to apply officially ;-)
[09:58] <\sh> dholbach: yes .. I did some uploads for him the last days...and I'm impressed
[09:58] <ogra> and prepares uploads all the time for us ... its a bit sad
[09:59] <sistpoty> yes... the few packages of bmonty i came to look over showed good packageing skills. and he did _lots_ of work
[09:59] <slomo_> bmonty would also get a vote by me... he does _SO_ many merges lately we almost can't keep up with uploading his stuff
[10:00] <sistpoty> and he interacts with debian (files bug w. patches in BTS for stuff he changes)
[10:00] <mdz> is he mostly doing trivial merges from MOM or more in-depth merging as well?
[10:01] <\sh> mdz: both
[10:02] <mdz> ok
[10:02] <\sh> mdz: most of universe is trivial only one out of 50 is really non trivial
[10:02] <\sh> (forgetting the gstreamer universe packages of slomo)
[10:03] <mdz> mjg59: any questions regarding bmonty?
[10:03] <\sh> sistpoty: and some syncs he couldn't request
[10:03] <mjg59> mdz: Don't think so - motu reports sound good
[10:04] <mdz> yes, while he isn't present there are several people here willing to provide testimonials
[10:04] <\sh> sistpoty: and not all of his reports are uploaded actually
[10:04] <mdz> votes?
[10:04] <ogra> he was really patient with being postponed from meeting to meeting ...
[10:04] <mjg59> +1 from me
[10:04] <mdz> +1 from me based on testimonials from several regular MOTU contributors and reviewers, both at this meeting and previous ones
[10:04] <dholbach> cool :)
[10:04] <ajmitch_> we'll inform him of the good news then
[10:04] <mdz> dholbach: will you pass on the news to him personally?
[10:04] <sistpoty> \sh: very true... we need to sponsor more uploads. I think I'll go for this tonight... -> motu after meeting
[10:04] <ogra> welcome bmonty in absentia !
[10:05] <dholbach> mdz: i will
[10:05] <\sh> mjg59 / mdz: thanks :)
[10:05] <mdz> dholbach: thanks, send my congratulations
[10:05] <dholbach> mdz: as personally, as internet lets me :)
[10:05] <\sh> dholbach: blog it :)
[10:05] <dholbach> we don't have a MOTUPhoneNumber page yet :)
[10:05] <\sh> dholbach: I know he is reading the planet :)
[10:05] <\sh> +49 700 sourcecode? ,-)
[10:05] <mdz> there are 18 pending applications in launchpad right now
[10:05] <Seveas> Dial M for MOTU ;)
[10:06] <\sh> or should I get +49 700 motu ?
[10:06] <mdz> ogra,dholbach: would you ping each of them and confirm that they still intend to apply and will attend a meeting?  we need to clean out that list
[10:06] <ogra> mdz, 90% of them i've never heard of
[10:06] <dholbach> mdz: i know 3 of those missing ones
[10:06] <ogra> or seen them on irc
[10:06] <dholbach> mdz: that's sivang, vuntz and zakame
[10:06] <mdz> if you've never heard of them, they should receive a form letter explaining how the process works
[10:06] <pitti> btw, what about cleaning up members which are inactive? like astaroth?
[10:07] <ogra> most of them dont even have a wikipage
[10:07] <dholbach> mdz: i will take care of that
[10:07] <mdz> dholbach: thank you very much
[10:07] <dholbach> de rien
[10:07] <ajmitch_> pitti: I think maintainership was meant to have a year or 2 year term, right?
[10:07] <pitti> ajmitch_: ah, ok
[10:07] <mdz> pitti: what is astaroth's real name?
[10:07] <pitti> mdz: Gerardo di Giacomo
[10:08] <pitti> mdz: the guy who helped with universe security updates until he became a MOTU
[10:08] <pitti> it's by no way urgent to remove him, this example just came into my mind
[10:08] <mdz> pitti: please ping him and see if he intends to contribute in the future
[10:08] <pitti> yes, will do
[10:08] <dholbach> same for some other folks
[10:08] <mdz> pitti: we should not generally deactivate anyone simply because they go inactive; we have the expiration process for that
[10:09] <zakame> hi all
[10:09] <ajmitch_> hi zakame 
[10:09] <\sh> dholbach: we should discuss how we should proceed with this "problem"
[10:09] <dholbach> \sh: it's hard to decide... pinging back is the only thing, i can think of - there are times in life, where you simply don't have the time or drive to do it
[10:09] <mdz> \sh: a reasonable approach is to contact them and ask their intentions.  if they say that they can't or won't contribute anymore, they can voluntarily deactivate themselves in launchpad
[10:10] <mdz> \sh: and if they don't respond, they will eventually expire
[10:10] <\sh> mdz: ok..so the expiration process is already working :)
[10:10] <mdz> zakame: just in time
[10:10] <zakame> mdz: thank you :)
[10:11] <ajmitch_> mdz: will we have to undergo another interrogation around expiry time? :)
[10:11] <mdz> dholbach: you mentioned that you had some experience working with zakame?
[10:12] <mdz> ajmitch_: we have some time to finalize that part of the process ;-)
[10:12] <ogra> zakame, nice wikipage :)
[10:12] <zakame> ogra: many thanks :)
[10:12] <dholbach> mdz: that i "knew him" and watched his progress - he's been fairly busy in the mergers crew and iirc did some std allocator changes as well
[10:13] <dholbach> mdz: i have 217 bug mails from him, mostly merges, some bug triaging work as well
[10:13] <zakame> just a couple for c2a i think... libcommoncpp2 was already done in debian, and my most recent one was for MAS
[10:14] <dholbach> i'm not too familiar with his work, but what he said in #ubuntu-motu usually was sound
[10:15] <ogra> zakame, you dont mention that you help in edubuntu too on your wiki ....
[10:15] <sistpoty> though I haven't reviewed much of his work, I'm impressed by zakame's amount of work... 
[10:15] <\sh> oh yes..zakame is just hard working like bmonty or ajmitch, slomo, siretart, sistpoty or my person.
[10:15] <mdz> zakame: I happened to notice your merge of lostirc; it looks like the only Ubuntu-specific change had been to update to a new upstream version, which is now in Debian.  why was this a merge rather than a sync?
[10:15] <\sh> I had a view over his work, and his debdiffs were very good, for the time he's doing motu work. I'm happy to have him in the team
[10:17] <zakame> mdz: hm, you're right, this seems to just update aclocal.m4, and yes, S-V :(  my bad!
[10:17] <\sh> mdz: beginners luck I would name it...because I'm the one who has "beginners luck" all the time...;)
[10:18] <zakame> ogra: Ooh!  I forgot that part!  very sorry!!!
[10:18] <ogra> mdz, zakame expressed interest to help in edubuntu ... 
[10:18] <mdz> zakame: please be careful with that in the future; each package which is diverged creates more work for the team
[10:19] <ogra> zakame, was it doc or dev ? 
[10:19] <zakame> mdz: yes, I'll keep that in mind
[10:21] <mdz> zakame: who sponsors your uploads to Ubuntu usually?
[10:23] <zakame> ogra: hm, I'm collaborating with some teachers at the local school to implement an edubuntu system... we currently are running hoary, but I managed to get hold of edubuntu yesterday, so we'll be trying to upgrade maybe this afternoon
[10:23] <ogra> cool
[10:24] <\sh> mdz: nafallo and I
[10:24] <zakame> mdz: Nafallo_away did most of the sponsoring, though most recently \sh sponsored logilab-common and another...
[10:25] <\sh> zakame: we'll take a look for the others...actually I was busy merging during the weekend...so I have to find the time to get all pending uploads done from malone
[10:25] <mdz> mjg59: anything else before voting?
[10:25] <mjg59> Don't tihnk so
[10:25] <zakame> \sh: thanks again :) most of them are PendingSync
[10:25] <mdz> likewise
[10:26] <mdz> +1 based on my own examination of various uploads, testimonials from MOTU and discussion
[10:26] <\sh> zakame: if you can provide me a list of malone numbers :) that would be great :)
[10:26] <mjg59> +1 based on the MOTU opinions
[10:26] <ogra> \sh, see wikipage :)
[10:26] <mdz> zakame: welcome aboard
[10:26] <dholbach> that's brilliant news :)
[10:26] <sistpoty> congrats zakame
[10:26] <ogra> yay, welcome zakame 
[10:26] <minghua> zakame: congratulations. :-)
[10:26] <\sh> zakame: welcome aboard :) good shot :)
[10:26] <slomo_> zakame: congrats :)
[10:27] <mdz> pitti: you wanted to discuss something regarding sudo?
[10:27] <pitti> right
[10:27] <ajmitch_> zakame: well done
[10:27] <zakame> yay!
[10:27] <pitti> http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013260.html
[10:27] <pitti> ^ for reference
[10:27] <zakame> many thanks all! :)
[10:27] <pitti> there was not much fruitful discussion
[10:27] <mdz> right, this thread is long and I haven't had a chance to read it yet
[10:27] <pitti> the problem is in short:
[10:28] <pitti> initially we wanted to use sudo -t command to check whether an user can execute command
[10:28] <\sh> zakame: cool page :) I'll work with the information from this page 
[10:28] <zakame> \sh: thanks
[10:28] <pitti> if that would log auth failures, then it would remain compatible with default sudo behaviour on servers and not circumvent security checks
[10:28] <mdz> pitti: I think extending sudo to parse the .desktop file adds undesirable complexity to a setuid root program
[10:29] <pitti> mdz: I only see two options TBH: parse .desktop files in sudo or fall back to the broken group check
[10:29] <pitti> mdz: parsing .desktop files would nicely solve the desktop/server conflict
[10:29] <pitti> on servers there won't be .desktop files, so that sudo checks are not impeded
[10:29] <pitti> and on desktops we would avoid the log clutter from failed checks
[10:30] <mdz> pitti: it would certainly be nice to avoid execing sudo so many times during every login
[10:30] <pitti> mdz: well, we need to execute it once for every desktop file that wants root
[10:30] <mjg59> pitti: The sudo -t case would presumably also result in error mails every time someone logs in?
[10:30] <pitti> i. e. maybe 15 times for a normal system per login
[10:30] <ogra> how would that cope with the gnome speeup plans ? 
[10:30] <ogra> *speedup
[10:30] <pitti> mjg59: right, that's the most annoying thing right now
[10:31] <mjg59> Why are we trying to achieve this?
[10:31] <mdz> mjg59: in order to simplify the menus for unprivileged users
[10:31] <pitti> mjg59: we want to hide admin tools from the menu for users who aren't admins
[10:31] <mdz> i.e., don't show them administrative tools requiring sudo if they won't be able to use them
[10:31] <pitti> https://wiki.ubuntu.com/HideAdminToolsToUsers
[10:31] <mjg59> Surely a common use case is that an admin will wish to debug things while a user is logged in?
[10:31] <mdz> mjg59: the menu items have no chance of working unless the user has sudo rights
[10:31] <Mithrandir> pitti: can't we write a helper which is suid root and parses the desktop files and asks sudo "can this user run this command"?
[10:31] <mjg59> Hrm. True.
[10:31] <pitti> mjg59: 'run program as another user'
[10:32] <ogra> and the worst thing is that they just silently fail
[10:32] <pitti> Mithrandir: what would that solve?
[10:32] <pitti> Mithrandir: sudo would still log violations
[10:32] <Mithrandir> pitti: it would not put the desktop parsing code in sudo.
[10:32] <pitti> Mithrandir: and doing the check in sudo is safer than writing a new program from scratch
[10:32] <mjg59> ogra: I think the silent failure is a bug in itself, but still...
[10:32] <ogra> yup
[10:32] <mdz> Mithrandir: that code would still run as root, though
[10:32] <Mithrandir> mdz: yes, but it would be easier to merge from debian that way.
[10:33] <pitti> I mean, parsing is not terribly difficult
[10:33] <pitti> but of course it must be done carefully
[10:33] <mjg59> But surely this inevitably subverts part of sudo's security?
[10:33] <Mithrandir> pitti: I just don't see upstream wanting to incorporate that patch, without knowing sudo upstream.
[10:33] <mdz> pitti: is there a program which is run whenever a new .desktop file is instaled?
[10:33] <pitti> mjg59: to the extent that an intruder can check commands mentioned in installed (root owned) desktop files
[10:33] <mdz> pitti: one approach would be to have such a program dump a list of all of the relevant commands to a (trusted) file and have sudo suppress its error reporting for any command listed exactly in that file
[10:33] <pitti> mjg59: but on desktops we can safely forget about logging anyway
[10:34] <mjg59> pitti: Which, in a standard ubuntu install, amounts to everything
[10:34] <pitti> mdz: dpkg install hooks? (SCNR)
[10:34] <mvo> there is dh_desktop 
[10:34] <pitti> mjg59: why everything?
[10:34] <pitti> mjg59: on a server there won't be any/many desktop files
[10:34] <mjg59> pitti: If a user has sudo rights to execute admin tools, they have sudo rights to execute anything
[10:34] <pitti> and seriously, whoever runs sudo under X doesn't need to care about the logging
[10:35] <pitti> mjg59: under X at least (event injection, etc.)
[10:35] <mdz> pitti: what does a hypothetical attacker gain by being able to test for sudo rights in this way?  any attempt to use those rights is more closely scrutinized
[10:35] <pitti> mjg59: but the case I worry about is to not impede server security checks
[10:35] <mjg59> To be honest, I'm fairly strongly of the opinion that we should just accept that we made a mistake in Warty, cut our losses and just display them for users in the admin group and otherwise not do so
[10:35] <mdz> pitti: for the common case, any unprivileged user on the system can already check for membership in the admin group
[10:35] <pitti> mdz: he can silently poke around to check which privileges a cracked user account has
[10:36] <pitti> mdz: right now, sudo immediately mails out failures to the admin
[10:36] <mjg59> Rather than produce a complex solution that provides extra information leakage about what rights a user has
[10:36] <pitti> mdz: so that the admin can quickly close the user account, etc.
[10:36] <mdz> mjg59: if we do that, we need to heuristically add users to the admin group on upgrades
[10:36] <pitti> mjg59: but that's not just a warty upgrade issue
[10:36] <mjg59> mdz: No, we can document it in the release notes
[10:36] <mdz> pitti: they can already do that silently with 'groups'
[10:36] <pitti> sudo is more flexible than just crude admin/no admin 
[10:36] <mjg59> "Admin applications will only be visible to users in the admin group"
[10:37] <dholbach> sorry, i'll leave now, because i'm dead tired - good night
[10:37] <mjg59> pitti: Yes, but it's not the sudo case that we care about really
[10:37] <ogra> bye dholbach 
[10:37] <mdz> mjg59: we don't display the release notes on upgrades yet
[10:37] <zakame> bye dholbach :)
[10:37] <pitti> mjg59: well, the question is if we do...
[10:37] <mjg59> What we care about is "should this user see these icons"
[10:37] <pitti> I don't see why we should force admins to use the admin group
[10:37] <mjg59> pitti: Because it's the existing mechanism for flagging user capabilities
[10:37] <mdz> pitti: I don't think we should; I'm just pointing out that we already make most of this information available by using the admin group the way wedo
[10:38] <pitti> mdz: not on my server :) I use /etc/suders to directly configure allowed commands for users, not via groups
[10:38] <mjg59> In the brave new world of selinux, the obvious thing to do would be to have admin users have an selinux capability
[10:38] <pitti> mdz: I agree, when the admin group is used, the case is trivial
[10:38] <ajmitch_> that brave new world won't be on by default in dapper 
[10:38] <mdz> and that is our default configuration for Ubuntu
[10:38] <Mithrandir> mjg59: what would we do in the cases of people being allowed to do some things as root, but not all?
[10:39] <ogra> mdz, not for warty upgraded systems
[10:39] <mjg59> Limiting visiblity to people in the admin group fixes the vast majority of cases that we're worried about, and doesn't involve us developing what is, effectively, a new authentication mechanism
[10:39] <mdz> ogra: that is missing the point
[10:39] <ogra> mdz, that will be a good bunch of users ....
[10:39] <pitti> mjg59: but that makes the usage of non-group sudo impossible
[10:39] <janimo> checking sudo -t only once and then using a blacklist of apps which are not to be shown? would that not scale?
[10:39] <mjg59> pitti: No it doesn't
[10:39] <pitti> mjg59: since then the users would never see the desktop files
[10:40] <mjg59> pitti: The apps can be run from a shell
[10:40] <mdz> ogra: the only reason not to use sudo for this is that it reveals information
[10:40] <pitti> mjg59: right, of course
[10:40] <pitti> I mean in terms of correct menus
[10:40] <mjg59> pitti: They can launch a shell, add themselves to the admin group and then re-login
[10:40] <mdz> ogra: but that is only the case if the user has extensively customized the system, since our default configuration and tools reveal it already
[10:40] <pitti> mjg59: erm?
[10:41] <mdz> janimo: what would the blacklist contain?
[10:41] <pitti> mjg59: if I allow an user to run only a particular command as root, he can't
[10:41] <pitti> janimo: that doesn't react to changes
[10:41] <janimo> the apps which are to be run only as sudo 
[10:41] <mjg59> pitti: Are you suggesting that certain users should have access to specific admin tools, but not all?
[10:41] <janimo> changes as in introducing new packages?
[10:41] <pitti> janimo: we already know this, it's in the desktop files
[10:41] <mjg59> pitti: Making icon visibility depend on being in the admin group doesn't mean that the admin group must have full sudo rights
[10:41] <ogra> mdz, my initail reaction was the same as yours, but Kamion made some valid points i cant remember currently ... sad he isnt here
[10:41] <pitti> mjg59: why not? I could allow an user to set the time, but nothing else
[10:42] <mjg59> pitti: It's an insanely tiny use-case
[10:42] <pitti> well, ok, if we say that we basically ignore /etc/sudoers and jsut support admin group, that's fine for me
[10:42] <mdz> mjg59: we don't need to account for it in our defaults, but we should avoid making it impossible if w ecan
[10:42] <pitti> I just want to have that decision formally settled
[10:43] <mjg59> mdz: It would still be possible by changing the semantics of the admin group on that system
[10:43] <mdz> mjg59: how do you mean?
[10:43] <mjg59> mdz: Don't give admin users sudo rights
[10:43] <pitti> mjg59: no, you need several groups then, which we don't suport
[10:43] <pitti> mjg59: well, we could have a mapping somewhere
[10:43] <mjg59> pitti: We don't support it how?
[10:43] <pitti> group -> desktop files
[10:44] <mdz> mjg59: hmm
[10:44] <mjg59> I mean, you /could/ solve this just by having the desktop files be 640, right?
[10:44] <pitti> mjg59: i. e. the menu only reflects admin membership, not the actual privileges an user ahs
[10:44] <pitti> has, even
[10:44] <mjg59> Or just using ACLs
[10:44] <pitti> mjg59: sure, but who configures that?
[10:44] <mjg59> pitti: The admin
[10:45] <pitti> dpkg-statoverride? well, that would work
[10:45] <mjg59> I'm sorry, I feel like I must be missing something really obvious here
[10:45] <pitti> but it certainly needs a guy
[10:45] <pitti> gui, even
[10:45] <mdz> mjg59: we have some conflicting goals
[10:45] <mdz> we would like to hide the entries where the user can't possibly make use of them
[10:45] <pitti> our current sudo supports sudo -t command
[10:45] <mdz> but we want to avoid hiding them if the user can use them
[10:45] <pitti> but that generates clutter on desktops
[10:46] <pitti> so we need to test at a higher level
[10:46] <Mithrandir> pitti: can we just get sudo -t to log, but not mail?  I think that would be ok.
[10:46] <mjg59> mdz: But that goal inherently provides information leakage about user capabilities
[10:46] <mdz> we implemented a solution as pitti describes which makes it trivial to query sudo for this information
[10:46] <pitti> Mithrandir: then we don't need mail for sudo without -t either
[10:46] <mdz> mjg59: yes, in my opinion a certain amount of leakage is probably OKO
[10:46] <mdz> OK
[10:46] <pitti> Mithrandir: which would change sudo semantics on servers, too
[10:46] <pitti> Mithrandir: sudo -t command && sudo command 
[10:46] <Mithrandir> pitti: hmm, right.
[10:47] <mjg59> mdz: I worry about changing security expectations from traditional unix
[10:47] <pitti> mjg59: right, the question is how much leakage we want to sacrifice for this hide-admin spec
[10:47] <mdz> pitti: hmm?
[10:47] <ogra> cant you add a switch to sudo for mailing the admin can set ? 
[10:47] <mdz> mjg59: I think sudo is a bit young to have traditional security expectations
[10:47] <ogra> i.e. have it off by default on desktops and on on servers ? 
[10:47] <mdz> and this problem only applies to sudo
[10:47] <pitti> ogra: sure, but I doubt that it would be easier than grepping desktop files
[10:47] <mjg59> mdz: I've seen people using it for years
[10:48] <pitti> ogra: what defines a server then?
[10:48] <\sh> sudo is not young..it wasn't popular...just like the story about telnet and ssh
[10:48] <ogra> pitti, dunno, but we build this system, we can define it ...
[10:48] <mdz> mjg59: I agree with you in that getting to dapper from warty requires fairly extensive command-line familiarity already
[10:48] <pitti> ogra: the problem is, the admin defines the purpose of the install, not we :)
[10:49] <mdz> mjg59: but I think we need to do better than the release notes if we're going to rely on admin membership in this way
[10:49] <ogra> pitti, but we can define flags that get set, based on default options the installing person choose
[10:49] <pitti> ogra: right, that was option 2 in my email to u-d
[10:49] <ogra> or checks
[10:49] <mdz> pitti: do you think we could safely add users to the admin group on upgrades?
[10:49] <mjg59> mdz: Well, it's possible to do that (at the cost of requiring manual intervention during the upgrade)
[10:50] <pitti> mdz: no, I'd not do that
[10:50] <mdz> the entry created in sudoers by the installer is specially marked
[10:50] <pitti> mdz: IF the admin configured fine-grained permissions, then this would lead to privilege escalation
[10:50] <Mithrandir> mdz: we could have an upgrade tool which asked the admin how he wanted stuff done, but I dislike that.
[10:50] <mdz> pitti: I think that can be avoided
[10:50] <pitti> well, I wouldn't have a good feeling with changing group memberships on upgrades, even less so with admin
[10:50] <\sh> mdz: this is somehow not the right solution...better to ask during dist-upgrade "Who is your admin user?"
[10:50] <mdz> pitti: the process would be to check for an entry in sudoers of the form:
[10:50] <Mithrandir> something like a ubuntu-fixup package which asked questions and tried to fix stuff in the postinst.
[10:50] <mdz> # Added by Ubuntu installer
[10:50] <mdz> mdz     ALL=(ALL) ALL
[10:51] <pitti> mdz: we check for a default sudoers and do it only then?
[10:51] <mdz> pitti: a sudoers with the default entry
[10:51] <mdz> pitti: which is equivalent to admin group membership
[10:51] <mdz> i.e., unrestricted sudo to root
[10:51] <pitti> mdz: well, that would cover the warty upgrade, what about the general usage of visudo without admin group?
[10:51] <pitti> i. e. finer grained privs?
[10:51] <mdz> pitti: wouldn't those be superseded by the ALL entry?
[10:52] <mdz> configuring finer-grained privileges would require removing the ALL entry
[10:52] <pitti> mdz: I mean with nonstandard sudoers (when we don't add users to admin)
[10:52] <pitti> not for upgrades
[10:52] <mdz> pitti: I don't understand
[10:52] <pitti> mdz: if I allow joe to use sudo time-admin, but nothing else, then joe would not see time-admin in the menu
[10:52] <pitti> mdz: if we don't care about this case, then group check is sufficient
[10:52] <pitti> if we do, then it's not
[10:52] <mdz> pitti: unless you add joe to the admin group
[10:52] <mjg59> Does dpkg-statoverrides have support for POSIX ACLs?
[10:53] <mdz> mjg59: RUN AWAY
[10:53] <mjg59> mdz: But then he'd see all of them, not just time
[10:53] <mdz> mjg59: that is acceptable to me
[10:53] <pitti> mdz: he would not be in admin, of course, otherwise the 'sudo time-admin' entry would be pointless
[10:53] <mdz> pitti: if the admin wants finer grained permissions, they would remove the %admin entry
[10:53] <pitti> I know that it's a corner case
[10:53] <\sh> pitti: is this the normal use-case for desktop installations?
[10:53] <pitti> but we should clearly say whether or not we support it
[10:54] <pitti> \sh: no
[10:54] <\sh> I think I can remember windows xp asking even unprivilegded users to update windows xp via windows update
[10:54] <mjg59> pitti: It's something that can be supported by the admin removing the read bit from the desktop files, and then adding individual users to an associated ACL
[10:54] <\sh> and the user clicks on the toaster and "u don't have rights"
[10:54] <ogra> \sh, remember we are better than MS
[10:54] <pitti> mjg59: I agree
[10:55] <mjg59> And I think we support ACLs on all our supported filesystems
[10:55] <mdz> mjg59: which ones are our supported filesystems?
[10:55] <ogra> heh
[10:55] <pitti> it's just not something a non-hardcore freak would do
[10:55] <mdz> mjg59: currently, the process for granting admin privileges is trivial: adduser <user> admin, or check the tick box in the GUI tool
[10:55] <\sh> ogra: what I wanted to say with this is: what is the typical use case for a desktop...single machine. and if there is a second or third account most people don't care if they see the admin tools or not...if they get the "sorry, not allowed" message..they don't care anymore
[10:55] <mjg59> mdz: Right, and I'd see that as the default
[10:56] <mdz> ACLs complicate that for both cases (more commands, and complicating the tool)
[10:56] <mdz> mjg59: so you're suggesting that we don't try to hide these entries by default?
[10:56] <mjg59> No, we hide those entries by default
[10:56] <mdz> mjg59: and leave it to the admin only if they really want to configure it that way?
[10:56] <pitti> but isn't our problem exactly the other way round?
[10:56] <mdz> pitti: yes
[10:56] <mjg59> In the corner case of an admin wanting a user to be able to run a single application but not all of them, they use the ACL solution
[10:56] <pitti> users who aren't in admin, but have special rights won't see the desktop file
[10:57] <pitti> instead of users without rights see them
[10:57] <mjg59> mdz: ext3, xfs, jfs, reiserfs and nfs support them
[10:57] <mdz> mjg59: the ACL solution being: remove the %admin entry from sudoers, add the more specific entries, and set ACLs on the .desktop files corresponding to the more specific entries?
[10:57] <pitti> ah, I see, we make the desktop files root:admin 640 by default?
[10:57] <mjg59> mdz: Correct
[10:57] <mjg59> pitti: Yeah, that would work
[10:58] <mdz> mjg59: I think dpkg probably clobbers ACLs on upgrades
[10:58] <mjg59> mdz: Well, that's a feature request for dpkg :)
[10:58] <ogra> and i dont think we need even to think about this special cornercase ...
[10:58] <ogra> switch all on or all off ...
[10:58] <pitti> "Dear Keybuk, please teach dpkg-statoverride ACLs, kthxbye"?
[10:59] <mdz> pitti: I have an idea
[10:59] <pitti> give us the ultimate solution, Matt! :)
[10:59] <mdz> pitti: we could allow users to query sudo without any logging or warning if they are in the admin group
[10:59] <\sh> hmmm....
[10:59] <mdz> pitti: and otherwise, fall back to displaying all of the menu entries
[10:59] <pitti> mdz: that's what happen right now
[10:59] <pitti> oh, wait
[11:00] <ogra> isnt that backwards ? 
[11:00] <pitti> well, if they are in admin, then we already know everything
[11:00] <mdz> IFF they are in the admin group
[11:00] <pitti> we want to know information if they aren't
[11:00] <ogra> exactly
[11:00] <mdz> if they aren't, we just display everything
[11:00] <ogra> but we dont want this
[11:00] <mjg59> mdz: Uhm. No, surely?
[11:00] <pitti> well, then we don't need to do anything :)
[11:00] <mdz> I'm not particularly interested in having finer-grained menu entries corresponding to finer-grained sudoers
[11:00] <mdz> I just don't want the functionality to disappear from the desktop undesirably
[11:00] <pitti> becaue that would mean to always show everything :)
[11:00] <mjg59> mdz: If they're not in the admin group, we don't want to display anything
[11:01] <mdz> mjg59: you are introducing facts into the discussion
[11:01] <ogra> lol
[11:01] <\sh> I wonder if it's possible to create a patch which is doing the query if a user is in admin group or not inside of the menu display 
[11:01] <mjg59> Simplest solution:
[11:01] <mjg59> 1) Make .desktop files 640 and group admin owned 
[11:01] <pitti> \sh: that's easy, yes
[11:02] <mjg59> 2) Transition default user to admin group for warty upgrades
[11:02] <mjg59> Result: Most use cases sorted
[11:02] <mdz> mjg59: 2) is scary
[11:02] <pitti> I have a bad feeling about 2)
[11:02] <ogra> mjg59, how do we know its a warty upgrade ? 
[11:02] <\sh> pitti: and the gnome-menu reads the desktop file, right?
[11:02] <pitti> but I like 1)
[11:02] <mjg59> We're talking about users who, in sudoers, have ALL=(ALL), right?
[11:02] <pitti> \sh: right
[11:02] <mdz> mjg59: we don't have a persistent record of who the default user is and whether it's been customized
[11:02] <mjg59> So they could add themselves to the admin group *anyway*
[11:02] <pitti> right
[11:03] <ogra> mjg59, yes, but i might have set this in a brandnew breezy because i think its cool
[11:03] <mdz> mjg59: it seems probable that there are corner cases
[11:03] <ogra> so we would break hat
[11:03] <ogra> that*
[11:03] <pitti> I'm not questioning that, but we have to make damn sure that we get that right
[11:03] <mdz> what happens when you have multiple matching entries in sudoers for a user?
[11:03] <mjg59> mdz: If they have a fine-grained setup, we do nothing
[11:04] <\sh> pitti: so..when we set a special "X-Admin: true/false" inside of the admin apps and checking in gnome-menu if or if not the user a) is in admin group or not and b) if the app which is described in .desktop is admin tool or not..and then display or not display it
[11:04] <mdz> mjg59: meaning what?  we don't touch it unless it hasn't been modified since installation?
[11:04] <pitti> \sh: see the spec, yes
[11:04] <mdz> mjg59: I'm saying that I think sudoers semantics may allow a finer-grained setup without removing the default entry
[11:04] <mjg59> mdz: I think we can justifiably add any user who has privileges to run anything to the admin group
[11:05] <pitti> mjg59: your chmod solution has the added benefit that we don't actually need to add that X-Requires-Root: true key :)
[11:05] <Mithrandir> mjg59: that's not problematic, I think giving the admin group root-equivalent priviledges might be more problematic.
[11:05] <\sh> ogra: you can read my mind?
[11:05] <mdz> mjg59: I'm saying that that situation is difficult to detect reliably; it may not be as simple as looking for the expected line in sudoers
[11:05] <mdz> mjg59: and the risks of being too liberal are pretty severe
[11:05] <ogra> its a task for gnome-menus as it was thought out in the beginning imho
[11:05] <pitti> ogra: how do you want to determine if user foo can execute sudo command?
[11:06] <ogra> pitti, if i check his groups
[11:06] <pitti> mdz: if we go for group checking, then I'd prefer a release note
[11:06] <\sh> pitti: sudo should be excuted by anyone...the app to run afterwards is determined by sudoers...we still have the cli 
[11:06] <mdz> pitti: I fear that we will be flooded by reports of users upgrading and then being locked out
[11:06] <pitti> not doing a relative simple .desktop parsing for security reasons, and then add a highly delicate sudoers rewriting doesn't fit together
[11:06] <ogra> i wouldnt touch sudo at all ...
[11:07] <mdz> pitti: we don't know how many breezy systems are out there which are upgrades from hoary and warty
[11:07] <mjg59> The current options have at least one of the following problems:
[11:07] <mjg59> a) Increase information leakage
[11:07] <pitti> ogra: well, but see backlog, not every sudoer is in admin group
[11:07] <mjg59> b) Increase code run as root
[11:07] <mjg59> c) Are awkward for upgrades
[11:07] <mdz> we've already increased the information leakage
[11:07] <mjg59> mdz: How?
[11:07] <ogra> pitti, corner cases ...
[11:07] <pitti> with the admin group
[11:08] <mdz> mjg59: sudo -t no longer asks for a password
[11:08] <mjg59> mdz: I think that's a bug
[11:08] <mdz> mjg59: it just bitches in the log
[11:08] <\sh> pitti: but during a dist-upgrade from warthy, hoary, breezy to dapper, we could ask questions...and we can "rearrange /etc/sudoers"
[11:08] <pitti> mdz: how is that information disclosure?
[11:08] <mdz> pitti: for the same reasons we've been discussing all along
[11:09] <ogra> why not focus on the group and make a note in the release notes ... to warty systems it simply wont make a difference ...
[11:09] <pitti> mdz: I don't understand why sudo -t command without a password discloses information
[11:09] <mdz> pitti: it allows the user (or an attacker with their privileges) to query sudo
[11:09] <pitti> mdz: right, but not unnoticed
[11:09] <mjg59> mdz: Unless the default behaviour of sudo -t failing is identical to the default behaviour of attempting to execute a command without privileges (in terms of admin notification), I think that's incorrect
[11:09] <mdz> pitti: the information is still leaked, we just record the fact that it was leaked
[11:10] <mjg59> When was this -t behaviour changed?
[11:10] <mdz> dapper
[11:10] <mjg59> Right. So we can revert it.
[11:10] <mjg59> mdz: It's the sort of thing that will get mentioned on bugtraq
[11:10] <mdz> if we can't do this without unacceptable tradeoffs in robustness or security, we should consider not doing it
[11:10] <mdz> mjg59: I do not fear bugtraq
[11:10] <pitti> mdz: right
[11:11] <mjg59> mdz: I don't fear bugtraq. I fear negative PR associated with "Ubuntu change security tool default behaviour to one that leaks more information"
[11:11] <mdz> I believe it was also mentioned on bugtraq that we grant sudo privileges rather than using a root password
[11:11] <amu> moin
[11:11] <mdz> the world moved on
[11:11] <ajmitch_> hi amu
[11:11] <ogra> hey amu
[11:12] <pitti> ok, then let's ignore the custom sudoers case and just check for admin membership
[11:12] <ogra> yeah
[11:12] <mdz> pitti: that leaves us back to dealing with warty upgrades
[11:12] <pitti> the workaround is really evil, but it seems that sudo solution is evil, too
[11:12] <ogra> for warty upgraded systems the menu will just go on looking like before ...
[11:12] <mjg59> mdz: If sudo -t continues to log, then that's going to be a *lot* of log entries for terminal server-type installs
[11:12] <mdz> and hoary, in fact, no? didn't we change to group admin in breezy?
[11:12] <mjg59> And if it doesn't log, it's a security pain
[11:12] <ogra> i dont think thats bad
[11:12] <mjg59> I /think/ hoary had an admin gorup
[11:12] <pitti> mjg59: it should log
[11:13] <mdz> mjg59: it's unacceptable to use sudo for this if it logs
[11:13] <pitti> mjg59: hoary had
[11:13] <mdz> mjg59: but you've said that you find it unacceptable to use sudo for this at all, already
[11:13] <mdz> because we can't use sudo for the query unless we allow it to be queried without a password
[11:13] <mjg59> mdz: I think it's bad to use sudo in a way that leaks information. I think it's /terrible/ to use sudo in a way that doesn't log if an unauthorised user runs it.
[11:14] <mdz> I'm all for using the admin group check IFF we can find a  way to fall back gracefully for systems which never had that configuration in the first place
[11:14] <pitti> mjg59: well, with the desktop file test, we would not leak any info on servers
[11:14] <mdz> do we create the admin group on upgrades?  if not, we could check for its existence
[11:15] <ogra> no, we dont
[11:15] <pitti> we would drop -t
[11:15] <pitti> and introduce --check-desktop-file, or so
[11:15] <mjg59> pitti: Uhm.
[11:15] <mjg59> pitti: How does that help?
[11:15] <ogra> why must that be done on sudo pitti ?
[11:15] <ogra> in*
[11:15] <pitti> mjg59: on servers there are no .desktop files, so there is no information leak
[11:15] <mdz> ogra: are you sure?  where is admin created?
[11:15] <mjg59> pitti: That's not a sensible assertion
[11:15] <pitti> ogra: /etc/sudoers is readable only by root
[11:16] <ogra> mdz, from hoary on in the installer afaik
[11:16] <mjg59> pitti: mjg59@kern:~/ > locate .desktop | grep /usr | wc 353     353   16080
[11:16] <ogra> pitti, we have the info in the .desktop files, we can make gnome-menus check the group
[11:16] <mjg59> mjg59@kern:~/ > wc /etc/passwd
[11:16] <mjg59>   3576   8484 220748 /etc/passwd
[11:16] <ogra> no need to touch sudo at all
[11:16] <mjg59> pitti: So, no. Being a server does not mean that people don't run graphical sessions.
[11:17] <pitti> mjg59: well, we would limit the information leak to exactly the information we need  - desktop files
[11:17] <pitti> instead of arbitrary commands
[11:17] <pitti> mjg59: well, if people use sudo under X, then we don't need to worry about information leaks
[11:17] <mjg59> pitti: But the user then (effectively) knows that they can execute whatever is in that .desktop file
[11:17] <mdz> ogra: I can't find where it's created
[11:17] <pitti> mjg59: exactly
[11:17] <pitti> that's the amount of sacrifice we need to do IF we want this
[11:17] <ogra> mdz, i only know that its there since hoary ... for all new installs i did
[11:18] <mjg59> pitti: Right. So I think it's a stupid idea in that form.
[11:18] <ogra> mdz, and its not there on upgraded systems
[11:18] <pitti> mjg59: it's better than sudo -t command IMHO
[11:18] <mjg59> pitti: Being stabbed in the hand is better than being stabbed in the eye :)
[11:18] <sistpoty> why not check in /etc/group as heuristic instead of the sudoer-file?
[11:18] <pitti> *shrug*
[11:18] <mdz> pitti: how about my suggestion?
[11:19] <pitti> mdz: the one with not doing anything at all?
[11:19] <mdz> pitti: if the admin group exists, use it to test whether to display the menu entries.  if it doesn't exist, display them all.
[11:19] <pitti> mdz: that's what we have now
[11:19] <ogra> mdz++
[11:19] <mjg59> That works for me.
[11:19] <pitti> oh, ok
[11:19] <mdz> pitti: and revert the sudo change
[11:19] <pitti> mdz: would work for me
[11:19] <ogra> the behavior for upgraded warts just wont change ...
[11:19] <mdz> I thought we created admin on upgrades, but ogra pointed out that this isn't true
[11:19] <mdz> so this is a very simple solution
[11:19] <pitti> for warty upgrades that's certainly fine
[11:20] <pitti> people are used to the menus by now, probably
[11:20] <mdz> ok, I think we've licked it
[11:21] <ogra> so keep the change at gui level ? 
[11:21] <mdz> that only took an hour
[11:21] <pitti> mdz: that would mean to break the case when admin group is not actually used, but that's probably a small enough corner case
[11:21] <ogra> together with the checks etc 
[11:21] <mdz> pitti: I'm satisfied with that
[11:21] <pitti> it's certainly fine for me
[11:21] <mdz> ok
[11:22] <mdz> DONE
[11:22] <pitti> but I think it was important enough to talk about it
[11:22] <mdz> DOIT
[11:22] <ogra> phew
[11:22] <pitti> 'k :)
[11:22] <mdz> any other business?
[11:22] <pitti> sleeeep
[11:22] <mdz> I would like to talk about scheduling meeting times
[11:22] <mdz> but we should do that when we have everyone here
[11:22] <mdz> I'll just send email to TB about it
[11:22] <pitti> at the beginning of next TB?
[11:22] <mjg59> Cool
[11:22] <\sh> ogra: grmpf...
[11:23] <mdz> workrave HATES ME
[11:23] <ogra> hit it
[11:23] <\sh> mdz: kill -9 ?
[11:23] <mdz> meeting adjourned
[11:23] <pitti> mdz: it is wonderfully silent if I just keep cklicking on 'skip' :)
[11:23] <mdz> thanks, everyone
[11:23] <pitti> thanks, guys
[11:23] <mjg59> Night
[11:23] <ogra> thanks mdz
[11:23] <\sh> thx mdz
[11:23] <mvo> night
[11:24] <ogra> night mvo 
[11:24] <zakame> night mvo 
[11:24] <mvo> night ogra, zakame 
[11:27] <\sh> ogra: pingeling...ubuntu-de-messe please...amu wants to come with us :)
[11:27] <ogra> YAY !!!
[11:28] <ogra> i have a vey dirty car and wont have the time to clean it before ... so you have to live with that :)