=== jalcine is now known as JackyAlcine_ === webjadmin_ is now known as JackyAlcine_ === AfC1 is now known as AfC === webjadmin is now known as JackyAlcine_ [05:42] Good morning === tkamppeter_ is now known as tkamppeter [07:27] good morning [07:29] morning. unfortunately not so much a good one. :-/ [07:30] * Sweetshark found out people have ripped him of a ~1000Euros on his Visacard. [08:07] didrocks, hey [08:08] didrocks, good morning for you [08:09] hey didrocks [08:09] hey bschaefer [08:09] morning pitti [08:09] Sweetshark: urgh -- but I guess they'll reimburse it? [08:09] didrocks, so a I've been asked about doing an SRU for the new ibus changes [08:10] didrocks, or more or less people have asked for it [08:10] bschaefer: hum? did your management asked for it? [08:10] ask* [08:10] didrocks: no, I told him to ask you :) [08:10] didrocks, nope, thumper told me to talk to you about it. As the changes would be in both nux and unity [08:10] bschaefer: seems quite a big change IMHO [08:11] and largeish [08:11] bschaefer: and 2 month before we recommend using the LTS [08:11] didrocks, agreed [08:11] doesn't seem reasonable to me [08:11] better to focus on precise now [08:11] didrocks, I just wanted to check so I have something to tell people when I get asked about it :) [08:11] didrocks, but that sounds good thank you :) [08:11] you can tell the above ^ [08:11] :) [08:12] yw [08:41] I am experiencing strange movement of applications when I click their icons in launchre. [08:41] launcher. === webjadmin is now known as JackyAlcine_ [08:45] good morning everyone [08:45] hey chrisccoulson, how are you? [08:45] hi chrisccoulson [08:45] chrisccoulson: is your foot any better? [08:45] pitti - yeah, it's much better, thanks [08:46] chrisccoulson, I hope you didn't shot yourself in the foot. :) [08:47] heh, not quite ;) [08:47] all well then.:) === webjadmin is now known as jalcine [08:49] need to take my wife to the doctor, back later [08:52] morning mvo [08:52] hey glatzor! [08:52] glatzor: did you had a chance to look at my aptdaemon branch? the one about sudo vs admin group? [08:53] mvo, regarding lp:~mvo/aptdaemon/admin-group-fix, we cannot rely on the group that the user is in [08:53] glatzor: in the test? or in the actual code? [08:53] mvo, every user could theoretically buy software - thanks to policykit [08:53] mvo, in the code. [08:54] glatzor: hm, in this case we could a) use 0640 and set the group to the users gid or we use the /etc/apt/netrc file for the username/password storing [08:54] I guess (b) is more elegant [08:56] just for the background: ubuntu has merged the sudo group from debian? is there an automatic migration from admin to sudo? [08:58] why is the permission root:root insufficient? [08:58] does the user need to read his own password anywhere? [09:04] chrisccoulson: hey hey, how was your week-end? [09:04] didrocks, yeah, not too bad thanks. and yours? [09:05] chrisccoulson: was nice. However, the night was short (took Julie to see the doctor urgently, was feeling some pain. She's better now) [09:05] hey [09:05] so, lacking sleep now :) [09:05] salut seb128 [09:05] oh, that sucks. it's good that she's better now though [09:06] hey seb128 [09:06] lut didrocks [09:06] didrocks, what happened to Julie? [09:06] chrisccoulson, hey, how are you? [09:06] seb128, yeah, not too bad thanks [09:06] I made chrisccoulson do desktop work again \o/ [09:06] lol [09:06] yeah :) [09:06] chrisccoulson, thanks for fixing that, I still don't get why the valgrind log on that bug didn't show an invalid write in nautilus code [09:06] seb128: some stomach pained which seems to have happened shortly, but in an intensive way [09:07] didrocks, oh :-( [09:07] didrocks, is she better? [09:07] pain* [09:07] seb128, i'm not sure valgrind works for stuff which isn't heap allocated [09:07] seb128: yeah, way better this morning :) [09:07] great [09:07] chrisccoulson, hum, could be, maybe it's time I get a 64bits install ;-) [09:07] chrisccoulson, thanks for sorting it in any case! [09:07] you're welcome :) [09:28] seb128, didrocks: If you see anyone complaining about "X froze when I moved the mouse to the screen edge to reveal the launcher", bug #946954 is what I'm using to track it. apw has very kindly furnished me with a backtrace fully describing my oversight. [09:28] Launchpad bug 946954 in xorg-server "Deadlock on attempting to reveal launcher" [Critical,In progress] https://launchpad.net/bugs/946954 [09:28] RAOF, hey, ok, great, thanks! [09:29] Now, dinner. [09:29] oh nice, thanks RAOF :) [09:29] RAOF: enjoy [09:34] RAOF, oh, i keep seeing that bug too [09:35] i also noticed at the weekend that i get a blank screen when i resume from suspend (although, my session is functional and i can still interact with it - i even see the cursor changing on the screen) [09:35] chrisccoulson, but I'm sure you were blaming it on dx :p [09:35] seb128, yeah, it's always compiz fault [09:35] hehe [09:36] i was getting ready to blame compiz for the nautilus crash ;) [09:36] well to be fair that one was dx's fault :p [09:36] it was a patch from them [09:36] heh [09:37] ooh, nice: https://twitter.com/#!/mozhacks/status/176597541285142528 ;) [09:37] ok, I'm out for half an hour or so, bbiab [09:42] glatzor: ups, sorry missed your message. so ubuntu did merge sudo but there is *no* automatic migration [09:43] glatzor: root.root and 640 is not good because then apt will not be able to read the package information for that repository [09:43] glatzor: and 644 is not good because the password is visible systemwide [09:44] glatzor: the alternative is 644 and putting the password into /etc/apt/netrc, maybe that is the way to go, let me test, its pretty much untested :/ === webmaster is now known as davidcalle [09:59] glatzor: so /etc/apt/auth.conf seems to be fine, would you accept the patch if I simply write to there? [10:00] is it known that language reverted to English in ubuntu precise? [10:00] maybe lang pack are broken or something? [10:01] xclaesse, no, works fine here [10:01] xclaesse, what does "locale" say? [10:02] hm, weird, it's a mix of fr_FR and en_US... [10:02] did you play with the control center region capplet? [10:03] seb128, I've played with the stuff in keyboard layout (not asking why language is there...) [10:03] xclaesse, seems like a bug in the region stuff then [10:06] seb128, ok, I've moved french to the top in ubuntu's language window, and now all is fine [10:06] good [10:06] so it seems that conflicts with g-c-c [10:08] it should not, the GNOME region stuff is known to be buggy and unfinished though, that's why we hide it under Unity [10:08] it was on the list of stuff to fix for this cycle but we didn't get to it [10:08] so next cycle I guess [10:15] seb128, ok fair enough :) [10:26] mvo auth.conf? [10:26] seb128: is there any reason not to update to the latest libglib-perl? I see one small feature (Add a fallback implementation of SvMAGIC_set), it also fixes the FTBFS in the latest rebuild [10:27] micahg, don't ask me, I've no clue about perl nor interest for it [10:27] micahg, but not reason as far as I'm concerned [10:27] glatzor: yeah, its a (very underused) feature in apt to support seperation of credentials from sources.list [10:27] glatzor: I work on a branch for it now and updated the merge proposal [10:27] mvo, ah I see - back from Lucid :) [10:28] glatzor: yes [10:28] glatzor: I push my initial branch and need to run to a appointment [10:28] mvo, is it ok for you if I take a look at it this afternoon? [10:29] glatzor: sure, I push my branch and you can tidy it up and make it pretty, sounds good? [10:30] glatzor: or I can make it as pretty as possible and you just need to ack it [10:30] mvo, that is the way to go! [10:30] mvo, it is ok for me to to do the dirty work :) [10:30] glatzor: awsome! lp:~mvo/aptdaemon/use-apt-auth.conf is the branch [10:31] glatzor: so far it just contains the failing test, but its hopefully easy to add the rest, I will see what I can do before lunch and leave you the pieces ;) [11:06] Why are my windows randomly displaced around the desktops? :/ [11:18] hey seb128, how are you? [11:18] pitti, hey, alter! wie gehts? [11:18] I'm good thanks, had a relaxing w.e [11:19] seb128: me too; we can't do much anyway these days :) [11:19] pitti, so my week of effort was just enough to balance your two apport uploads and you got over the mark with jockey today, I'm working on fixing that ;-) [11:20] seb128: hehe [11:20] pitti, how is your wife doing? [11:20] * pitti finishes the lightdm upload he was preparing before [11:20] seb128: it's going as expected, no difficulties [11:20] ok, good [11:20] pitti, >lightdm, I guess it's just the fd leak stuff? [11:20] a lot of sessions at the physiotherapist and some at the doctor still, of couse [11:20] not a fixed 1.1.4? [11:21] seb128: oh, right, I should pick that, too [11:21] seb128: I'm working on bug 868400 [11:21] Launchpad bug 868400 in gnome-settings-daemon "Synaptics touchpad stops working - two syndaemon instances running" [Medium,Confirmed] https://launchpad.net/bugs/868400 [11:21] it also needs a g-s-d fix [11:21] pitti, the issue is mostly g-s-d [11:21] i.e when gsd segfault and is respawned [11:21] yes, understood [11:21] I think the lightdm part was a redherring [11:21] well, not quite [11:22] it also starts a syndaemon in the greeter session, and it's not properly killed [11:22] anyway, it can't hurt to just disable it, it's not really needed [11:22] but yes, I'll also work on the g-s-d side, that's more involved [11:22] gsd side> I think we should do whatever syncdaemon is doing in gsd [11:23] like copy the code there if we can [11:23] rather than calling an external command [11:23] I hoped upstream would pick it up but they didn't yet [11:23] that'd be more elegant, but it's also quite a lot of code [11:23] and the code also isn't very good [11:23] ok, that's what I feared [11:23] as a g-s-d maintainer I'd be opposed to adopting it [11:24] it's a very ugly polling loop, instead of subscribing to key events [11:24] I guess the easiest way is to check if a syndaemon is running and not start one in this case [11:24] I tried writing an event-based replacement, but did not get that far yet [11:24] seb128: right, and I'll start with that [11:24] great [11:24] GNOME 3.3.91 tarballs day today btw [11:24] we have bug 906987 to track the "ugly code" part [11:24] Launchpad bug 906987 in xserver-xorg-input-synaptics "syndaemon polls 5 times a second even though it is started with the -R XRecord extension option" [Medium,Triaged] https://launchpad.net/bugs/906987 [11:24] just for info for those interested [11:28] seb128: the fd leak fix doesn't backport well, I'll rather wait for mterry to investigate the 1.1.4 regression [11:29] pitti, ok [11:43] pitti: libreoffice_3.5.0-2ubuntu1 on chinstrap is waiting for sponsoring. [11:43] didrocks: unless you volunteer for ^^ [11:43] Sweetshark: still kind of busy with unity/compiz [11:49] Sweetshark: sure, doing; BTW, did you get any feedback on your PPU application? [11:54] pitti, urg, your lightdm hack is wrong imho [11:56] pitti, I will revert that in the vcs [11:56] seb128: oh, how else do you provide an user specific dconf setting? [11:56] pitti, lightdm has nothing to do with gsd [11:56] pitti, that's an unity-greeter specific issue [11:57] perhaps, but it's lightdm which creates the user [11:57] pitti, and unity-greeter already has code to disable half the gsd plugins [11:57] pitti: still only one endorsement (yours), so I didnt really push it further. [11:57] and the bug is not speicifc to the unity greeter [11:57] pitti, no other greeter run gsd [11:57] seb128: oh, fair enough; if it's better done in unity-greeter, I won't object [11:59] pitti, http://bazaar.launchpad.net/~unity-greeter-team/unity-greeter/trunk/view/head:/src/settings-daemon.vala [11:59] pitti, I think it's better to add a line there [11:59] pitti, rather than doing postinst hacks [12:00] seb128: oh, it already disables the mouse plugin [12:00] pitti, right, I wonder why the bug is happening at all then :-( [12:01] seb128: presumably due to multiple g-s-ds in one session (after crashing) [12:01] seb128: ok, I'll revert it in lightdm then, sorry [12:01] pitti, no worry, just revert it in the vcs [12:02] pitti, I'm puzzled by the second entry in the changelog btw, http://launchpadlibrarian.net/95371871/lightdm_1.1.4.is.1.1.3-0ubuntu1_1.1.4.is.1.1.3-0ubuntu2.diff.gz === CharlieMike is now known as ayan [12:02] pitti, I see no actual change matching it? [12:03] hm, that change already was in bzr [12:03] so yes, that looks missing indeed [12:04] seb128: I'll add it for good, while I'm at it [12:04] seb128: thanks for spotting this [12:20] hum, I disconnected during lunch it seems [12:20] pitti, if you said anything for me after my " oh, I bet robert_ancell forgot to bzr add in r1077" please say it again ;-) [12:20] (or anyone else) [12:21] seb128: I didn't actually see that any more [12:21] up [12:21] pitti | hm, that change already was in bzr [12:21] pitti | so yes, that looks missing indeed [12:21] pitti | seb128: I'll add it for good, while I'm at it [12:21] pitti | seb128: thanks for spotting this [12:21] pitti, thanks ;-) === greyback is now known as greyback|lunch [12:49] glatzor: welcome back, I have a merge-proposal for you, but a second pair of eyes is more than welcome :) [12:52] glatzor: so for the install-different-versions branch you suggest that I simply make my code smarter to understand about upgrade/downgrade and use that when a version is forced? and that will work even if apt is not of the opinion that the package is upgradable (its only upgradable when the version is explicitely set)? [13:00] didrocks: ping [13:00] hey m4n1sh [13:00] * didrocks will try to find some time to have a break at some point :) [13:00] as you wished, here is UIFe proposal https://bugs.launchpad.net/ubuntu/+source/activity-log-manager/+bug/945557 [13:00] Launchpad bug 945557 in activity-log-manager "[UIFe] Selection list for blocking application logging provides usage and last-used column. Upload activity-log-manager 0.9.3" [Undecided,New] [13:00] you need to go hiking in the alps after every ubuntu release === MacSlow is now known as MacSlow|lunch [13:01] m4n1sh: well, I was born in the alps, so knowing this kind of landscape quite well ;) [13:01] that's even better [13:01] so what is the next step for UIFe process [13:01] will it discussed in release meeting or they will look into the proposal separately? [13:02] m4n1sh: we need to wait for the documentation team to ack or nack the change [13:02] okay [13:02] m4n1sh: as you subscribed them, they should look at it [13:02] maybe, try to catch some people on IRC as well [13:02] like Jeremy is around normally [13:03] (jbicha) [13:03] oh, he is in docs team. never knew that [13:03] yeah ;) [13:03] asking when he's around is the easiest way [13:04] good morning, ubupeeps [13:04] hey desrt [13:05] * m4n1sh once saw a photo of desrt comically photoshopped with ploum [13:05] lol [13:05] something in a bed I guess :) [13:05] hey desrt [13:05] yes [13:05] I think I found it, but not sure if it as per CoC [13:05] the internet never forget ;-) [13:07] m4n1sh: i think everyone has seen that picture [13:08] it turned up on PGO and Planet Ubuntu [13:08] including my parents... [13:08] it comes up on the first page when you google my name, so..... [13:08] pretty much everyone i know has seen it :p [13:10] so as per the post next up is with vincent [13:10] fortunately vuntz doesn't have the same flair for GIMP as ploum [13:19] mvo, sorry. my laptop crashed. [13:20] glatzor: no worries [13:20] glatzor: glatzor: welcome back, I have a merge-proposal for you, but a second pair of eyes is more than welcome :) [13:20] glatzor: so for the install-different-versions branch you suggest that I simply make my code smarter to understand about upgrade/downgrade and use that when a version is forced? and that will work even if apt is not of the opinion that the package is upgradable (its only upgradable when the version is explicitely set)? === greyback|lunch is now known as greyback [13:25] ricotz: thats for the python reply. I thought that was a backport only issue. sorry about that. [13:26] mvo, I will be back soon [13:26] see you [13:26] glatzor: see you [13:27] Sweetshark, yeah, it is a upstream problem after all ;), but thanks for notifying [13:29] ricotz: 90% of our open launchpad LO bugs are upstream -- and most even feature requests, so no exception there ;) [13:30] Sweetshark, alright -- don't forget to push the git changes [13:31] ricotz: done already. [13:32] Sweetshark, i see, wasnt there when i looked ealier ;) [13:35] is there a way to disable apparmor on mission-control ? [13:36] now when I install a telepathy-gabble from source, MC won't be able to read my accounts anymore because: [13:36] open("/usr/local/share//telepathy/managers/gabble.manager", O_RDONLY) = -1 EACCES (Permission denied) [13:40] xclaesse: sudo apparmor_parser -R /etc/apparmor.d/usr.lib.telepathy to temporarily do it. to do it permanently, sudo aa-disable /etc/apparmor.d/usr.lib.telepathy. You can also add entries to /etc/apparmor.d/loca/usr.lib.telepathy such as ' /usr/local/** mr,' and do 'sudo apparmor_parser -r /etc/apparmor.d/usr.lib.telepathy' [13:40] /etc/apparmor.d/local/usr.lib.telepathy allows you to make local policy changes [13:43] jdstrand, thanks [13:43] * xclaesse just disabled permanently, to not get bothered anymore :) [13:44] * jdstrand does not generally advocate that ;) [13:45] jdstrand, any reason to not include /usr/local in those rules? [13:46] it isn't really appropriate for the disto. any number of things can be in there [13:49] hm, and teleapthy-* installed in /usr/local/libexec does not seems to get dbus-activated anymore neither [13:50] good morning everyone [13:52] jdstrand, I don't get it, only root can install in /usr/local [13:53] so surely if that's compromised, there is nothing you can do anymore.... [13:54] xclaesse: /usr/local is site-specific and we don't know what's in there. the profile itself limits what it can read from /usr as well, which is also admin controlled. the point is to have a policy that is still meaningful security-wise. allowing all of /usr/local is too open === MacSlow|lunch is now known as MacSlow [13:58] jdstrand, is there a way to disable all of apparmor? even after disabling the telepathy rules, telepathy-gabble installed in /usr/local does not get dbus-activated [14:00] xclaesse: if you are not getting any apparmor denials (look at kern.log), then it shouldn't be apparmor blocking that. that said, yes you can disable apparmor: boot with apparmor=0 [14:02] jdstrand, I see no apparmor log in kern.log [14:03] even though I'm 100% sure that denial ( open("/usr/local/share//telepathy/managers/gabble.manager", O_RDONLY) = -1 EACCES (Permission denied)) was because of apparmor since disabling telepathy rules made it pass immediately [14:06] xclaesse: you might be hitting the kernel rate limiting: sudo sysctl -w kernel.printk_ratelimit=0 [14:08] xclaesse: surely apparmor was not allowing /usr/local/share//telepathy/managers/gabble.manager, but that doesn't mean it is blocking dbus services (indeed, we don't confine dbus in Ubuntu) [14:08] * jdstrand points xclaesse to https://wiki.ubuntu.com/DebuggingApparmor [14:17] jbicha: ping [14:17] jdstrand: why is this file in /usr/local being prohibited anyway? [14:17] because the policy doesn't allow it (see backscroll for why the policy is written this way) [14:18] I only recently joined [14:18] 07:54 < jdstrand> xclaesse: /usr/local is site-specific and we don't know [14:18] what's in there. the profile itself limits what it can read [14:18] from /usr as well, which is also admin controlled. the point [14:19] more telepathy apparmor woes? [14:19] is to have a policy that is still meaningful security-wise. [14:19] allowing all of /usr/local is too open [14:19] isn't the policy supposed to protect from buggy software, not buggy administrators? [14:19] like, /usr/local is still admin-controlled [14:19] desrt: if there are bugs in the telepathy profile, please file them [14:20] Robot101: there is no reason to put things in /usr/local/ rather than somewhere else in /usr/ allowed by policy. [14:20] jdstrand: just thinking about this recent bug where the profile caused problems with dconf as well [14:20] (or elsewhere on the filesystem of course) [14:20] Robot101: the policy is not supposed to protect against buggy software, it is supposed to limit the accesses the confined application has access to so an attacker as a smaller attack surface [14:20] m4n1sh: good morning [14:20] jbicha: good evening :) [14:20] jdstrand: well... yes. I characterise an application controlled by an attacker to be buggy. :) [14:21] cyphermox: because the FHS says that's what /usr/local is for, the local administrator to put things which they'd like to be run on the system? [14:21] jbicha: are you in ubuntu-doc team? can you approve my mail which is in the queue? (I am not subscribed, but as per UIFe policy, I need to send a mail to it) [14:21] if an admin is installing things in /usr/local, the admin presumably knows what he/she is doing and can update the /etc/apparmor.d/local policy [14:21] Robot101: nm me, I thought this was a different kind of policy (regarding packaging things in /usr/local/) [14:22] m4n1sh: I'm not a list admin, you could try subscribing to the list and then resending your email [14:22] regardless, I'm fully behind jdstrand re: the rationale for not allowing /usr/local/ in apparmor policy [14:22] jbicha: looks like the only way left [14:22] jdstrand, I doubt ever dev building their sw knows about apparmor [14:22] that admin knows better than us where things are being installed. we shouldn't try to guess that or water down the shipped policy [14:23] (hm, in the meantime, it seems my gabble gets activated now... wondering what I changed...) [14:23] I don't think that follows at all - the admin can't necessarily be expected to be familiar enough with apparmor or telepathy to correctly reconfigure those things [14:23] xclaesse: that may be true, but an admin can ask for help, like you did. we don't want to reduce the security policy of the (vast) many for the few [14:23] * kenvandine runs out for a bit, bbl [14:24] I still don't understand what "vulnerability" running stuff which was put into /usr/local by root actually exposes you to - root can disable apparmor or any policy anyway can't they? [14:24] if you are an admin, you by definition should know how to administer the system. apparmor provides debug logs for denials === kenvandine is now known as ken[out] [14:25] Robot101: you are conflating two things. we are protecting the normal user. if there is a security bug in telepathy, we want to limit what it has access to. just like we allow specific accesses to /usr, we don't allow full access to /usr/local. if you want full access to /usr/local, put it in /etc/apaprmor.d/local [14:26] Robot101: if someone were running telepathy as root, it would prevent a security bug from allow root to modify policy via telepathy [14:26] apparmor is root strong [14:26] is there some middleground where we could provide the policy for, eg, telepathy to work properly in /usr/local, but have it disabled by default? [14:27] well, we have that now. anyone can add whatever they want to /etc/apparmor.d/local/usr.lib.telepathy [14:27] the policy embodies a load of domain knowledge in how telepathy and apparmor should interact which I don't expect on average, an admin would have - and they'd just disable apparmor as a consequence of "stuff doesn't work" [14:27] as for some sort fo runtime variable-- it would be possible, but then the developer still needs to know to switch it [14:27] Robot101: +1 [14:28] my general approach to apparmor is the same as my general approach to selinux: my life is a lot easier when i turn it off [14:28] which, in this case, they have to know about apparmor, and can just add the rule in /etc/apparmor.d/local/usr.lib.telepathy [14:28] over-active policies just make me turn it off that much faster [14:28] yeah, but we're going to get a bunch of support requests from this - "I installed this; stuff didn't work" "ok, disable apparmor" [14:29] desrt: that is very unfortunate. if there iare bugs against apparmor policy in Ubuntu, please file them. we work extremely hard to have the apparmor policy work for normal users in the default install [14:29] just like SElinux [14:29] the net result of neither us nor the administrator understanding or caring about apparmor. if we could say run "sudo aa-enable telepathy-local" or whatever, that'd be far nicer. [14:29] jdstrand: i think i have a fundamental disagreement with the idea behind things like apparmor/selinux [14:29] Robot101: we've shipped apparmor policy for various things since hardy. this is not new. people file bugs, we fix them [14:31] desrt: then we disagree. I would appreciate if you would not promote deactivating a meaningful protection that is protecting literally millions of users because you have a philosophical problem with it. by all means, on any systems you administer, do what you want, but the protection is real [14:31] plenty of times remote code execution vulnerabilities were reduced to a denial of service because of apparmor protections [14:31] (and these are noted in our USNs) [14:33] desrt, Robot101: well, normal users don't install stuff in /usr/local or when they do that 90% of the time bite them back later [14:33] some days I think we should drop /usr/local being loaded before /usr by default [14:33] Robot101: if you would like that functionality, please file a bug and submit a patch. we have been shipping a telepathy policy since oneiric. we have had extremely few bugs against the policy when compared against the number of users [14:34] it keeps bitting people who do make install without understanding and 1.5 year later wonder why things stop working because they have a 1.5 years old glib in local [14:34] seb128: i think /usr/local is a mistake from a forgotten era [14:34] and when there are bugs, I take them seriously and fix them [14:34] desrt, right, Robot101 seems to think it's not useful,used though [14:34] seb128: that doesn't change my fundamental hate for selinux and (to a lesser extent) apparmor :) [14:34] jdstrand: I'm not 100% convinced either way - I just wanted to hear the arguments :) [14:35] I don't disagree that a maximally-restrictive but properly-functioning policy by default is the best thing [14:35] note that it's not only /usr/local, if you install a telepathy CM in any prefix, you won't be able to use it until you disable apparmor rule [14:35] Robot101, your users should never have to fiddle with /usr/local [14:36] xclaesse, that seems wrong, the normal /usr directory for those should be whitelisted [14:36] seb128, that's even worse, you mean I should make install into /usr ?? [14:36] xclaesse, no, I mean normal users shouldn't make install ever [14:37] desrt: I doubt I would convince you of anything else. but know that the security team is keenly aware of people knee-jerkingly turning off selinux and do not want them to turn off apparmor. we strive hard to make sure things work for people. there are bugs-- report them and we'll fix them. we also are keen to not break things-- look at the disabled by default rsyslog policy for evidence. we ship it, but could not ship it enabled for all Ubun [14:37] yeah, normal users are on windows7 anyway :p [14:37] seb128, devs are pretty common linux users... [14:37] xclaesse: seb128 has a point - old crap in /usr/local probably breaks our stuff more often than apparmor does :) [14:37] xclaesse, dev should be able to run aa-complain or have a custom profile [14:37] jdstrand: i appreciate your position and i do appreciate that apparmor is quite a lot less bad than selinux [14:38] jdstrand: but these sort of added-on-after-the-fact approaches to security will always have these sorts of problems [14:39] chrisccoulson: hey, are you still on unity on precise, right? [14:39] by and large, the 'upstream' world has failed to be convinced that one of these systems is necessary or useful [14:39] and therefore software is not written with it in mind [14:39] certainly. unfortunately stuff has security bugs and we can't fix them before the fact. telepathy is a network listening daemon installed on all Ubuntu systems and in use on many. a bug in it is scary stuff, so we do the best we can with what we've got [14:39] desrt: that's because upstream thinks they write secure code :) [14:39] no. it's more like upstream thinks that the standard unix permissions model will be good enough [14:40] (well, we could fix them before the fact with a deep audit, but then the codebase changes so significantly that audit would soon be out of date...) [14:41] honestly, this problem won't be solved by something like apparmor [14:41] it's just a hack/workaround [14:41] we need a proper privilege separation concept in the kernel as a first-class citizen [14:41] something like what android does, for example [14:41] telepathy upstream doesn't think we write secure code - we designed telepathy specifically so it /could/ be thusly contained :) [14:41] I mean, we load in libpurple. we're automatically doomed.... :P [14:41] each distro having completely different security rules/tools does not help trusting them... [14:41] (although that's obviously insane for us to adopt in its current form) [14:42] olpc's rainbow thing did the same uid containment thing pretty nicely [14:42] desrt: we're more like what ios does [14:42] things like disabling ptrace by default are quite helpful [14:42] but probably nowhere near good enough [14:43] anyway.. what i think i mean is that there needs to be higher walls between processes as a basic property of the normal functioning of the operating system [14:44] not according to some policy written by a human that changes from time to time [14:44] until that happens we are failing [14:45] pitti: ping [14:46] hello desrt (on call) [14:46] pitti: just a poke about XDG_RUNTIME_DIR [14:46] pitti: things are going to start getting *really* bad for dconf+nfs if you don't support this [14:48] pitti: i have an incoming patch, basically. i could probably argue that we're well past feature freeze and i should hold off until next cycle [14:48] pitti: but it's absolutely certainly going to be in by early next cycle [14:49] if you will go systemd already next cycle and don't want to waste time doing the XDG_RUNTIME_DIR upstart hack in the meantime i could use that as an argument to wait [15:03] jbicha: Can you please upload gnome-panel 3.3.91? It fixes half of bug 828392 :) [15:03] Launchpad bug 828392 in gnome-panel "light-themes don't display well in gnome-panel 3+" [Low,Triaged] https://launchpad.net/bugs/828392 [15:20] seb128: i'm going to ping moch to make a rb release, when that side of the globe comes on-line later today, but if he doesn't make a tarball release tonight, do you think it would be better to package a snapshot, or to cherry-pick some fixes into the ubuntu package? [15:21] dobey, either way, I didn't look at git enough but I would be in favor of snapshot to reduce the delta with the next tarball [15:22] hiya [15:23] can we do something about the desktop sponsoring items? there's 22 of them (not only quicklists) [15:23] seb128: ok. it brings back magnatune plug-in i think, and a few other big changes (like getting rid of most all the gtk_dialog_run usage). [15:23] ricotz: i guess i should ask you if you have any opinion on it as well? ^^ [15:24] dobey, open a ffe bug I guess [15:24] dholbach, heya [15:24] ok [15:25] hey seb128 [15:25] dholbach, I will try to have a look but today is GNOME 3.3.91 tarball day so it's likely to not be your lucky day for sponsoring [15:26] thanks seb128 [15:26] seb128: when you get a chance, can you try latest compiz and unity (I just copied them in unity-team/ppa)? [15:26] didrocks, ok [15:26] seb128: seems that most of RC bugs are fixed, but I still don't get any appmenu showing on pressing alt on Qt app or xul ones [15:27]