/srv/irclogs.ubuntu.com/2005/12/04/#ubuntu-meeting.txt

=== kjcole [n=kjcole@pchb1f.gallaudet.edu] has joined #ubuntu-meeting
=== MarioMeyer [n=meyer@ubuntu/member/mariomeyer] has joined #ubuntu-meeting
=== ajmitch__ [n=ajmitch@203.89.167.142] has joined #ubuntu-meeting
=== FLeiXiuS [n=fleixius@pcp0010489211pcs.essex01.md.comcast.net] has joined #ubuntu-meeting
=== hunger_ [n=hunger@p54A630BB.dip0.t-ipconnect.de] has joined #ubuntu-meeting
=== ogra [n=ogra@ubuntu/member/ogra] has joined #ubuntu-meeting
=== uniq_ [n=frode@213.184.199.55] has joined #ubuntu-meeting
=== uniq [n=frode@213.184.199.55] has joined #ubuntu-meeting
=== MarioMeyer_ [n=meyer@ubuntu/member/mariomeyer] has joined #ubuntu-meeting
=== bmonty [n=bmontgom@wsip-68-15-230-31.om.om.cox.net] has joined #ubuntu-meeting
=== mgalvin [n=mgalvin@cpe-69-205-47-165.nycap.res.rr.com] has joined #ubuntu-meeting
=== MarioMeyer_ is now known as MarioMeyer
=== SloMoSnail [n=slomo@p5487FA98.dip.t-dialin.net] has joined #ubuntu-meeting
=== bmonty [n=bmontgom@wsip-68-15-230-31.om.om.cox.net] has joined #ubuntu-meeting
=== ajmitch [i=ajmitch@203.89.178.198] has joined #ubuntu-meeting
=== ajmitch_ [n=ajmitch@port162-85.ubs.maxnet.co.nz] has joined #ubuntu-meeting
=== robitaille [n=robitail@ubuntu/member/robitaille] has joined #ubuntu-meeting
=== highvoltage [n=Jono@196.36.161.235] has joined #ubuntu-meeting
=== crimsun [i=crimsun@pdpc/supporter/silver/crimsun] has joined #ubuntu-meeting
=== crimsun [i=crimsun@pdpc/supporter/silver/crimsun] has left #ubuntu-meeting []
=== dholbach [n=daniel@i577B0C37.versanet.de] has joined #ubuntu-meeting
=== robitaille [n=robitail@ubuntu/member/robitaille] has joined #ubuntu-meeting
=== ..[topic/#ubuntu-meeting:robitaille] : Agendas: http://wiki.ubuntu.com/MeetingAgendas | Calendar: http://fridge.ubuntu.com/event | Logs: http://people.ubuntu.com/~fabbione/irclogs/ | 30 Nov 12:00 UTC: Edubuntu | 01 Dec 20:00 UTC: Dapper Development Status | 02 Dec 22:00 UTC: DocTeam | 06 Dec 14:00 UTC: Community Council | 16 Dec 16:00 UTC: Desktop team
=== phlaegel_ [n=phlaegel@atdot.ca] has joined #ubuntu-meeting
=== ..[topic/#ubuntu-meeting:robitaille] : Agendas: http://wiki.ubuntu.com/MeetingAgendas | Calendar: http://fridge.ubuntu.com/event | Logs: http://people.ubuntu.com/~fabbione/irclogs/ | 30 Nov 12:00 UTC: Edubuntu | 01 Dec 20:00 UTC: Dapper Development Status | 02 Dec 22:00 UTC: DocTeam | 06 Dec 14:00 UTC: Community Council | 07 Dec 14:30 UTC: Accessibility Team | 16 Dec 16:00 UTC: Desktop team
=== hunger_ [n=hunger@p54A60A06.dip0.t-ipconnect.de] has joined #ubuntu-meeting
=== highvoltage [n=Jono@196.36.161.235] has joined #ubuntu-meeting
=== ..[topic/#ubuntu-meeting:robitaille] : Agendas: http://wiki.ubuntu.com/MeetingAgendas | Calendar: http://fridge.ubuntu.com/event | Logs: http://people.ubuntu.com/~fabbione/irclogs/ | 29 Nov 20:00 UTC: Technical Board | 30 Nov 12:00 UTC: Edubuntu | 01 Dec 20:00 UTC: Dapper Development Status | 02 Dec 22:00 UTC: DocTeam | 06 Dec 14:00 UTC: Community Council | 07 Dec 14:30 UTC: Accessibility Team | 16 Dec 16:00 UTC: Desktop team
=== mvo [n=egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting
=== hunger_ [n=hunger@p54A6412B.dip0.t-ipconnect.de] has joined #ubuntu-meeting
=== Simira [n=rpGirl@214.84-48-74.nextgentel.com] has joined #ubuntu-meeting
=== ogra [n=ogra@ubuntu/member/ogra] has joined #ubuntu-meeting
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-meeting
=== ogra [n=ogra@ubuntu/member/ogra] has joined #ubuntu-meeting
=== MarioMeyer [n=meyer@ubuntu/member/mariomeyer] has joined #ubuntu-meeting
=== lamont [n=lamont@mib.fc.hp.com] has joined #ubuntu-meeting
=== mgalvin [n=mgalvin@host-66-202-95-170.spr.choiceone.net] has joined #ubuntu-meeting
=== kjcole [n=kjcole@pchb1f.gallaudet.edu] has joined #ubuntu-meeting
=== ogra [n=ogra@ubuntu/member/ogra] has joined #ubuntu-meeting
=== ogra [n=ogra@ubuntu/member/ogra] has joined #ubuntu-meeting
=== hunger__ [n=hunger@p54A63476.dip0.t-ipconnect.de] has joined #ubuntu-meeting
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-meeting
=== Yogarine [n=Yogarine@200165085137.user.veloxzone.com.br] has joined #ubuntu-meeting
=== jane_ [n=JaneW@wbs-146-174-135.telkomadsl.co.za] has joined #ubuntu-meeting
=== Yogarine [n=Yogarine@200165085137.user.veloxzone.com.br] has left #ubuntu-meeting []
=== Hirion [n=Hirion@p5487FA98.dip.t-dialin.net] has joined #ubuntu-meeting
=== jane_ [n=JaneW@wbs-146-174-135.telkomadsl.co.za] has joined #ubuntu-meeting
=== kjcole [n=kjcole@pchb1f.gallaudet.edu] has joined #ubuntu-meeting
=== ajmitch_1 [n=ajmitch@port169-199.ubs.maxnet.net.nz] has joined #ubuntu-meeting
=== sistpoty [n=sistpoty@ubuntu/member/sistpoty] has joined #ubuntu-meeting
=== minghua [n=minghua@danube.mems.rice.edu] has joined #ubuntu-meeting
=== abelcheung [n=abelcheu@221.126.147.177] has joined #ubuntu-meeting
=== seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-meeting
=== pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-meeting
pittihi08:58
seb128hey pitti08:58
ogramrning pitti 08:58
pittiseb128: here for the hide-admin-tools issue?08:58
Seveasah, TB meeting08:59
Seveasthat explains activity :)08:59
ograwow, huge agenda :)08:59
seb128pitti: 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 :)08:59
\shjumping from one meeting to another09:00
seb128pitti: because if you speak about hide-admin-tools I'm interested :)09:00
ograedubuntu too :)09:00
dholbachmako wants to become a MOTU09:00
ografinally09:00
ogra*g*09:00
\shWHAT?09:01
ogradholbach, tell him he has to send a $100 laptop to every MOTU first :)09:01
dholbachhttps://launchpad.net/people/ubuntu-dev/+members09:01
dholbachyeah09:01
dholbachthat'd make sense09:01
\shhmm...i never worked with him, I saw him never in #ubuntu-motu..,)09:02
ogradid mdz forget us ? 09:02
mdzno09:02
ogra:)09:02
mdzworkrave waits for no man09:02
ogralol09:02
Seveashehe09:02
mjg59I'm actually here on time, for once09:02
Seveasworkrave is a bitch ;)09:02
mdzKeybuk said he probably wouldn't be able to make it09:02
mdzand I expect the same for sabdfl as he's travelling09:03
ograSeveas, obviously self chosen09:03
mdzI think we can call this a quorum though09:04
mdzthere is one candidate for the core development team, Sebastian Drge09:04
mjg59Shall we get on with things, then?09:04
mdzis that slomo?09:04
dholbachslomo, are you there?09:04
dholbachmdz: yes09:05
mdzlaunchpad says yes09:05
ograyup, thats slomo 09:05
=== janimo [n=jani@Home03207.cluj.astral.ro] has joined #ubuntu-meeting
=== slomo_ [n=slomo@ubuntu/member/slomo] has joined #ubuntu-meeting
mdzslomo_: hello09:05
mdzwe were just looking for you09:05
slomo_hi everybody, hi mdz :)09:05
slomo_mdz: yes, ogra told me... sorry09:06
mdzslomo_: 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/weeks09:07
mdzslomo_: who are your sponsors?09:08
slomo_mdz: dajobe, ajmitch and lool09:08
mdzare any of them present?09:08
mdzmaybe ajmitch, I'd like to hear from him09:09
sistpotyajmitch said he'd be on his way to work 10mins ago09:09
slomo_he left only some minutes ago afaik :/ and the others are not present09:09
mjg59slomo_: 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:09
mdzslomo_: 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 them09:10
mjg59slomo_: Ok, cool09: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 useful09:11
ogramdz, we could drop xine on him ;)09:11
ograslomo does a lot with multimedia packages09:11
=== Burgwork [n=corey@S010600131016cf6f.gv.shawcable.net] has joined #ubuntu-meeting
\shslomo is a tough guy for the hard nuts ... MOTU owe him a few 09:12
mdzslomo_: which packages, and what sort of work?09:12
ajmitch_morning09:13
slomo_mdz: for mono? the complete mono stack from ground up... i.e. cli-common, mono, gtk#, monodoc, etc09:13
=== ajmitch_ didn't realise there was a TB meeting today, sorry :)
=== Keybuk [n=scott@descent.netsplit.com] has joined #ubuntu-meeting
ograKeybuk!!09:15
mdzslomo_: what would you like to change about those packages presently?09:15
mdzKeybuk: (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 dapper09:16
ajmitch_mdz: what would you like to ask about the sponsored packages or other work?09:17
mdzslomo_: what is needed in order to get everything working well together?09:17
mdzajmitch_: yes, feel free09:17
ajmitch_ok, slomo has done most of the mono work for dapper that was required for merging debian changes09:18
=== vincent_ [n=vincent@85.69.101.91] has joined #ubuntu-meeting
ajmitch_he's worked well with the debian mono team to get issues sorted out09:18
ajmitch_and the packages I've had time to sponsor have been very clean, with few things to fix up or clarify09:19
ajmitch_I'd like to see him able to upload the mono stuff directly to main, especially as we get more of it in09:19
mdzajmitch_: thanks09:20
seb128mdz: 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 too09:20
seb128s/seems//09:20
mdzseb128: that's great ,thanks09:20
seb128s/seems to be/do/09:20
ograand slomo mainly maintains mplayer nowadays09:20
ograand ffmpeg etc ...09:21
mdzslomo_: 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 too09:21
mdzslomo_: what can we do to make that situation better?09:21
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 meeting09:22
mdzslomo_: if you would prefer to wait until the next meeting, that's no problem09:22
slomo_mdz: mostly work with upstream to get everything in a stable state09:22
mdzslomo_: I'm looking for specific and concrete actions that you would like to take in main, as examples of what we could expect from you09:23
ajmitch_upstream being debian or real upstream of the programs that break?09:23
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 there09:24
mdzslomo_: how would this relate to the work that tseng is currently doing on mono?09:25
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 time09:26
slomo_ajmitch_: both09: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 out09:27
mdzslomo_: have you seen https://launchpad.net/distros/ubuntu/+spec/video-playback ?09:28
mdzI would like to hear your ideas about how we could provide the best unencumbered video playback capability in the default install09:28
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 afaik09:29
seb128slomo_: are you interested by splitting xine for this? :)09:30
mjg59slomo_: 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 later09:31
mdzslomo_: he's talking about the video-playback spec I referred to earlier09:31
mdzslomo_: 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
seb128slomo_: 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 spec09:32
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 box09:33
mjg59slomo_: 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 yet09:33
slomo_seb128: sure, i could try splitting it that way09:34
seb128would be nice :)09:34
seb128thanks!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:34
mjg59slomo_: At the moment, I think we're integrating the technical side of multimedia into the distribution fairly well, but the social side is less clear09:35
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 box09:36
mjg59It would be good to think about ways we can improve that in the distribution, rather than just referring people to the wiki09:37
Burgworktotem/rb needs to be able to tell people what specific codec they need09:37
mjg59The totem user experience in Ubuntu is currently fairly dire09:37
mdzslomo_: 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:37
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 fix09:38
slomo_mjg59: yes, i know nobody who uses totem atm because it's too unstable for them :( that needs to be improved somehow09:38
mdzI use totem and have not found it unstable09:39
Burgworkslomo, is that something we can push on to the laptop testing team? They already have the hardware09:40
=== gauss [n=enrico@gailleton-2-82-67-8-40.fbx.proxad.net] has joined #ubuntu-meeting
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 now09:40
slomo_mdz: it's mostly the applet or when playing wmv/quicktime... for "normal" formats it works well... normal beeing xvid, theora, vorbis, etc09:41
mdzslomo_: what do you think we could do to better test multimedia support as you propose?09:42
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 regularly09:44
=== doko_ [n=doko@dslb-084-059-099-238.pools.arcor-ip.net] has joined #ubuntu-meeting
ograslomo_, volunteering to make a testplan ? ;)09:45
dholbachogra: add it to: https://wiki.ubuntu.com/TestPlans :)09:45
ograhehe09:45
ogradholbach, 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 it09:46
ograajmitch_, i'm the evil recruiter, but not *that* evil :)09:47
mdzslomo_: what I would suggest is to extend https://launchpad.net/distros/ubuntu/+spec/test-plans to include a simple multimedia test in the test plan09:47
ajmitch_ogra: go on, take the next step ;)09:47
mdzslomo_: perhaps you could work with dholbach on this09:47
dholbachi'm happy to09:47
slomo_mdz: sure... sounds good :)09:48
mdzslomo_: 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 that09:48
mdzmjg59: do you have any further questions you'd like to ask?09:48
mdzif not, I'm ready to call a vote09:48
mjg59I think I'm done09:49
mdzok, votes?09:50
ogra+1 (if i could)09:50
mdzogra: please leave the voting to the board09:50
mjg59I think +1, based on the discussion of a testing regime and thinking about improving the entire user experience09:51
mdz+1 from me based on positive feedback from the development team and the potential for solid contributions to main09:51
=== dholbach hugs slomo
mdzslomo_: congratulations, thanks and welcome09:52
=== ogra applauds
=== slomo_ hugs dholbach :)
ajmitch_well done slomo_ 09:52
slomo_thanks everybody :)09:52
dholbachEXCELLENT09:52
=== pitti ^5 slomo, welcome to the main team!
seb128slomo_: congrats09:52
=== \sh hugs slomo and congrats him :)
seb128slomo_: I'll ping you for gst0.10 so :)09:52
\shI 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 votes09:52
dholbachslomo_: now if i might invite you to #ubuntu-desktop, we have some things to discuss ... :-p (seb: we have him)09:52
mdzbut today we have only 2/4 present and 2/2 votes09:53
\shmdz: oh ok :)09:53
sistpotycongrats slomo09:53
\shdholbach: don't take him away from the motu...09:53
mdzjanimo: 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
janimomdz, no hurry, as long as xfce is still in universe09:53
janimonext time is fine09:53
mdzjanimo: since we've been here an hour already and have more agenda already, if you don't mind waiting, I think that would be better09:54
janimook, np09:54
mdzwe seem to have 3 new MOTU candidates since the last meeting09:54
dholbachmako :)09:55
mdzzakame doesn't seem to be here09:55
mdzmako: ping09:55
mdzbojan doesn't seem to be here09:55
ajmitch_sadly, since zakame has been doing a fair bit of work lately with merges09:55
\shhmmm...09:55
mdzmjg59: I'm comfortable considering mako in absentia if you are, since we know him quite well already09:55
dholbachwhat happened to bmonty?09:56
\shbmonty can't be here again.....but I would like to propose a vote in absentia 09:56
mjg59Yup09:56
\shbecause 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 Ubuntu09:56
mjg59+1 for mako, too09:56
mdzdone and done09:57
ajmitch_that was a quick appointment :)09:57
\shmako: do some merges asap :) 09:57
Seveaswow, fastest ever I guess :)09:57
ograyes, 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 merges09:57
=== tseng [n=tseng@li2-186.members.linode.com] has joined #ubuntu-meeting
mdzmako has been contributing to Ubuntu since its inception and has only now decided to apply officially ;-)09:58
\shdholbach: yes .. I did some uploads for him the last days...and I'm impressed09:58
ograand prepares uploads all the time for us ... its a bit sad09:58
sistpotyyes... the few packages of bmonty i came to look over showed good packageing skills. and he did _lots_ of work09: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 stuff09:59
sistpotyand he interacts with debian (files bug w. patches in BTS for stuff he changes)10:00
mdzis he mostly doing trivial merges from MOM or more in-depth merging as well?10:00
\shmdz: both10:01
mdzok10:02
\shmdz: most of universe is trivial only one out of 50 is really non trivial10:02
\sh(forgetting the gstreamer universe packages of slomo)10:02
mdzmjg59: any questions regarding bmonty?10:03
=== sistpoty counts 24 dapper changes mails from bmonty
\shsistpoty: and some syncs he couldn't request10:03
mjg59mdz: Don't think so - motu reports sound good10:03
mdzyes, while he isn't present there are several people here willing to provide testimonials10:04
\shsistpoty: and not all of his reports are uploaded actually10:04
mdzvotes?10:04
ograhe was really patient with being postponed from meeting to meeting ...10:04
mjg59+1 from me10:04
mdz+1 from me based on testimonials from several regular MOTU contributors and reviewers, both at this meeting and previous ones10:04
dholbachcool :)10:04
ajmitch_we'll inform him of the good news then10:04
mdzdholbach: 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 meeting10:04
ograwelcome bmonty in absentia !10:04
dholbachmdz: i will10:05
\shmjg59 / mdz: thanks :)10:05
mdzdholbach: thanks, send my congratulations10:05
dholbachmdz: as personally, as internet lets me :)10:05
\shdholbach: blog it :)10:05
dholbachwe don't have a MOTUPhoneNumber page yet :)10:05
\shdholbach: I know he is reading the planet :)10:05
\sh+49 700 sourcecode? ,-)10:05
mdzthere are 18 pending applications in launchpad right now10:05
SeveasDial M for MOTU ;)10:05
\shor should I get +49 700 motu ?10:06
mdzogra,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 list10:06
ogramdz, 90% of them i've never heard of10:06
dholbachmdz: i know 3 of those missing ones10:06
ograor seen them on irc10:06
dholbachmdz: that's sivang, vuntz and zakame10:06
mdzif you've never heard of them, they should receive a form letter explaining how the process works10:06
pittibtw, what about cleaning up members which are inactive? like astaroth?10:06
ogramost of them dont even have a wikipage10:07
dholbachmdz: i will take care of that10:07
mdzdholbach: thank you very much10:07
dholbachde rien10:07
ajmitch_pitti: I think maintainership was meant to have a year or 2 year term, right?10:07
pittiajmitch_: ah, ok10:07
mdzpitti: what is astaroth's real name?10:07
pittimdz: Gerardo di Giacomo10:07
pittimdz: the guy who helped with universe security updates until he became a MOTU10:08
pittiit's by no way urgent to remove him, this example just came into my mind10:08
mdzpitti: please ping him and see if he intends to contribute in the future10:08
pittiyes, will do10:08
dholbachsame for some other folks10:08
mdzpitti: we should not generally deactivate anyone simply because they go inactive; we have the expiration process for that10:08
=== zakame [n=zak@ubuntu/member/zakame] has joined #ubuntu-meeting
zakamehi all10:09
ajmitch_hi zakame 10:09
\shdholbach: 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 it10: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 launchpad10:09
mdz\sh: and if they don't respond, they will eventually expire10:10
\shmdz: ok..so the expiration process is already working :)10:10
mdzzakame: just in time10:10
zakamemdz: thank you :)10:10
ajmitch_mdz: will we have to undergo another interrogation around expiry time? :)10:11
mdzdholbach: you mentioned that you had some experience working with zakame?10:11
mdzajmitch_: we have some time to finalize that part of the process ;-)10:12
ograzakame, nice wikipage :)10:12
zakameogra: many thanks :)10:12
dholbachmdz: 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 well10:12
dholbachmdz: i have 217 bug mails from him, mostly merges, some bug triaging work as well10:13
zakamejust a couple for c2a i think... libcommoncpp2 was already done in debian, and my most recent one was for MAS10:13
dholbachi'm not too familiar with his work, but what he said in #ubuntu-motu usually was sound10:14
ograzakame, you dont mention that you help in edubuntu too on your wiki ....10:15
sistpotythough I haven't reviewed much of his work, I'm impressed by zakame's amount of work... 10:15
\shoh yes..zakame is just hard working like bmonty or ajmitch, slomo, siretart, sistpoty or my person.10:15
mdzzakame: 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
\shI 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 team10:15
zakamemdz: hm, you're right, this seems to just update aclocal.m4, and yes, S-V :(  my bad!10:17
\shmdz: beginners luck I would name it...because I'm the one who has "beginners luck" all the time...;)10:17
zakameogra: Ooh!  I forgot that part!  very sorry!!!10:18
ogramdz, zakame expressed interest to help in edubuntu ... 10:18
mdzzakame: please be careful with that in the future; each package which is diverged creates more work for the team10:18
ograzakame, was it doc or dev ? 10:19
zakamemdz: yes, I'll keep that in mind10:19
mdzzakame: who sponsors your uploads to Ubuntu usually?10:21
zakameogra: 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 afternoon10:23
ogracool10:23
\shmdz: nafallo and I10:24
zakamemdz: Nafallo_away did most of the sponsoring, though most recently \sh sponsored logilab-common and another...10:24
\shzakame: 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 malone10:25
mdzmjg59: anything else before voting?10:25
mjg59Don't tihnk so10:25
zakame\sh: thanks again :) most of them are PendingSync10:25
mdzlikewise10:25
mdz+1 based on my own examination of various uploads, testimonials from MOTU and discussion10:26
\shzakame: if you can provide me a list of malone numbers :) that would be great :)10:26
mjg59+1 based on the MOTU opinions10:26
ogra\sh, see wikipage :)10:26
mdzzakame: welcome aboard10:26
=== dholbach hugs zakame
dholbachthat's brilliant news :)10:26
sistpotycongrats zakame10:26
ograyay, welcome zakame 10:26
minghuazakame: congratulations. :-)10:26
\shzakame: welcome aboard :) good shot :)10:26
slomo_zakame: congrats :)10:26
mdzpitti: you wanted to discuss something regarding sudo?10:27
pittiright10:27
ajmitch_zakame: well done10:27
zakameyay!10:27
=== zakame hugs everybody :D
pittihttp://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013260.html10:27
pitti^ for reference10:27
zakamemany thanks all! :)10:27
pittithere was not much fruitful discussion10:27
mdzright, this thread is long and I haven't had a chance to read it yet10:27
pittithe problem is in short:10:27
pittiinitially we wanted to use sudo -t command to check whether an user can execute command10:28
\shzakame: cool page :) I'll work with the information from this page 10:28
zakame\sh: thanks10:28
pittiif that would log auth failures, then it would remain compatible with default sudo behaviour on servers and not circumvent security checks10:28
mdzpitti: I think extending sudo to parse the .desktop file adds undesirable complexity to a setuid root program10:28
pittimdz: I only see two options TBH: parse .desktop files in sudo or fall back to the broken group check10:29
pittimdz: parsing .desktop files would nicely solve the desktop/server conflict10:29
pittion servers there won't be .desktop files, so that sudo checks are not impeded10:29
pittiand on desktops we would avoid the log clutter from failed checks10:29
mdzpitti: it would certainly be nice to avoid execing sudo so many times during every login10:30
pittimdz: well, we need to execute it once for every desktop file that wants root10:30
mjg59pitti: The sudo -t case would presumably also result in error mails every time someone logs in?10:30
pittii. e. maybe 15 times for a normal system per login10:30
ograhow would that cope with the gnome speeup plans ? 10:30
ogra*speedup10:30
pittimjg59: right, that's the most annoying thing right now10:30
mjg59Why are we trying to achieve this?10:31
mdzmjg59: in order to simplify the menus for unprivileged users10:31
pittimjg59: we want to hide admin tools from the menu for users who aren't admins10:31
mdzi.e., don't show them administrative tools requiring sudo if they won't be able to use them10:31
pittihttps://wiki.ubuntu.com/HideAdminToolsToUsers10:31
mjg59Surely a common use case is that an admin will wish to debug things while a user is logged in?10:31
mdzmjg59: the menu items have no chance of working unless the user has sudo rights10:31
Mithrandirpitti: 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
mjg59Hrm. True.10:31
pittimjg59: 'run program as another user'10:31
ograand the worst thing is that they just silently fail10:32
pittiMithrandir: what would that solve?10:32
pittiMithrandir: sudo would still log violations10:32
Mithrandirpitti: it would not put the desktop parsing code in sudo.10:32
pittiMithrandir: and doing the check in sudo is safer than writing a new program from scratch10:32
mjg59ogra: I think the silent failure is a bug in itself, but still...10:32
ograyup10:32
mdzMithrandir: that code would still run as root, though10:32
Mithrandirmdz: yes, but it would be easier to merge from debian that way.10:32
pittiI mean, parsing is not terribly difficult10:33
pittibut of course it must be done carefully10:33
mjg59But surely this inevitably subverts part of sudo's security?10:33
Mithrandirpitti: I just don't see upstream wanting to incorporate that patch, without knowing sudo upstream.10:33
mdzpitti: is there a program which is run whenever a new .desktop file is instaled?10:33
pittimjg59: to the extent that an intruder can check commands mentioned in installed (root owned) desktop files10:33
mdzpitti: 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 file10:33
pittimjg59: but on desktops we can safely forget about logging anyway10:33
mjg59pitti: Which, in a standard ubuntu install, amounts to everything10:34
pittimdz: dpkg install hooks? (SCNR)10:34
mvothere is dh_desktop 10:34
pittimjg59: why everything?10:34
pittimjg59: on a server there won't be any/many desktop files10:34
mjg59pitti: If a user has sudo rights to execute admin tools, they have sudo rights to execute anything10:34
pittiand seriously, whoever runs sudo under X doesn't need to care about the logging10:34
pittimjg59: under X at least (event injection, etc.)10:35
mdzpitti: 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 scrutinized10:35
pittimjg59: but the case I worry about is to not impede server security checks10:35
mjg59To 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 so10:35
mdzpitti: for the common case, any unprivileged user on the system can already check for membership in the admin group10:35
pittimdz: he can silently poke around to check which privileges a cracked user account has10:35
pittimdz: right now, sudo immediately mails out failures to the admin10:36
mjg59Rather than produce a complex solution that provides extra information leakage about what rights a user has10:36
pittimdz: so that the admin can quickly close the user account, etc.10:36
mdzmjg59: if we do that, we need to heuristically add users to the admin group on upgrades10:36
pittimjg59: but that's not just a warty upgrade issue10:36
mjg59mdz: No, we can document it in the release notes10:36
mdzpitti: they can already do that silently with 'groups'10:36
pittisudo 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:36
dholbachsorry, i'll leave now, because i'm dead tired - good night10:37
mjg59pitti: Yes, but it's not the sudo case that we care about really10:37
ograbye dholbach 10:37
mdzmjg59: we don't display the release notes on upgrades yet10:37
zakamebye dholbach :)10:37
pittimjg59: well, the question is if we do...10:37
mjg59What we care about is "should this user see these icons"10:37
pittiI don't see why we should force admins to use the admin group10:37
mjg59pitti: Because it's the existing mechanism for flagging user capabilities10:37
mdzpitti: 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 wedo10:37
pittimdz: not on my server :) I use /etc/suders to directly configure allowed commands for users, not via groups10:38
mjg59In the brave new world of selinux, the obvious thing to do would be to have admin users have an selinux capability10:38
pittimdz: I agree, when the admin group is used, the case is trivial10:38
ajmitch_that brave new world won't be on by default in dapper 10:38
mdzand that is our default configuration for Ubuntu10:38
Mithrandirmjg59: what would we do in the cases of people being allowed to do some things as root, but not all?10:38
ogramdz, not for warty upgraded systems10:39
mjg59Limiting 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 mechanism10:39
mdzogra: that is missing the point10:39
ogramdz, that will be a good bunch of users ....10:39
pittimjg59: but that makes the usage of non-group sudo impossible10:39
janimochecking sudo -t only once and then using a blacklist of apps which are not to be shown? would that not scale?10:39
mjg59pitti: No it doesn't10:39
pittimjg59: since then the users would never see the desktop files10:39
mjg59pitti: The apps can be run from a shell10:40
mdzogra: the only reason not to use sudo for this is that it reveals information10:40
pittimjg59: right, of course10:40
pittiI mean in terms of correct menus10:40
mjg59pitti: They can launch a shell, add themselves to the admin group and then re-login10:40
mdzogra: but that is only the case if the user has extensively customized the system, since our default configuration and tools reveal it already10:40
pittimjg59: erm?10:40
mdzjanimo: what would the blacklist contain?10:41
=== mgalvin [n=mgalvin@host-66-202-95-170.spr.choiceone.net] has joined #ubuntu-meeting
pittimjg59: if I allow an user to run only a particular command as root, he can't10:41
pittijanimo: that doesn't react to changes10:41
janimothe apps which are to be run only as sudo 10:41
mjg59pitti: Are you suggesting that certain users should have access to specific admin tools, but not all?10:41
janimochanges as in introducing new packages?10:41
pittijanimo: we already know this, it's in the desktop files10:41
mjg59pitti: Making icon visibility depend on being in the admin group doesn't mean that the admin group must have full sudo rights10:41
ogramdz, my initail reaction was the same as yours, but Kamion made some valid points i cant remember currently ... sad he isnt here10:41
pittimjg59: why not? I could allow an user to set the time, but nothing else10:41
mjg59pitti: It's an insanely tiny use-case10:42
pittiwell, ok, if we say that we basically ignore /etc/sudoers and jsut support admin group, that's fine for me10:42
mdzmjg59: we don't need to account for it in our defaults, but we should avoid making it impossible if w ecan10:42
pittiI just want to have that decision formally settled10:42
mjg59mdz: It would still be possible by changing the semantics of the admin group on that system10:43
mdzmjg59: how do you mean?10:43
mjg59mdz: Don't give admin users sudo rights10:43
pittimjg59: no, you need several groups then, which we don't suport10:43
pittimjg59: well, we could have a mapping somewhere10:43
mjg59pitti: We don't support it how?10:43
pittigroup -> desktop files10:43
mdzmjg59: hmm10:44
mjg59I mean, you /could/ solve this just by having the desktop files be 640, right?10:44
pittimjg59: i. e. the menu only reflects admin membership, not the actual privileges an user ahs10:44
pittihas, even10:44
mjg59Or just using ACLs10:44
pittimjg59: sure, but who configures that?10:44
mjg59pitti: The admin10:44
pittidpkg-statoverride? well, that would work10:45
mjg59I'm sorry, I feel like I must be missing something really obvious here10:45
pittibut it certainly needs a guy10:45
pittigui, even10:45
mdzmjg59: we have some conflicting goals10:45
mdzwe would like to hide the entries where the user can't possibly make use of them10:45
pittiour current sudo supports sudo -t command10:45
mdzbut we want to avoid hiding them if the user can use them10:45
pittibut that generates clutter on desktops10:45
pittiso we need to test at a higher level10:46
Mithrandirpitti: can we just get sudo -t to log, but not mail?  I think that would be ok.10:46
mjg59mdz: But that goal inherently provides information leakage about user capabilities10:46
mdzwe implemented a solution as pitti describes which makes it trivial to query sudo for this information10:46
pittiMithrandir: then we don't need mail for sudo without -t either10:46
mdzmjg59: yes, in my opinion a certain amount of leakage is probably OKO10:46
mdzOK10:46
pittiMithrandir: which would change sudo semantics on servers, too10:46
pittiMithrandir: sudo -t command && sudo command 10:46
Mithrandirpitti: hmm, right.10:46
mjg59mdz: I worry about changing security expectations from traditional unix10:47
pittimjg59: right, the question is how much leakage we want to sacrifice for this hide-admin spec10:47
mdzpitti: hmm?10:47
ogracant you add a switch to sudo for mailing the admin can set ? 10:47
mdzmjg59: I think sudo is a bit young to have traditional security expectations10:47
ograi.e. have it off by default on desktops and on on servers ? 10:47
mdzand this problem only applies to sudo10:47
pittiogra: sure, but I doubt that it would be easier than grepping desktop files10:47
mjg59mdz: I've seen people using it for years10:47
pittiogra: what defines a server then?10:48
\shsudo is not young..it wasn't popular...just like the story about telnet and ssh10:48
ograpitti, dunno, but we build this system, we can define it ...10:48
mdzmjg59: I agree with you in that getting to dapper from warty requires fairly extensive command-line familiarity already10:48
pittiogra: the problem is, the admin defines the purpose of the install, not we :)10:48
mdzmjg59: but I think we need to do better than the release notes if we're going to rely on admin membership in this way10:49
ograpitti, but we can define flags that get set, based on default options the installing person choose10:49
pittiogra: right, that was option 2 in my email to u-d10:49
ograor checks10:49
mdzpitti: do you think we could safely add users to the admin group on upgrades?10:49
mjg59mdz: Well, it's possible to do that (at the cost of requiring manual intervention during the upgrade)10:49
pittimdz: no, I'd not do that10:50
mdzthe entry created in sudoers by the installer is specially marked10:50
pittimdz: IF the admin configured fine-grained permissions, then this would lead to privilege escalation10:50
Mithrandirmdz: we could have an upgrade tool which asked the admin how he wanted stuff done, but I dislike that.10:50
=== ajmitch_ hasn't added an admin group here, and probably would be surprised to see it on an upgrade
mdzpitti: I think that can be avoided10:50
pittiwell, I wouldn't have a good feeling with changing group memberships on upgrades, even less so with admin10:50
\shmdz: this is somehow not the right solution...better to ask during dist-upgrade "Who is your admin user?"10:50
mdzpitti: the process would be to check for an entry in sudoers of the form:10:50
Mithrandirsomething like a ubuntu-fixup package which asked questions and tried to fix stuff in the postinst.10:50
mdz# Added by Ubuntu installer10:50
mdzmdz     ALL=(ALL) ALL10:50
pittimdz: we check for a default sudoers and do it only then?10:51
mdzpitti: a sudoers with the default entry10:51
mdzpitti: which is equivalent to admin group membership10:51
mdzi.e., unrestricted sudo to root10:51
pittimdz: well, that would cover the warty upgrade, what about the general usage of visudo without admin group?10:51
pittii. e. finer grained privs?10:51
mdzpitti: wouldn't those be superseded by the ALL entry?10:51
mdzconfiguring finer-grained privileges would require removing the ALL entry10:52
pittimdz: I mean with nonstandard sudoers (when we don't add users to admin)10:52
pittinot for upgrades10:52
mdzpitti: I don't understand10:52
pittimdz: if I allow joe to use sudo time-admin, but nothing else, then joe would not see time-admin in the menu10:52
pittimdz: if we don't care about this case, then group check is sufficient10:52
pittiif we do, then it's not10:52
mdzpitti: unless you add joe to the admin group10:52
mjg59Does dpkg-statoverrides have support for POSIX ACLs?10:52
mdzmjg59: RUN AWAY10:53
mjg59mdz: But then he'd see all of them, not just time10:53
mdzmjg59: that is acceptable to me10:53
pittimdz: he would not be in admin, of course, otherwise the 'sudo time-admin' entry would be pointless10:53
mdzpitti: if the admin wants finer grained permissions, they would remove the %admin entry10:53
pittiI know that it's a corner case10:53
\shpitti: is this the normal use-case for desktop installations?10:53
pittibut we should clearly say whether or not we support it10:53
pitti\sh: no10:54
\shI think I can remember windows xp asking even unprivilegded users to update windows xp via windows update10:54
mjg59pitti: 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 ACL10:54
\shand the user clicks on the toaster and "u don't have rights"10:54
ogra\sh, remember we are better than MS10:54
pittimjg59: I agree10:54
mjg59And I think we support ACLs on all our supported filesystems10:55
mdzmjg59: which ones are our supported filesystems?10:55
ograheh10:55
pittiit's just not something a non-hardcore freak would do10:55
mdzmjg59: currently, the process for granting admin privileges is trivial: adduser <user> admin, or check the tick box in the GUI tool10:55
\shogra: 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 anymore10:55
mjg59mdz: Right, and I'd see that as the default10:55
mdzACLs complicate that for both cases (more commands, and complicating the tool)10:56
mdzmjg59: so you're suggesting that we don't try to hide these entries by default?10:56
mjg59No, we hide those entries by default10:56
mdzmjg59: and leave it to the admin only if they really want to configure it that way?10:56
pittibut isn't our problem exactly the other way round?10:56
mdzpitti: yes10:56
mjg59In 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 solution10:56
pittiusers who aren't in admin, but have special rights won't see the desktop file10:56
pittiinstead of users without rights see them10:57
=== seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-meeting
mjg59mdz: ext3, xfs, jfs, reiserfs and nfs support them10:57
mdzmjg59: 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
pittiah, I see, we make the desktop files root:admin 640 by default?10:57
mjg59mdz: Correct10:57
=== seb128 [n=seb128@ubuntu/member/seb128] has left #ubuntu-meeting ["Ex-Chat"]
mjg59pitti: Yeah, that would work10:57
=== seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-meeting
mdzmjg59: I think dpkg probably clobbers ACLs on upgrades10:58
mjg59mdz: Well, that's a feature request for dpkg :)10:58
ograand i dont think we need even to think about this special cornercase ...10:58
ograswitch all on or all off ...10:58
pitti"Dear Keybuk, please teach dpkg-statoverride ACLs, kthxbye"?10:58
mdzpitti: I have an idea10:59
pittigive us the ultimate solution, Matt! :)10:59
mdzpitti: we could allow users to query sudo without any logging or warning if they are in the admin group10:59
\shhmmm....10:59
mdzpitti: and otherwise, fall back to displaying all of the menu entries10:59
pittimdz: that's what happen right now10:59
pittioh, wait10:59
ograisnt that backwards ? 11:00
pittiwell, if they are in admin, then we already know everything11:00
mdzIFF they are in the admin group11:00
pittiwe want to know information if they aren't11:00
ograexactly11:00
mdzif they aren't, we just display everything11:00
ograbut we dont want this11:00
mjg59mdz: Uhm. No, surely?11:00
pittiwell, then we don't need to do anything :)11:00
mdzI'm not particularly interested in having finer-grained menu entries corresponding to finer-grained sudoers11:00
mdzI just don't want the functionality to disappear from the desktop undesirably11:00
pittibecaue that would mean to always show everything :)11:00
mjg59mdz: If they're not in the admin group, we don't want to display anything11:00
mdzmjg59: you are introducing facts into the discussion11:01
ogralol11:01
\shI 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
mjg59Simplest solution:11:01
mjg591) Make .desktop files 640 and group admin owned 11:01
pitti\sh: that's easy, yes11:01
mjg592) Transition default user to admin group for warty upgrades11:02
mjg59Result: Most use cases sorted11:02
mdzmjg59: 2) is scary11:02
pittiI have a bad feeling about 2)11:02
ogramjg59, how do we know its a warty upgrade ? 11:02
\shpitti: and the gnome-menu reads the desktop file, right?11:02
pittibut I like 1)11:02
mjg59We're talking about users who, in sudoers, have ALL=(ALL), right?11:02
pitti\sh: right11:02
mdzmjg59: we don't have a persistent record of who the default user is and whether it's been customized11:02
mjg59So they could add themselves to the admin group *anyway*11:02
pittiright11:02
ogramjg59, yes, but i might have set this in a brandnew breezy because i think its cool11:03
mdzmjg59: it seems probable that there are corner cases11:03
ograso we would break hat11:03
ograthat*11:03
pittiI'm not questioning that, but we have to make damn sure that we get that right11:03
mdzwhat happens when you have multiple matching entries in sudoers for a user?11:03
mjg59mdz: If they have a fine-grained setup, we do nothing11:03
\shpitti: 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 it11:04
mdzmjg59: meaning what?  we don't touch it unless it hasn't been modified since installation?11:04
pitti\sh: see the spec, yes11:04
mdzmjg59: I'm saying that I think sudoers semantics may allow a finer-grained setup without removing the default entry11:04
mjg59mdz: I think we can justifiably add any user who has privileges to run anything to the admin group11:04
pittimjg59: your chmod solution has the added benefit that we don't actually need to add that X-Requires-Root: true key :)11:05
Mithrandirmjg59: that's not problematic, I think giving the admin group root-equivalent priviledges might be more problematic.11:05
=== ogra still wonders why we solve a GUI problem in the backend, and not in the GUI
\shogra: you can read my mind?11:05
mdzmjg59: I'm saying that that situation is difficult to detect reliably; it may not be as simple as looking for the expected line in sudoers11:05
mdzmjg59: and the risks of being too liberal are pretty severe11:05
ograits a task for gnome-menus as it was thought out in the beginning imho11:05
pittiogra: how do you want to determine if user foo can execute sudo command?11:05
ograpitti, if i check his groups11:06
pittimdz: if we go for group checking, then I'd prefer a release note11:06
\shpitti: sudo should be excuted by anyone...the app to run afterwards is determined by sudoers...we still have the cli 11:06
mdzpitti: I fear that we will be flooded by reports of users upgrading and then being locked out11:06
pittinot doing a relative simple .desktop parsing for security reasons, and then add a highly delicate sudoers rewriting doesn't fit together11:06
ograi wouldnt touch sudo at all ...11:06
mdzpitti: we don't know how many breezy systems are out there which are upgrades from hoary and warty11:07
mjg59The current options have at least one of the following problems:11:07
=== lamont [n=lamont@mib.fc.hp.com] has joined #ubuntu-meeting
mjg59a) Increase information leakage11:07
pittiogra: well, but see backlog, not every sudoer is in admin group11:07
mjg59b) Increase code run as root11:07
mjg59c) Are awkward for upgrades11:07
mdzwe've already increased the information leakage11:07
mjg59mdz: How?11:07
ograpitti, corner cases ...11:07
pittiwith the admin group11:07
mdzmjg59: sudo -t no longer asks for a password11:08
mjg59mdz: I think that's a bug11:08
mdzmjg59: it just bitches in the log11:08
\shpitti: but during a dist-upgrade from warthy, hoary, breezy to dapper, we could ask questions...and we can "rearrange /etc/sudoers"11:08
pittimdz: how is that information disclosure?11:08
mdzpitti: for the same reasons we've been discussing all along11:08
ograwhy not focus on the group and make a note in the release notes ... to warty systems it simply wont make a difference ...11:09
pittimdz: I don't understand why sudo -t command without a password discloses information11:09
mdzpitti: it allows the user (or an attacker with their privileges) to query sudo11:09
pittimdz: right, but not unnoticed11:09
mjg59mdz: 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 incorrect11:09
mdzpitti: the information is still leaked, we just record the fact that it was leaked11:09
mjg59When was this -t behaviour changed?11:10
mdzdapper11:10
mjg59Right. So we can revert it.11:10
=== amu [i=amu@debian/developer/amu] has joined #ubuntu-meeting
mjg59mdz: It's the sort of thing that will get mentioned on bugtraq11:10
mdzif we can't do this without unacceptable tradeoffs in robustness or security, we should consider not doing it11:10
mdzmjg59: I do not fear bugtraq11:10
pittimdz: right11:10
mjg59mdz: 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
mdzI believe it was also mentioned on bugtraq that we grant sudo privileges rather than using a root password11:11
amumoin11:11
mdzthe world moved on11:11
ajmitch_hi amu11:11
ograhey amu11:11
pittiok, then let's ignore the custom sudoers case and just check for admin membership11:12
ograyeah11:12
mdzpitti: that leaves us back to dealing with warty upgrades11:12
pittithe workaround is really evil, but it seems that sudo solution is evil, too11:12
ografor warty upgraded systems the menu will just go on looking like before ...11:12
mjg59mdz: If sudo -t continues to log, then that's going to be a *lot* of log entries for terminal server-type installs11:12
mdzand hoary, in fact, no? didn't we change to group admin in breezy?11:12
mjg59And if it doesn't log, it's a security pain11:12
ograi dont think thats bad11:12
mjg59I /think/ hoary had an admin gorup11:12
pittimjg59: it should log11:12
mdzmjg59: it's unacceptable to use sudo for this if it logs11:13
pittimjg59: hoary had11:13
mdzmjg59: but you've said that you find it unacceptable to use sudo for this at all, already11:13
mdzbecause we can't use sudo for the query unless we allow it to be queried without a password11:13
mjg59mdz: 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:13
mdzI'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 place11:14
pittimjg59: well, with the desktop file test, we would not leak any info on servers11:14
mdzdo we create the admin group on upgrades?  if not, we could check for its existence11:14
ograno, we dont11:15
pittiwe would drop -t11:15
pittiand introduce --check-desktop-file, or so11:15
mjg59pitti: Uhm.11:15
mjg59pitti: How does that help?11:15
ograwhy must that be done on sudo pitti ?11:15
ograin*11:15
pittimjg59: on servers there are no .desktop files, so there is no information leak11:15
mdzogra: are you sure?  where is admin created?11:15
mjg59pitti: That's not a sensible assertion11:15
pittiogra: /etc/sudoers is readable only by root11:15
ogramdz, from hoary on in the installer afaik11:16
mjg59pitti: mjg59@kern:~/ > locate .desktop | grep /usr | wc 353     353   1608011:16
ograpitti, we have the info in the .desktop files, we can make gnome-menus check the group11:16
mjg59mjg59@kern:~/ > wc /etc/passwd11:16
mjg59  3576   8484 220748 /etc/passwd11:16
ograno need to touch sudo at all11:16
mjg59pitti: So, no. Being a server does not mean that people don't run graphical sessions.11:16
pittimjg59: well, we would limit the information leak to exactly the information we need  - desktop files11:17
pittiinstead of arbitrary commands11:17
pittimjg59: well, if people use sudo under X, then we don't need to worry about information leaks11:17
mjg59pitti: But the user then (effectively) knows that they can execute whatever is in that .desktop file11:17
mdzogra: I can't find where it's created11:17
pittimjg59: exactly11:17
pittithat's the amount of sacrifice we need to do IF we want this11:17
ogramdz, i only know that its there since hoary ... for all new installs i did11:17
mjg59pitti: Right. So I think it's a stupid idea in that form.11:18
ogramdz, and its not there on upgraded systems11:18
pittimjg59: it's better than sudo -t command IMHO11:18
=== pusakat [i=proxy@203.167.88.65] has joined #ubuntu-meeting
mjg59pitti: Being stabbed in the hand is better than being stabbed in the eye :)11:18
sistpotywhy not check in /etc/group as heuristic instead of the sudoer-file?11:18
pitti*shrug*11:18
mdzpitti: how about my suggestion?11:18
pittimdz: the one with not doing anything at all?11:19
mdzpitti: 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
pittimdz: that's what we have now11:19
ogramdz++11:19
mjg59That works for me.11:19
pittioh, ok11:19
mdzpitti: and revert the sudo change11:19
pittimdz: would work for me11:19
ograthe behavior for upgraded warts just wont change ...11:19
mdzI thought we created admin on upgrades, but ogra pointed out that this isn't true11:19
mdzso this is a very simple solution11:19
pittifor warty upgrades that's certainly fine11:19
pittipeople are used to the menus by now, probably11:20
mdzok, I think we've licked it11:20
ograso keep the change at gui level ? 11:21
mdzthat only took an hour11:21
pittimdz: that would mean to break the case when admin group is not actually used, but that's probably a small enough corner case11:21
ogratogether with the checks etc 11:21
mdzpitti: I'm satisfied with that11:21
pittiit's certainly fine for me11:21
mdzok11:21
mdzDONE11:22
pittibut I think it was important enough to talk about it11:22
mdzDOIT11:22
ographew11:22
pitti'k :)11:22
mdzany other business?11:22
pittisleeeep11:22
=== ogra finally opens a merlot
mdzI would like to talk about scheduling meeting times11:22
mdzbut we should do that when we have everyone here11:22
mdzI'll just send email to TB about it11:22
pittiat the beginning of next TB?11:22
mjg59Cool11:22
\shogra: grmpf...11:22
mdzworkrave HATES ME11:23
ograhit it11:23
\shmdz: kill -9 ?11:23
mdzmeeting adjourned11:23
pittimdz: it is wonderfully silent if I just keep cklicking on 'skip' :)11:23
mdzthanks, everyone11:23
pittithanks, guys11:23
mjg59Night11:23
ograthanks mdz11:23
\shthx mdz11:23
=== janimo [n=jani@Home03207.cluj.astral.ro] has left #ubuntu-meeting []
mvonight11:23
=== pitti [n=pitti@ubuntu/member/pitti] has left #ubuntu-meeting []
ogranight mvo 11:24
zakamenight mvo 11:24
mvonight ogra, zakame 11:24
\shogra: pingeling...ubuntu-de-messe please...amu wants to come with us :)11:27
ograYAY !!!11:27
ograi have a vey dirty car and wont have the time to clean it before ... so you have to live with that :)11:28
=== minghua [n=minghua@danube.mems.rice.edu] has left #ubuntu-meeting []
=== ealden [n=ealden@219.90.92.151] has joined #ubuntu-meeting
=== Burgwork [n=corey@S010600131016cf6f.gv.shawcable.net] has left #ubuntu-meeting ["Leaving"]
=== sistpoty [n=sistpoty@ubuntu/member/sistpoty] has left #ubuntu-meeting []
=== zakame [n=zak@ubuntu/member/zakame] has left #ubuntu-meeting ["Leaving"]
=== pusakat [i=proxy@203.167.88.65] has left #ubuntu-meeting ["Leaving"]
=== mgalvin [n=mgalvin@cpe-69-205-38-37.nycap.res.rr.com] has joined #ubuntu-meeting

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!