| === alex3f is now known as alex3f|kss | ||
| pitti | Bonjour | 03:36 |
|---|---|---|
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | pitti, hi | 06:42 |
| pitti | hey tkamppeter | 06:42 |
| tkamppeter | pitti, thank you for your mail. I am trying to make your example a separate program now, but it seems that the added "import sys" breaks the PackageKit stuff. | 06:44 |
| pitti | uh, how? | 06:44 |
| pitti | "import sys" should be absolutely harmless | 06:44 |
| tkamppeter | pitti, this is the program: http://paste.ubuntu.com/1162166/ | 06:45 |
| pitti | how do you call it and how does it fail? | 06:46 |
| tkamppeter | pitti, and this is what happens: http://paste.ubuntu.com/1162169/ | 06:46 |
| pitti | erk, DOS line endings | 06:49 |
| tkamppeter | pitti, where? | 06:50 |
| pitti | (no worries, presumably just fallout from the pastebin download) | 06:50 |
| pitti | tkamppeter: hm, this script works fine here | 06:50 |
| pitti | with the same command as you have | 06:51 |
| pitti | tkamppeter: does the key appear in "apt-key list"? | 06:52 |
| pitti | it seems it already failed at this stage | 06:52 |
| tkamppeter | pitti, for m,e this script does not work as shown, your original script works, and your original script with only "import sys" added at the beginning shows the same problem. I am on Quantal. | 06:52 |
| pitti | if "import sys" is the only difference, this sounds like a red herring | 06:53 |
| pitti | perhaps it sometimes works and sometimes not, depending on your configured GPG server? | 06:53 |
| tkamppeter | pitti, the key appears. | 06:53 |
| pitti | tkamppeter: if you run the script again, how far does it get? | 06:54 |
| pitti | exact same output, or slightly different? | 06:54 |
| tkamppeter | pitti, now the original script also shows the problem, without "import sys". | 06:55 |
| pitti | oh | 06:57 |
| pitti | perhaps it fails if the key is already present? | 06:57 |
| tkamppeter | pitti, I have already done more than one successful run with the same key. | 06:59 |
| tkamppeter | pitti, you have tested my script, can you run it again? | 06:59 |
| pitti | yes, I do; works fine here | 07:00 |
| pitti | I ran it four times up to after enabling the repo (which is further than it got for you) | 07:01 |
| pitti | tkamppeter: your pastebin, is that the full output, or only the tail? | 07:02 |
| pitti | oh, hang on, I have another idea | 07:03 |
| tkamppeter | pitti, my pastebin is the full output. | 07:03 |
| pitti | tkamppeter: I think the problem is in the progress() callback when it tries to display progress.props.package_id | 07:03 |
| pitti | tkamppeter: if you drop this part from progress(), does it work? 'package:', progress.props.package_id, | 07:04 |
| tkamppeter | pitti, I added "return" as the first line of progress() now (not showing progress info at all) and the problem still persists. | 07:05 |
| pitti | tkamppeter: do you have "packagekit" installed? | 07:06 |
| pitti | tkamppeter: I don't, I'm using python3-aptdaemon.pkcompat, which we install by default | 07:06 |
| pitti | tkamppeter: (we do not really support the real packagekit) | 07:07 |
| pitti | that might explain the difference, there might be a bug in this part of PackageKit | 07:07 |
| tkamppeter | pitti, here is what I have installed: http://pastebin.ubuntu.com/1162192/ | 07:11 |
| pitti | tkamppeter: ah, that explains it; so, we might fix this bug in PK, but it's not time critical; please install python3-aptdaemon.pkcompat (this will remove packagekit) | 07:12 |
| pitti | this might also explain some failures that you got with codec installs | 07:12 |
| pitti | we only test our stuff with aptdaemon usually | 07:13 |
| tkamppeter | pitti, now it works again. thanks. But now a new problem occurs: I have run the script two times in a row, entering the password in both runs, and on the second run (with the package already installed) I get a segfault. It should fail gracefully then. | 07:19 |
| pitti | uh, a segfault sounds bad -- this is all python | 07:21 |
| pitti | but yes, this is by no means a finished script -- it does not do any such checks | 07:21 |
| tkamppeter | pitti, it seems that the library function to handle failure has a bug here, and as failure cannot only happen by duplicate installation this would be a stopper for this method. | 07:26 |
| pitti | I ran it wice with picsaw, I can reproduce the bug | 07:30 |
| tkamppeter | pitti, I tried another failure, trying to load a non-existing package, it does not give a segfault, but a traceback, so failures without triggereing apport are not possible with this script. | 07:30 |
| pitti | well, the latter is no problem, the script can try: / exec GLib.GError: | 07:30 |
| pitti | at the moment it does not do any error checking | 07:30 |
| pitti | (process:21062): PackageKit-WARNING **: couldn't parse execption 'GDBus.Error:org.debian.apt.TransactionFailed: error-package-already-installed: Package picsaw is already installed', please report | 07:31 |
| tkamppeter | pitti, so the segfault is the only thing preventing from using this method. | 07:31 |
| pitti | tkamppeter: I agree it should be fixed; but the script can check at the beginning if the package is already installed | 07:32 |
| pitti | you can also skip the "add repo" and "install repo key" steps if the package already resolves | 07:33 |
| * pitti adds a few tweaks to the script, hang on | 07:34 | |
| pitti | tkamppeter: ^ give me 5 minutes to add some checks | 07:34 |
| fredp | pitti: hi! about https://bugzilla.gnome.org/show_bug.cgi?id=434924 , are you confident enough to get this in 3.6? | 07:40 |
| ubot2` | Gnome bug 434924 in gobject "Add signal helper" [Enhancement,Assigned] | 07:40 |
| pitti | fredp: it's well testcase'd and does not affect existing API; but as it's an API addition it formally falls under feature and API freeze | 07:41 |
| pitti | and it's not really urgent, so I didn't start bothering the release team about it yet | 07:41 |
| fredp | pitti: Simon did :) it's still early in the freeze, I'll give it my +1, and I'm confident another one will be given. | 07:42 |
| pitti | fredp: ah, thanks! | 07:42 |
| seb128 | hey desktopers | 07:43 |
| seb128 | hey pitti, fredp | 07:43 |
| pitti | bonjour seb128, ça va? | 07:43 |
| fredp | 'lut seb128 | 07:44 |
| seb128 | pitti, ca va, un peu fatigué | 07:46 |
| seb128 | will be glad once the ff madness is over | 07:46 |
| pitti | heh | 07:46 |
| pitti | tkamppeter: there: http://people.canonical.com/~pitti/tmp/install-printerdriver | 07:46 |
| pitti | tkamppeter: this skips key/repo installation if the package is already available, and also skips installation if the package is installed | 07:46 |
| tkamppeter | pitti, works great, thanks. | 07:51 |
| dholbach | hi guys | 08:37 |
| dholbach | maybe somebody of you can comment on http://benjaminkerensa.com/2012/08/23/canonical-privacy-policy-for-zeitgeist-is-insufficient? | 08:38 |
| dholbach | just so this doesn't turn into a flamefest or complainfest | 08:38 |
| seb128 | dholbach, not really | 08:41 |
| seb128 | dholbach, hey btw | 08:41 |
| seb128 | dholbach, can you ping ev,mpt on #ubuntu-devel? that "send to canonical" is part of the whoopsie work | 08:41 |
| seb128 | dholbach, it's not something desktop is working, ev is dealing with that | 08:41 |
| seb128 | *working on | 08:42 |
| dholbach | seb128, thanks muchly | 08:43 |
| seb128 | dholbach, yw | 08:44 |
| dholbach | there's nothing like a bit of drama in the morning | 08:45 |
| seb128 | dholbach, is that your equivalent of reading people magasins? :p | 08:46 |
| seb128 | dholbach, like closer or whatever are famous (I mostly know the name of the french ones (gala, voici, ...) | 08:47 |
| dholbach | yeah, my grandma loves those - especially the stories about princes and princesses - I guess everybody gets their dose of drama elsewhere :) | 08:48 |
| seb128 | ;-) | 08:48 |
| xclaesse | I was wondering: what is keeping back gdm to 3.0 even in quantal? | 09:11 |
| seb128 | xclaesse, ricotz and jbicha didn't get the gsettings version to work properly, and most of the team focus on lightdm and nobody else stepped to work on gdm | 09:19 |
| xclaesse | seb128, ok fair enough :) | 09:29 |
| === MacSlow is now known as MacSlow|lunch | ||
| rodrigo_ | hi | 10:35 |
| rodrigo_ | does aptdaemon now implement the full PackageKit dbus interfaces (session and system)? | 10:35 |
| pitti | rodrigo_: mostly, yes; we have had the session one for quite a while (sesssioninstaller) | 10:51 |
| pitti | rodrigo_: and during quantal I did some work on the system one | 10:51 |
| pitti | for adding keys, repos, and the like (installing packages has worked for a while) | 10:51 |
| rodrigo_ | pitti, perfect, that's what I need :) | 10:53 |
| OwaisL | https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/733233/comments/35 | 11:21 |
| ubot2` | Ubuntu bug 733233 in light-themes "Increase shadow area to 45 pixels (but not grip area)" [Undecided,Fix released] | 11:21 |
| OwaisL | Any plans to implement this for Quantal now that Unity2d is not around anymore? | 11:22 |
| OwaisL | seb128, ^ | 11:24 |
| seb128 | dunno, ask smspillaz or Cimi | 11:24 |
| OwaisL | Ok, thanks! | 11:25 |
| === dholbach_ is now known as dholbach | ||
| === MacSlow|lunch is now known as MacSlow | ||
| tkamppeter | pitti, all is working now, the only thing which does not work is listing the newly added files of the package installation. PackageKit has a function for it but it simply does not work. Perhaps I am the first one trying to use it. | 12:06 |
| chrisccoulson | huh, the latest eds libraries don't contain a .gnu_debuglink section | 12:10 |
| chrisccoulson | that's meant to contain the filename for the debug symbols | 12:10 |
| chrisccoulson | i just noticed it because it breaks my breakpad symbols builder job | 12:11 |
| chrisccoulson | cyphermox_ ^^ | 12:11 |
| chrisccoulson | it also prevents gdb from automatically loading the symbols | 12:12 |
| pitti | tkamppeter: we can still add that to aptdaemon if required | 12:12 |
| tkamppeter | pitti, so it does not work because it is not implemented in aptdaemon? I need it, as this allows prioritizing the PPDs of the freshly installed package when setting up the printer. Please implement it in aptdaemon. | 12:15 |
| pitti | tkamppeter: can you please file a bug for it against aptdaemon and assign it to me? | 12:16 |
| pitti | tkamppeter: with some infos which method you called, etc. | 12:16 |
| pitti | tkamppeter: the get_files() call is implemented and supposed to work | 12:18 |
| tkamppeter | pitti, bug 1040619 | 12:21 |
| ubot2` | Launchpad bug 1040619 in cups "aptdaemon does not support listing the files of a package" [High,New] https://launchpad.net/bugs/1040619 | 12:21 |
| pitti | thanks, will look at it ASAP | 12:24 |
| pitti | mvo: I'd like to do another aptdaemon uplaod now to fix this ^, any reservations? | 12:45 |
| pitti | tkamppeter: fixed in trunk | 12:45 |
| mvo | pitti: not from me, I plan to work on a whitelist feature today but that will probably take a couple of hours before its ready | 12:46 |
| mvo | pitti: there is one branch pending though | 12:46 |
| mvo | pitti: that would be nice to get a review for | 12:46 |
| mvo | pitti: lp:~mvo/aptdaemon/support-change-credentials-on-add-repo and the one from steve, but I can look at the later too | 12:46 |
| pitti | well, it's not urgent from my side, not sure how urgent it is to tkamppeter | 12:46 |
| pitti | tkamppeter: you can also apply the patch locally for now | 12:46 |
| pitti | just apply the pkcompat.py part in http://bazaar.launchpad.net/~aptdaemon-developers/aptdaemon/main/revision/853 to your /usr/lib/python3/dist-packages/aptdaemon/pkcompat.py | 12:47 |
| pitti | tkamppeter: ^ with this you can go ahead immediately without being blocked on an upload or package build, etc. | 12:47 |
| pitti | mvo: ^ I guess that's even faster :) | 12:47 |
| chrisccoulson | fantastic. the eds binaries from a local build are correct | 13:02 |
| === Guest81255 is now known as jpds | ||
| === ken_ is now known as Guest96238 | ||
| jbicha | good morning | 13:23 |
| jbicha | I think I fixed the libsecret build but I need a sponsor http://people.ubuntu.com/~jbicha/libsecret/ | 13:25 |
| tkamppeter | pitti, manually applying your patch works, the files get listed now. Thank you for the quick fix. | 13:36 |
| seb128 | jbicha, thanks | 13:36 |
| seb128 | jbicha, uploaded, let's see if that works | 13:39 |
| desrt | seb128: so i wanted to harass you about ubuntu-control-center | 13:39 |
| seb128 | jbicha, you including the orig in the .changes, you shouldn't normally | 13:39 |
| desrt | wasn't that meant to be happening this cycle? | 13:39 |
| seb128 | included | 13:39 |
| seb128 | desrt, stay on 3.4 | 13:39 |
| seb128 | g-s-d as well | 13:39 |
| cyphermox_ | morning. | 13:39 |
| seb128 | nautilus as well | 13:39 |
| seb128 | desrt, "that" being? | 13:39 |
| desrt | seb128: the official forking | 13:40 |
| desrt | (and renaming) | 13:40 |
| desrt | (and returning of the original name to the unmodified upstream version) | 13:40 |
| seb128 | desrt, ask lars if he had time to work on their version :p | 13:40 |
| desrt | larsu: hey. seb said that you were going to solve all of my probles. is that true? | 13:40 |
| seb128 | desrt, olli said your team would take over that | 13:40 |
| desrt | oh. that's true. | 13:40 |
| * desrt seems to remember this on his birthday | 13:40 | |
| seb128 | ;-) | 13:41 |
| larsu | uhm. no! | 13:41 |
| larsu | :P | 13:41 |
| jbicha | seb128: oh, that's how most things need to be built | 13:47 |
| === ayan_ is now known as ayan | ||
| jbicha | xclaesse: we have a mostly working gdm now but it breaks locales, the keyring doesn't auto-unlock, & there may be a bug with plymouth | 13:51 |
| seb128 | jbicha, the orig tarball need to be uploaded only if launchpad doesn't have it already | 13:52 |
| xclaesse | jbicha, by curiosity (I'm happy with lighdm): is there someone working on fixing issues? | 13:52 |
| seb128 | so usually for -0ubuntu1 or -1 only | 13:52 |
| chrisccoulson | oh crap | 13:52 |
| chrisccoulson | bug 1040645 is "pkg-create-dbgsym creates broken symbols for packages using debhelper compat 9" | 13:53 |
| ubot2` | Launchpad bug 1040645 in evolution-data-server "eds binaries contain broken .gnu_debuglink section" [Medium,Triaged] https://launchpad.net/bugs/1040645 | 13:53 |
| jbicha | xclaesse: not really in that only a few people are aware of those bugs, maybe I'll push gdm to -proposed so that more people can look at it | 13:53 |
| ricotz | xclaesse, the problem is g-s 3.5.90 won't fully work without a running gdm | 13:55 |
| === cyphermox_ is now known as cyphermox | ||
| xclaesse | ricotz, hm, that's a bigger issue indeed | 13:56 |
| xclaesse | ricotz, so g-s package will depend on gdm and replace lighdm ? | 13:56 |
| xclaesse | and I guess g-s needs a newer gdm than 3.0? | 13:56 |
| jbicha | and I don't want to break gnomebuntu before our first alpha either | 13:56 |
| ricotz | xclaesse, it needs to depend on it yes | 13:56 |
| ricotz | xclaesse, and since it is a runtime dep some kind of check would be useful too, or even remove g-s session from lightdm | 13:57 |
| xclaesse | ricotz, jbicha: btw are you guys behind gnombuntu ? | 13:58 |
| seb128 | ricotz, why does it need gdm? | 13:58 |
| ricotz | seb128, gdm provides the dbus service which is mandatory for the g-s screenshield (lock-screen, ...) | 13:58 |
| xclaesse | (why would gnome need systemd... and still...) | 13:58 |
| xclaesse | but yeah, that makes sense IMO | 13:59 |
| ricotz | (it runs fine with consolekit) | 13:59 |
| seb128 | ricotz, so it's just for lock screen? | 13:59 |
| seb128 | ricotz, we could probably hack around and add a compat to gnome-screensaver | 13:59 |
| xclaesse | lighdm could provide the dbus service... I guess... | 13:59 |
| ricotz | seb128, and some session actions | 13:59 |
| seb128 | yeah, robert_ancell was talking about adding some gdm compat glue to lightdm | 14:00 |
| ricotz | seb128, i dont like the word "hack" | 14:00 |
| seb128 | he started looking at it at GUADEC | 14:00 |
| seb128 | ricotz, neither hacking or hackje | 14:00 |
| xclaesse | otoh, if we want gnome-shell we probably want a real gnome env, so getting latest gdm would be good anyway | 14:00 |
| seb128 | hacker | 14:00 |
| seb128 | ? | 14:00 |
| ricotz | seb128, but adding the org.gnome.displaymanager dbus interface to lightdm could work | 14:00 |
| seb128 | xclaesse, most people don't care about their init system or login manager (especially if they use autologin) | 14:00 |
| seb128 | xclaesse, they just want to get to their desktop | 14:01 |
| ricotz | seb128, i just meant "hack" in a lot of work which the team can't cope with | 14:01 |
| xclaesse | seb128, true | 14:01 |
| jbicha | I have a lot more confidence in lightdm than gdm (esp. on Ubuntu) so that would be great if robert could get lightdm to work with it | 14:02 |
| Sweetshark | seb128: LO build finished on all platforms for -proposed, can you dump in quantal main? | 14:22 |
| seb128 | Sweetshark, can do | 14:22 |
| Sweetshark | seb128: awesome, thanks! | 14:22 |
| seb128 | Sweetshark, copied | 14:39 |
| jasoncwarner_ | wow, anyone else with a x220/sandybridge get this? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1020733 making my system unstable right now...no idea how it happened | 14:46 |
| ubot2` | Ubuntu bug 1020733 in xserver-xorg-video-intel "[sandybridge-m-gt2+] GPU lockup IPEHR: 0x78170003" [Undecided,New] | 14:46 |
| jbicha | is the compiz gsettings switch scheduled for today? | 14:46 |
| mhall119 | kenvandine: ping | 14:47 |
| Guest96238 | mhall119, pong | 14:49 |
| mhall119 | Guest96238? | 14:49 |
| Guest96238 | oh... | 14:49 |
| === Guest96238 is now known as kenvandine | ||
| kenvandine | whew | 14:50 |
| kenvandine | mhall119, pong | 14:50 |
| mhall119 | kenvandine: I'm trying to get a list of "safe" dbus session services that apps can opt into without requiring a security review | 14:51 |
| mhall119 | kenvandine: I was hoping you'd know some that would almost always be needed, ones that could be needed and are safe, and ones that should require a review | 14:55 |
| kenvandine | not off hand | 14:57 |
| kenvandine | sorry | 14:57 |
| kenvandine | very distracted atm | 14:57 |
| mhall119 | kenvandine: stop looking at cats in boxes, there's work to do | 14:59 |
| kenvandine | haha | 14:59 |
| * kenvandine needs more of that :) | 14:59 | |
| mhall119 | kenvandine: do the com.Gwibber.* services let you send tweets without user approval? | 15:00 |
| kenvandine | yes | 15:01 |
| kenvandine | com.Gwibber.Service | 15:01 |
| mhall119 | how about just reading, is there a service that will give you read but not write? | 15:02 |
| pitti | bonne nuit, les filles et les garçons! | 15:23 |
| jbicha | seb128: for whoever uploads compiz, could you bump the minimum metacity build-depends for the soname transition? | 15:27 |
| chrisccoulson | oh, it's a public holiday on monday? | 15:27 |
| chrisccoulson | i nearly forgot! | 15:27 |
| seb128 | jbicha, what soname transition? | 15:29 |
| seb128 | jbicha, no, I've a week worth of work to land for tonight, I'm landing things in the state they are atm | 15:29 |
| jbicha | metacity switched from gconf to gsettings, Debian bumped the soname and added a breaks/replace against the old library | 15:35 |
| jbicha | Just bump the build-depends to libmetacity-dev (>= 1:2.34.3-3ubuntu1) and it will be fine | 15:36 |
| seb128 | jbicha, crap, I pushed without that, what happens if it build with the old one? | 15:38 |
| seb128 | jbicha, sorry I've like 5 discussions and people wanting things landing talking to me | 15:38 |
| jbicha | seb128: nothing, it will just need to get rebuilt | 15:39 |
| seb128 | jbicha, we didn't have that version, where are those changes come from? | 15:39 |
| jbicha | sorry, compiz is in main or I'd do it for you | 15:39 |
| seb128 | well, your upload will be in binNEW anyway I guess | 15:39 |
| seb128 | if there is a soname change | 15:40 |
| seb128 | we will land that later then and rebuild compiz | 15:40 |
| jbicha | seb128: ok, thanks! | 15:40 |
| seb128 | I need to get that compiz,unity on gsettings out | 15:40 |
| seb128 | there is another round of compiz,unity coming for gles then | 15:40 |
| seb128 | and then features | 15:40 |
| jbicha | the new compiz breaks the old metacity | 15:41 |
| jbicha | but sure | 15:41 |
| jbicha | bye for now | 15:42 |
| kenvandine | crap, evolution alarm notifier just told me i was supposed to be pilot yesterday | 16:03 |
| kenvandine | whoops | 16:03 |
| kenvandine | that would not have been a good day for it | 16:03 |
| seb128 | hehe | 16:05 |
| seb128 | kenvandine, today is a better day? :p | 16:05 |
| kenvandine | NO | 16:05 |
| chrisccoulson | bugger, i wish i hadn't restarted my session now. unity-panel-service is crashing constantly | 16:27 |
| kenvandine | chrisccoulson, mine too | 16:28 |
| kenvandine | using the ubuntu-desktop ppa? | 16:28 |
| chrisccoulson | kenvandine, ah, yeah, that might be it | 16:28 |
| kenvandine | larsu, ^^ | 16:28 |
| kenvandine | seb128, ^^ | 16:28 |
| seb128 | chrisccoulson, in some g_action_muxer function? | 16:29 |
| seb128 | chrisccoulson, kenvandine: can you try if https://launchpad.net/ubuntu/+source/indicator-appmenu/12.10.0-0ubuntu2 fixes it? | 16:30 |
| seb128 | it was segfaulting for me when nautilus was focussed before, that fixed it | 16:31 |
| kenvandine | i'll try in a few | 16:31 |
| larsu | argh, it's in the messagingmenu plugin | 16:35 |
| seb128 | larsu, ? | 16:36 |
| larsu | just tried it | 16:36 |
| larsu | don't have a good stacktrace yet | 16:36 |
| seb128 | larsu, tried what? | 16:36 |
| larsu | the ppa | 16:37 |
| larsu | what chris and ken were saying | 16:37 |
| seb128 | larsu, hum, try the indicator-appmenu update I pointed? | 16:37 |
| seb128 | larsu, are you sure it's not the issue I was complaining about and desrt fixed? | 16:37 |
| kenvandine | indicator-appmenu isn't built yet | 16:37 |
| kenvandine | just finishing | 16:38 |
| seb128 | kenvandine, the debs are on launchpad, wget and dpkg | 16:38 |
| kenvandine | amd64 wasn't done a few minutes ago | 16:38 |
| kenvandine | now they are there :) | 16:38 |
| seb128 | ok, I'm out for some exercice, I need that ;-) | 16:41 |
| seb128 | be back in ~1h | 16:41 |
| larsu | kenvandine, any news? | 16:55 |
| mterry | seb128, et al: nautilus 3.5.90.really.3.4.2 is in quantal-proposed | 16:55 |
| mterry | ah, just missed seb128 | 16:55 |
| larsu | he'll be back ;) | 16:55 |
| ogra_ | lovely version | 16:55 |
| cyphermox | is hicolor-icon-theme supposed to be empty except for directories? | 16:56 |
| kenvandine | larsu, just restarted | 16:56 |
| jbicha | mterry: :( | 16:57 |
| mterry | jbicha, I know. :( | 16:57 |
| larsu | my crash in the messaging menu was only because I didn't have the right gtk and glib | 16:57 |
| larsu | so maybe it's the one seb128 was talking about | 16:57 |
| kenvandine | larsu, no crash yet | 16:57 |
| * larsu should really keep track which terminal has which LD_LIBRARY_PATH | 16:58 | |
| mterry | jbicha, I like the look of the new one | 16:58 |
| ayan | all: i'm looking for the code that determines which options you have when right clicking on a device like an SD card reader. | 17:00 |
| ayan | for example, i have the option to eject an SD card -- which doesn't make sense for my reader. | 17:00 |
| ayan | i tried setting the udisks propery ID_DRIVE_EJECTABLE to 0 but the option to eject the SD card is still available. :( | 17:01 |
| dobey | ayan: the code with that string is i think in either glib, gtk+, or nautilus; but it's based on the 'removable' flag, i think | 17:07 |
| dobey | ayan: devices that are not 'removable' get 'Unmount' as the string, iirc. and removable devices get 'Eject' | 17:08 |
| ayan | dobey: thank you! now what determines if the device gives the option to 'safely remove' it? | 17:12 |
| kenvandine | seb128, that looks like it fixed the crash | 17:13 |
| kenvandine | thx | 17:13 |
| dobey | ayan: not sure, but that's an option you basically never want to use | 17:16 |
| dobey | ayan: 'safely remove' powers down the device, and you'll have to reboot to be able to insert another SD card for example | 17:16 |
| ayan | dobey: right. this is the case for some SD card readers. | 17:19 |
| ayan | dobey: so i'm trying to remove this option so that the device doesn't get powered down. | 17:19 |
| dobey | ayan: 'Eject' while it may seem nonsensical in many cases, is the correct option. it does do slightly more than 'Unmount' but doesn't power down the drive as 'Safely Remove' would | 17:22 |
| ayan | right -- i agree. but how does one completely remove the 'Safely Remove' option so that people don't power down their card reader? | 17:23 |
| dobey | 'Eject' does remove the drive from internal reference from the software (you have to pull it out and insert it again to re-mount), while Unmount will let you re-mount without removal | 17:23 |
| dobey | ayan: i am not sure. the code for that set of options is in one of the 3 places I looked. you'll have to find it, see what it's looking for, and tweak those flags in udev I guess | 17:24 |
| dobey | or perhaps just get it patched out. i can't really think of any time where that option is a good idea | 17:25 |
| ayan | well -- it depends on what it does. if safely removing a device powers it down -- then i'm not sure if that is the right thing. if safe removal means syncing/unmounting -- well that might be reasonable. | 17:26 |
| ayan | perhaps the meaning of safely remove should be dependant on some udev attributes. | 17:27 |
| ayan | but it doen't make sense to overload the term 'eject'. eject shouldn't be there unless my SD card will leap out of my computer when i select it. | 17:27 |
| seb128 | kenvandine, great! | 17:48 |
| seb128 | mterry, \o/ | 17:48 |
| mterry | seb128, try it out, let me know if anything is obviously broken (seems OK for me so far) | 17:48 |
| seb128 | mterry, ok, will do that after taking a shower (just back from exercice) | 17:50 |
| seb128 | mterry, thanks for working on that | 17:51 |
| mterry | k | 17:51 |
| mterry | np | 17:51 |
| * mterry logs out and back in | 17:51 | |
| seb128 | chrisccoulson, did that appmenu update fix your issue? | 17:53 |
| chrisccoulson | seb128, yeah, it's working fine now | 17:53 |
| chrisccoulson | thanks | 17:53 |
| seb128 | great | 17:53 |
| seb128 | yw | 17:53 |
| desrt | seb128: should i get ted to merge that code? | 17:57 |
| seb128 | desrt, well, I backported to fix to quantal so I'm not in an hurry, but it should be in the next tarball | 17:59 |
| desrt | thanks | 18:00 |
| desrt | seb128: uh... did you see the latest background panel? | 18:04 |
| desrt | is this a bug or is it actually supposed to look like that? | 18:04 |
| seb128 | desrt, screenshot? | 18:08 |
| seb128 | it didn't change since precise for me | 18:08 |
| desrt | oh. i'm on ricotz crack | 18:10 |
| desrt | you're probably not | 18:10 |
| desrt | ricotz: what's up with this? :) | 18:10 |
| seb128 | kenvandine, mterry, chrisccoulson, others: unity-compiz-gsettings stack in quantal-proposed | 18:11 |
| desrt | seb128: http://imgur.com/1F32M | 18:11 |
| seb128 | if you could upgrade and restart your session I would appreciate, first logging might be a bit slow but don't panic | 18:11 |
| mterry | kenvandine, chrisccoulson: and while we're testing proposed, also install nautilus and run it once for me! | 18:11 |
| seb128 | watch for migration issues (keybindings, unity settings, etc) | 18:11 |
| desrt | seb128: when you click on it, you get this: http://imgur.com/N5GwH | 18:12 |
| seb128 | desrt, seems like the new upstream design | 18:12 |
| * desrt loves minimalism, but seriously? | 18:12 | |
| seb128 | desrt, yeah, THEY MEAN IT ;-) | 18:13 |
| seb128 | desrt, I like the "test" in the mouse capplet as well | 18:14 |
| seb128 | you get the happy face stuff to click on full page | 18:14 |
| desrt | this is actually kinda cute :) | 18:14 |
| desrt | would be better if he was a little dude on the main page tho | 18:15 |
| ogra_ | seb128, yo ... lookin at some lubuntu image build failures today ... | 18:15 |
| ogra_ | ndicator-application-gtk2 : Depends: indicator-application (= 0.5.0-0ubuntu1) but it is not going to be installed | 18:15 |
| seb128 | yeah, the main page is a bit boring | 18:15 |
| ogra_ | are the gtk2 bits premanently gone ? | 18:15 |
| seb128 | ogra_, yes | 18:15 |
| ogra_ | who decided that ? | 18:15 |
| seb128 | ogra_, I announced it in june on -devel | 18:15 |
| seb128 | list | 18:16 |
| ogra_ | it will likely break the world for deriivatives | 18:16 |
| seb128 | ogra_, we said we would maintain gtk2 support until precise | 18:16 |
| ogra_ | ok | 18:16 |
| mhall119 | seb128: I'm trying to come up with a list of common dbus session services that are "safe" for applications to access, where "safe" means they can't do anything terrible to the user or the user's data by accessing them | 18:16 |
| seb128 | ogra_, the xubuntu guys agreed to bring back the ones they need in universe as separate sources | 18:16 |
| desrt | mhall119: i'd love to know what you're up to and to try to talk you out of it | 18:16 |
| ogra_ | seb128, ah, cool | 18:16 |
| mhall119 | I already have a list of the services used by Unity, are there any others you can think of that would fall under htat "safe" category? | 18:16 |
| ogra_ | thx ! | 18:16 |
| seb128 | desrt, likely giving a list of things possible for software-center appdev | 18:17 |
| desrt | ya. like partial sandboxing? | 18:17 |
| mhall119 | desrt: you can try ;) | 18:17 |
| seb128 | desrt, right, like "if you use a service out of those you will be rejected" | 18:17 |
| desrt | is this sandboxing or rather review checklist? | 18:17 |
| seb128 | desrt, until we get an efficient dbus sandboxing we can use I guess, at this point the sandbox will do it for you | 18:17 |
| mhall119 | yes, it's for sandboxing. Specifically we need a list of "pre-approved" things that your app can access | 18:18 |
| mhall119 | desrt: well, both possibly | 18:18 |
| desrt | mhall119: what of the filesystem? | 18:18 |
| seb128 | dinner, bbiab | 18:18 |
| mhall119 | desrt: I already have a list for the filesystem | 18:18 |
| desrt | mhall119: how do you plan to deal with shared libraries? | 18:18 |
| mhall119 | shared library code would run under the same apparmor restrictions as the app | 18:19 |
| desrt | ya. you're already entering into a world of pain, then | 18:19 |
| mhall119 | man, I've been there for weeks already ;) | 18:19 |
| desrt | i don't think that this is something that we can do mish-mash with a secondary solution like apparmor... | 18:20 |
| desrt | and we're going to feel a lot of pain for this. we already are. | 18:20 |
| mhall119 | I don't really care *how* it gets implemented | 18:20 |
| desrt | yes. you do. | 18:20 |
| mhall119 | whether it's apparmor, or built into the dbus daemon itself | 18:21 |
| desrt | because the proper way to do this is going to take more time than you probably have | 18:21 |
| mhall119 | I don't really have a deadline | 18:21 |
| desrt | okay. so we need to change the unix security model | 18:21 |
| jdstrand | desrt: what is secondary about this? we need to be able to say what an app is allowed to do and reject things outside of that? this is no different than other sandboxing solutions, like Apple's? | 18:21 |
| desrt | and get all of our upstream library developers to understand that we have done so | 18:21 |
| desrt | jdstrand: the problem is that libraries will do unexpected things | 18:21 |
| jdstrand | so? | 18:22 |
| desrt | we've seen all kinds of issues where we get apparmor rejecting apps for trying to write files to unexpected places | 18:22 |
| jbicha | seb128: the -proposed Unity is lagging really bad here | 18:22 |
| jdstrand | if it is unexpected it should be denied. if it is something the application expects, the profile will allow it | 18:22 |
| desrt | only to find out that it was actually a mundane (and completely necessary) part of the function of a shared library | 18:22 |
| jdstrand | desrt: that is a problem with the abstraction, not apparmor itself | 18:23 |
| desrt | which abstraction? | 18:23 |
| jdstrand | obviously, this whole exercise will help with our abstractions | 18:23 |
| jbicha | seb128: also, I believe we're ready for the compiz rebuild so that metacity isn't uninstallable | 18:23 |
| desrt | until apparmor grows the ability to consider use of a particular shared library as 'safe' then you have trouble | 18:23 |
| desrt | and i don't think that's very easy.... | 18:23 |
| mhall119 | desrt: presumably for things already in the archives they wouldn't be subject to this, just like how most apps in main/universe aren't subject to apparmor restrictions | 18:23 |
| jdstrand | whatever one is allowing the access or not allowing it, but it should | 18:23 |
| mterry | seb128, the proposed stack seems fine to me | 18:24 |
| mhall119 | desrt: yes, there will be a problem if a shared library needs to access a resource the app author doesn't realize it needs to access | 18:25 |
| desrt | mhall119: the problem is that the shared library can get an upgrade | 18:25 |
| mhall119 | but, that in and of itself is a problem, and one that can be fixed with awareness | 18:25 |
| desrt | mhall119: is that the appauthor's responsibility? | 18:25 |
| mhall119 | yup | 18:26 |
| mhall119 | IMO, anyway | 18:26 |
| desrt | it can also depend on the user's configuration | 18:26 |
| desrt | is that their responsibility as well? | 18:26 |
| mhall119 | how would it depend on the user's configuration? | 18:26 |
| desrt | so for example, depending on how the sysadmin has configured dconf, you can find reads or writes happening to completely arbitrary places in the filesystem | 18:26 |
| mhall119 | ok, so if somebody is tweaking their dconf storage location, stuff is probably going to break | 18:27 |
| mhall119 | how many users do that? | 18:27 |
| desrt | so we only support installing apps from the software centre if you don't have a corporate deployment? | 18:27 |
| desrt | mhall119: google, for example... | 18:28 |
| desrt | and this is just one library that i happen to know a bit about... | 18:28 |
| desrt | out of 100s | 18:28 |
| mhall119 | right, but google's custom Ubuntu configuration isn't really what I'm targetting here | 18:29 |
| jdstrand | desrt: mhall119 is talking about stuff being installed from software center | 18:29 |
| mhall119 | specifically stuff being installed from the Extras archive | 18:30 |
| * desrt can imagine that people working at companies might sometimes like to install things? | 18:30 | |
| jdstrand | desrt: not a locked down browser or something. ie, a developer uploads something to extras.ubuntu.com and it floats out to users. it is mandatory that it behave in certain ways and the sandbox will enforce that | 18:30 |
| mhall119 | desrt: if they're tweaking dconf configs, I would assume they have their own archive or some other custom solution, and won't be allowing Angry Birds downloads | 18:30 |
| jdstrand | there are lots of questions surrounding dconf and gsettings | 18:30 |
| desrt | corporate dconf usage != kiosk mode | 18:31 |
| jdstrand | and if the do allow angry birds downloads, they can adjust the abstractions to suit their needs | 18:31 |
| mhall119 | but at any rate, my task isn't to justify sandboxing, it's to determine which DBus services we should allow access to and which we shouldn't for a sandboxed, standalone desktop application | 18:31 |
| desrt | mhall119: so you already have trouble there | 18:31 |
| desrt | the same dbus service is responsible for allowing you to do relatively mundane things like session management but also to do things like reboot the computer without confirmation | 18:32 |
| jdstrand | that is where apparmor dbus mediation comes in. first identify the services, then the interfaces | 18:33 |
| mhall119 | ok, so we won't allow access to that service name, which ones can I safely give an app access to?> | 18:33 |
| desrt | mhall119: i'd say none is a good safe bet | 18:33 |
| desrt | people who write session dbus services don't write them to be robust against attack | 18:33 |
| mhall119 | btw, this doesn't have to be a comprehensive list, just something to get started with | 18:33 |
| desrt | i'm sure just about every 'safe' service is a potential vector | 18:33 |
| mhall119 | desrt: I'm not concerned about the possibility of bugs | 18:34 |
| desrt | wait | 18:34 |
| desrt | i thought we were talking about security? | 18:34 |
| jdstrand | that is definitely true, but enumerating them is a start | 18:34 |
| mhall119 | only whether doing what they are designed to do should be denied | 18:34 |
| jdstrand | and if there are security flaws in those services, they should be fixed | 18:34 |
| mhall119 | ^^ | 18:35 |
| desrt | they're not security flaws... | 18:35 |
| mhall119 | but if the intended use isn't safe, we can't expect that will be changed, so we souldn't allow it | 18:35 |
| * jdstrand -> call | 18:35 | |
| desrt | they're services written with the assumption that the thing calling them has the same privilege level | 18:35 |
| desrt | which is a true assumption | 18:35 |
| desrt | unless you plan to rewrite our entire platform... | 18:35 |
| mhall119 | desrt: ok, so under that assumption, what services should we let developers access without review? | 18:36 |
| desrt | none. | 18:36 |
| desrt | seriously. | 18:36 |
| mhall119 | I can't use that answer | 18:36 |
| desrt | you can't get security this way | 18:37 |
| mhall119 | org.freedesktop.Notifications is "safe", what's the worst an app can do with that (ignoring possible bugs)? | 18:37 |
| mhall119 | desrt: we currently have no restrictions and people adding every PPA ever mentioned on OMG!Ubuntu!, my goal is to be safer than that, which is a pretty low bar really | 18:37 |
| desrt | mhall119: you will only have success in preventing accidental mistakes | 18:38 |
| mhall119 | desrt: yes | 18:38 |
| mhall119 | that's all I need | 18:38 |
| desrt | all you'll do is get the attackers to step up their game | 18:39 |
| desrt | which will still be trivially easy | 18:39 |
| mhall119 | I'm not trying to stop attackers | 18:39 |
| mhall119 | I'm trying to give people an option to random PPAs | 18:39 |
| desrt | do we trust the random PPAs or not? | 18:39 |
| mhall119 | not at all, except that the source that was uploaded is what was built | 18:40 |
| desrt | because if we do, then no problem... and if we don't, this won't help | 18:40 |
| mhall119 | desrt: we're not going to let everybody use this process, they'll have to apply for access and be checked out by a person | 18:40 |
| mhall119 | unlike a PPA, which anybody with a Launchpad account and GPG key can use | 18:40 |
| desrt | i'm sorry to be a downer... but this 'plug a few holes here and there' approach to security really rubs me the wrong way | 18:40 |
| mhall119 | understood, and I'll plug as many as I can while still giving app developers and users a good experience | 18:41 |
| desrt | mhall119: mark my words: unless you're reviewing code, you will not have security until you adopt a radically different approach | 18:42 |
| desrt | looking at what google does on android (and making it suck less) is what i mean by radically different | 18:42 |
| mhall119 | desrt: that's what I'm working towards | 18:42 |
| mhall119 | and what jdstrand is working towards | 18:42 |
| desrt | mhall119: so why are you messing around with apparmor? | 18:42 |
| mhall119 | it's not going ot happen overnight and we know it | 18:43 |
| desrt | start hacking the kernel :) | 18:43 |
| mhall119 | because apparmor gives us 80% already | 18:43 |
| desrt | ... | 18:43 |
| desrt | this is what i'm trying to tell you | 18:43 |
| desrt | if you cover 80% of the holes, the attackers will be happy to use the other 20 | 18:43 |
| mhall119 | but that's still 80% more coverage than we have now, and doing nothing to help app developers isn't an option | 18:44 |
| mhall119 | better is still better | 18:44 |
| desrt | i really strongly disagree | 18:44 |
| desrt | fixing 80% of known security issues is just about as good as fixing 0% | 18:44 |
| desrt | unless you are on a path towards fixing 100% | 18:44 |
| desrt | which you're really not | 18:44 |
| mhall119 | and again, it's not my task to argue about whether or not we should have sandboxing, my task is to figure out what we can sandbox while making it work for app developers | 18:45 |
| JanC | I suppose apparmor & co could prevent 99.9999% or more of attacks, but doing that without hampering usability would be difficult... | 18:46 |
| mhall119 | JanC: yeah, we need to find a balance | 18:47 |
| mhall119 | too strict, and people will keep using PPAs | 18:47 |
| mhall119 | too loose and it won't be much better than PPAs | 18:47 |
| mhall119 | so, for example, Unity's apis run over dbus, and we should let desktop applications access them by default | 18:49 |
| JanC | not only Unity's APIs, but lots of other things in desktop applications need dbus | 18:51 |
| JanC | I guess at some point there could be a wizard that creates a profile that opens up holes in apparmor based on the features needed by a specific app, and the app reviewers would create the profile with it based on input from the app developer | 18:55 |
| jdstrand | JanC: so, there are definitely things that need to be addressed. for example, apparmor policy is static. so we have a confined application that uploads pictures to flickr. how will allow this? | 18:58 |
| jdstrand | we are thinking about these sorts of things | 18:58 |
| jdstrand | it would also be nice if when a user installs something from software center, they can look at the policy (sorta like on android), but be able to do more than just 'yes|no' | 18:59 |
| jdstrand | eg, 'yes I want to upload pictures, but no I don't need gps' | 18:59 |
| desrt | jdstrand: a good answer to this question is to forbid access to everything but have a service that the app can go through to say 'i want to open a file' | 18:59 |
| jdstrand | son't know what that will look like yet | 18:59 |
| desrt | the OS presents the open file dialog and only permits access to the file that the user selected | 19:00 |
| JanC | jdstrand: AFAIK (dis)allowing internet access is possible with apparmor, or did you think about restricting access to certain sites only? (not sure if the latter is possible, but I think not?) | 19:00 |
| jdstrand | desrt: yep. that is the plan. how it will be implemented has not been worked out | 19:00 |
| desrt | jdstrand: you'll need some kind of 'real' sandboxing in order to start talking about things like that being useful | 19:00 |
| desrt | ie: on the same order of uid separation | 19:00 |
| desrt | *as | 19:01 |
| jdstrand | JanC: apparmor is currently *very* coarse-grained on netowrking. basically can only go to the protocol. soon we should have bind() so we can say which port. eventually we'd like to use secmark so we can do things like 'allow access to flickr.com' | 19:01 |
| desrt | jdstrand: a reasonable approach there is to shut everything down and force the app through a proxyserver | 19:02 |
| jdstrand | desrt: uid separation is likely part of the answer, especially for things like gnome-keyring and online-accounts, etc | 19:02 |
| JanC | that would be nice, as long as flickr.com only uses flickr.com and doesn't change the domains it uses ;) | 19:02 |
| jdstrand | JanC: indeed. but the nice thing about this is that the developer isn't bottlenecked. if her app breaks, they can fix it, upload and then the user can get it. if the perms change, the ui should refelect that | 19:03 |
| JanC | I guess that means apps should be able to check if a new version is available when things break like that | 19:04 |
| * desrt wonders what happens when flickr.com starts resolving to 192.168.1.1 and people start trying to upload pictures to http://flickr.com/?reboot-my-router-please ;) | 19:04 | |
| jdstrand | desrt: there is definitely a lot that could be done. I would argue that apparmor is real sandboxing-- it is root strong, etc. however, as you pointed out, we need to be aware of things like applications assuming that because they are in the same user context, everything is ok | 19:04 |
| desrt | jdstrand: my main beef with apparmor is that it's not part of the OS | 19:05 |
| jono | desrt, to be clear, the goal here is to provide assurances around security, efficiency and user experience | 19:05 |
| jono | right now getting apps into Ubuntu is a nightmare | 19:05 |
| jdstrand | for example, we would say 'no' to anything trying to talk to evolution-data-server | 19:05 |
| desrt | and by 'the OS' i mean 'the thing that the developers were writing their software for' | 19:05 |
| jono | (for normal app devs) | 19:05 |
| jono | desrt, this is the start of a long journey :-) | 19:06 |
| jdstrand | the app would need to use the api for choosing contacts (ie, akin to the privileged file chooser) | 19:06 |
| jono | jdstrand, agreed | 19:06 |
| desrt | jono: i think you're buying yourself into a false-advertising problem | 19:06 |
| jono | desrt, how so? | 19:06 |
| jdstrand | and that api would likely be over a dbus service that the app is allowed to talk to | 19:06 |
| jdstrand | but that prompts the user | 19:06 |
| desrt | we're going to tell users that it's safe to install stuff from these untrusted sources? | 19:06 |
| desrt | because it won't be.... | 19:07 |
| JanC | also, there are lots of ways to hijack a user's account/password, as long as you have write access to their $HOME... | 19:07 |
| jdstrand | desrt: which is basically your proxy approach | 19:07 |
| desrt | jdstrand: the proxy approach is good | 19:07 |
| jono | desrt, we need to make a good determination of what we define as "safe" - and this is where jdstrand is focusing his efforts | 19:07 |
| desrt | as far as i'm concerned, from a security standpoint you need to do only two things | 19:07 |
| jono | desrt, how would you solve this problem with limited developer resources? | 19:07 |
| desrt | 0) remove all access to absolutely everything | 19:08 |
| desrt | 1) add back access to things that are needed, but only via interfaces that were designed to handle hostility | 19:08 |
| jono | desrt, so basically your suggestion is a single proxy API for everything on the system? | 19:08 |
| JanC | that's basically how Java works | 19:08 |
| desrt | jono: i don't think it can be done with limited developer resources without seriously impacting what can be done as an app | 19:08 |
| jdstrand | well, to be fair, mhall119 is identifying what is there, then the security team will determine what is 'safe'. it might be very little... but if it is called 'safe', we should make sure that the application isn't making too many assumptions on what is connecting to it | 19:08 |
| desrt | jono: reviews are a good approach | 19:09 |
| desrt | doesn't scale, of course... and reviewers make mistakes | 19:09 |
| jono | desrt, reviews of what? | 19:09 |
| jono | code reviews? | 19:09 |
| desrt | yes | 19:09 |
| jono | we have already tried this with the ARB and it doesnt scale at all | 19:09 |
| desrt | makes sense | 19:09 |
| jono | so that is not an option | 19:09 |
| jdstrand | desrt: your '0' and '1' are consistent with what we are thinking about | 19:09 |
| desrt | jdstrand: the problem is that shared libraries are an interface | 19:09 |
| desrt | jdstrand: and you didn't cut off access to those | 19:10 |
| jono | desrt, we are certainly open to options, but we feel sandboxing and provide a safe upload pipeline is the best approach | 19:10 |
| desrt | jono: i agree what what you said, but what you're doing isn't sandboxing | 19:10 |
| jdstrand | desrt: but in practice, that is not a problem. that is just something that the application happens to do and need access to | 19:10 |
| JanC | desrt: there are ways to "firewall" shared libraries | 19:10 |
| jdstrand | it is part of the confinement policy | 19:10 |
| jono | desrt, do you have a better suggestion given our resource constraints? | 19:10 |
| desrt | it's letting the app into the cockpit with a few "don't touch that" stickers placed over top of particularly important controls | 19:10 |
| JanC | but it's very difficult | 19:10 |
| desrt | jono: no. | 19:10 |
| jdstrand | the more we confine, the more we'll see what we need to allow, address, etc | 19:10 |
| desrt | jono: it's a shitty situation | 19:11 |
| jono | desrt, indeed | 19:11 |
| jono | we would rather do *something* than nothing | 19:11 |
| desrt | jono: my only suggestion is that we don't mislead our users into believing that they have any kind of security at all from this approach | 19:11 |
| jono | admittedly, there is lots to do | 19:11 |
| jdstrand | desrt: actually, I think you are making an assumption on the policy. it isn't a blacklist, we are whitelisting | 19:11 |
| jono | desrt, I agree we need to define realistic expectations | 19:11 |
| jdstrand | we are taking the stance that nothing should be allowed, except for certain things that are considered safe | 19:11 |
| desrt | jdstrand: i understand that you're whitelisting... that's why my earlier comments about how libraries are going to be very unhappy. | 19:12 |
| desrt | and that goes to my point about getting security into the OS | 19:12 |
| jdstrand | eg, no writes to $HOME except in predifined, application specific areas. if they need more than that, there needs to be an api | 19:12 |
| desrt | if apparmor was part of the OS that library developers were writing against, then they would know about it and expect to have to deal with it | 19:12 |
| desrt | it isn't, and they don't | 19:12 |
| jdstrand | desrt: except that people targeting Ubuntu apps in extras *will* be aware of it | 19:13 |
| jdstrand | desrt: it will be mandatory | 19:13 |
| desrt | jdstrand: _libraries_ | 19:13 |
| jdstrand | I get that, but in practice, that isn't a problem | 19:13 |
| jono | I still don't understand what the issue is with libs? | 19:13 |
| desrt | i just gave you a very real example that i've wasted a lot of time on in the past | 19:13 |
| kenvandine | mterry, unity-scope-gdocs added to MIR bug 1029549 | 19:13 |
| ubot2` | Launchpad bug 1029549 in gnome-control-center-signon "[MIR] online-accounts and friends" [High,Fix released] https://launchpad.net/bugs/1029549 | 19:13 |
| jdstrand | the devloper will see the stuff that the libraries he is using is accessing | 19:13 |
| desrt | jono: libraries were written to run on posix/linux | 19:13 |
| desrt | jono: ubuntu-under-apparmor is a totally different beast | 19:14 |
| jdstrand | and make adjustments or refine policy or file a bug against our abstractions, policy groups, templates, whatever | 19:14 |
| desrt | jono: which is sort of the issue here.... | 19:14 |
| desrt | if we make it too similar to what we already have then we have no real security | 19:14 |
| desrt | and if we make it too different then we get false positives everywhere and have destroyed our developer experience | 19:14 |
| jdstrand | I have done a lot of profiling over the years. Everything I profile uses libraries. it isn't an unsolvable or particularly painful problem | 19:14 |
| desrt | so we have to strike a balance.... but with security there is no balance | 19:15 |
| jono | so the issue is that the direct shared lib exposes one set of functionality but the apparmor exposes shared lib exposes a different set of functionality? | 19:15 |
| desrt | as long as you have one hole, it will be the one that the attackers use | 19:15 |
| jdstrand | heck, we can even change the library to not do it if we don't like. it's just code :) | 19:15 |
| desrt | jono: the problem is this: | 19:15 |
| desrt | we generally trust that gtk is good software, right? | 19:15 |
| desrt | we generally expect that if gtk wants to do something then it has good intentions... | 19:15 |
| jono | desrt, I don't necessarily agree that if there is any security hole the whole system is insecure | 19:15 |
| jono | desrt, right | 19:16 |
| * mterry shakes his fist at kenvandine | 19:16 | |
| desrt | the trouble is that apparmor can't tell the difference between gtk and an app using gtk | 19:16 |
| JanC | that depends on the security hole | 19:16 |
| desrt | it's just one process | 19:16 |
| jono | JanC, agreed :-) | 19:16 |
| kenvandine | mterry, this should be my last one... for online accounts that is ;) | 19:16 |
| desrt | and that's pretty sane -- with C, the app could have patched gtk's code in the live process image | 19:16 |
| jono | desrt, ok | 19:16 |
| desrt | the trouble is, gtk is a big complicated system | 19:16 |
| desrt | and application authors don't (and shouldn't have to) know how it works | 19:16 |
| JanC | but hackers tend to to abuse security holes way beyond what they seem to be... | 19:17 |
| seb128 | kenvandine, you know that saying that makes you need to buy a beer for eventual further coming one right? | 19:17 |
| desrt | so we have the app list all of the things it will ever want to do in the security profile | 19:17 |
| kenvandine | seb128, i qualified it with for online accounts :) | 19:17 |
| JanC | and often security breaches are based on a combination of security holes | 19:17 |
| desrt | but how does it know what gtk will want to do on its behalf? it doesn't. | 19:17 |
| * kenvandine extends that... for online accounts in 12.10 :) | 19:17 | |
| desrt | and we see annoying bugs like this all the time, even already... | 19:17 |
| jono | desrt, so the concern is a comprimised GTK? | 19:17 |
| desrt | we had some apparmor applied to telepathy and it was causing all kinds of trouble with dconf, for example | 19:17 |
| seb128 | kenvandine, ;-) | 19:17 |
| seb128 | mterry, thanks | 19:17 |
| seb128 | jbicha, how lagging? | 19:18 |
| desrt | jono: well... the library is on the disk and it's writable only to root | 19:18 |
| kenvandine | mterry, thx! | 19:18 |
| desrt | there's no worries about that | 19:18 |
| desrt | jono: but when a library gets loaded into a process, it's basically just a copy | 19:18 |
| jdstrand | those bugs may be annoying, but we fix them | 19:18 |
| desrt | (strictly speaking it's cow, but that's just an optimisation) | 19:18 |
| * kenvandine goes to get a sandwich | 19:18 | |
| jono | desrt, so the concern is in-process modification of the library | 19:18 |
| desrt | jono: well | 19:18 |
| desrt | jono: that's the argument for why we can't trust calls from GTK | 19:19 |
| jdstrand | the same way an application developer will fix them and upload so users can benefit | 19:19 |
| desrt | because we don't really know that they're coming from GTK | 19:19 |
| desrt | the only reasonable thing to do is to assume that a process can be controlled by anything inside of that process | 19:19 |
| jono | desrt, but surely this means all shared libs are flawed | 19:19 |
| desrt | jono: it means that one drop of untrustworthy code in a process makes the entire process untrustworthy | 19:19 |
| jono | desrt, right | 19:19 |
| desrt | and indeed, that's the model that apparmor follows | 19:19 |
| desrt | it's really the only sane model | 19:19 |
| jdstrand | but the confinement policy would block that | 19:19 |
| mterry | kenvandine, python3, not python2, man! | 19:20 |
| desrt | seb128: do you remember the apparmor/telepathy/dconf bug? | 19:20 |
| seb128 | desrt, yes | 19:20 |
| desrt | got a reference? | 19:20 |
| * jdstrand remembers fixing a bunch of telepathy bugs :) | 19:20 | |
| desrt | jono: so take something like dconf... | 19:20 |
| desrt | jono: it has highly variable behaviour in a variety of situations | 19:21 |
| jono | right | 19:21 |
| desrt | and we can't trust it any more than we can trust the app itself (for the reason mentioned above) | 19:21 |
| jdstrand | desrt: fwiw, dconf is something that has been identified as an area that the confinement needs to properly address | 19:21 |
| desrt | someone wrote a perfectly reasonable security policy saying that telepathy should not be creating files at random places in the user's home directory | 19:21 |
| desrt | since it's just a network service... | 19:21 |
| desrt | but the first time dconf is started, it creates an IPC socket in the user's home directory | 19:22 |
| jono | right | 19:22 |
| desrt | this was never noticed as being a problem because usually in the normal case the first program running dconf on a system is unity or something | 19:22 |
| desrt | but KDE users were suddenly getting screwed by this weird telepathy bug | 19:22 |
| desrt | because in that case the first dconf-using process was telepathy (under apparmor) and it would be the one to try to create the file | 19:22 |
| JanC | there are lots of issues here, of course, e.g. how do you confine a text editor? there is no way you can disallow it to edit any files in $HOME & elsewhere without disappointing its users? | 19:23 |
| jbicha | hmm, maybe it was LibreOffice that was causing me trouble... | 19:23 |
| seb128 | desrt, I don't have it, could be https://bugs.launchpad.net/ubuntu/+source/telepathy-mission-control-5/+bug/932626 | 19:23 |
| ubot2` | Ubuntu bug 932626 in telepathy-mission-control-5 "mission-control-5 crashed due to lack of user-tmp apparmor abstraction" [Undecided,Fix released] | 19:23 |
| jdstrand | JanC: you can, but you need to have it use a trusted file chooser | 19:23 |
| seb128 | desrt, if that's not this one I don't have it ;-) | 19:23 |
| jdstrand | (which has been identified as something that needs to be implemented) | 19:23 |
| desrt | seb128: no. i think it was a different bug | 19:24 |
| desrt | thanks for trying, though :) | 19:24 |
| jdstrand | seb128, desrt: no need to look for them-- I fixed something like 10 last cycle :P | 19:24 |
| seb128 | desrt, yw | 19:24 |
| desrt | jdstrand: so you know better than anyone that these issues will pop up everywhere | 19:24 |
| jdstrand | I do | 19:24 |
| kenvandine | mterry, yeah! | 19:24 |
| desrt | and the more exceptions we make, the less effective security we actually have | 19:24 |
| desrt | because now all i have to do is attack the system in a way that looks like dconf trying to open an IPC socket and i'm fine | 19:25 |
| jdstrand | desrt: no doubt | 19:25 |
| desrt | or any of the other 10+ exceptions | 19:25 |
| desrt | (just from last cycle...) | 19:25 |
| desrt | so ya... we'll block a lot of really obvious surface area | 19:25 |
| jdstrand | but there are a lot of differences here | 19:25 |
| mhall119 | desrt: so I understand, Empathy was the first to start Telepathy, so the Telepathy daemon was running under Empathy's AppArmor restrictions? | 19:25 |
| JanC | jdstrand: even a "trusted file chooser" would not be 100% safe | 19:25 |
| jono | desrt, but given our limited engineering resources, it might be better to resolve those exceptions than fundamentally change how Linux works | 19:25 |
| desrt | but if our goal is to keep potential attackers away from our users, the attackers will just switch from the obvious cases to the really malicious behaviour | 19:26 |
| jdstrand | mhall119: no-- empathy is not confined. telepaty-mission-control-5 is | 19:26 |
| mhall119 | jdstrand: oh, what is that? | 19:26 |
| desrt | mhall119: i don't think apparmor restrictions cross the bus | 19:26 |
| jdstrand | JanC: it is safe enough, because it requires the user to approve it | 19:26 |
| mhall119 | desrt: neither did I | 19:26 |
| desrt | which is sort of part of why this whole dbus thing scares the heck out of me | 19:26 |
| jono | desrt, but surely we face that issue with any security system, attackers will seek to find their way around it | 19:26 |
| desrt | jono: right... but in the case of apparmor we know we're only covering 80% surface area | 19:26 |
| JanC | jdstrand: it could still write data to that file behind the user's back... | 19:26 |
| desrt | jono: because covering 100% would make the system unusable | 19:27 |
| jono | desrt, right | 19:27 |
| desrt | so people _will_ poke the exposed 20% | 19:27 |
| jdstrand | mhall119: something that empathy uses. think of empathy as being broken into to parts-- the gui, and the stuff that does all the messaging | 19:27 |
| desrt | if that's what they're trying to do | 19:27 |
| jono | so it sounds like apparmor is basically our best option, but is not as secure as we would like, because full security is an unusable rock of a system | 19:27 |
| jdstrand | mhall119: we dealt witht he latter, since it processes network traffic | 19:27 |
| mhall119 | jdstrand: right, I understand the general concept of the telepathy libs | 19:27 |
| desrt | jono: full security is possible with much more engineering resources. put that aside. | 19:28 |
| jdstrand | JanC: yes, but you explicitly said that it could write to that file | 19:28 |
| mhall119 | jdstrand: I don't understand what happened with the IPC file and apparmor | 19:28 |
| desrt | jono: in the meantime i think that using apparmor is at best a waste of time and at worst a form of false advertising | 19:28 |
| jdstrand | sure, it could write gibberish | 19:28 |
| JanC | jdstrand: that doesn't make it safe ;) | 19:28 |
| desrt | jono: at least using it in this way.... | 19:28 |
| mhall119 | JanC: but it does make it your fault | 19:28 |
| jono | desrt, is there any other option other than full engineering resources and changing how the OS works? | 19:28 |
| jono | is there a "middle" option? | 19:28 |
| desrt | jono: systems like selinux and apparmor are designed to foil attacks against otherwise already-secure systems | 19:28 |
| JanC | mhall119: it's always the user's fault :p | 19:29 |
| desrt | like if i have some very specific bug in my parser that can be used to write a file to somewhere, for example | 19:29 |
| jdstrand | JanC: if you don't trust the code enough to write the file in the manner you said to, don't run it. if it is found to do this intentionally, the developer will get revoke | 19:29 |
| desrt | if i have a restriction to prevent writing files, i'm saved | 19:29 |
| jdstrand | d | 19:29 |
| desrt | but when the programmer has full ability to do any crafty thing they like, they'll find a way to break out | 19:29 |
| mhall119 | jdstrand: so I still don't understand what happened with empathy/telepathy/apparmor that caused a problem | 19:29 |
| desrt | jono: no... i don't think so. | 19:29 |
| jono | desrt, gotcha | 19:29 |
| desrt | jono: but meanwhile i wouldn't be putting resources on this option... | 19:29 |
| jono | unfortunately I need to grab lunch before a meeting, thanks for the input | 19:30 |
| jono | desrt, so what are we supposed to do? | 19:30 |
| JanC | jdstrand: what you are describing is how most Windows trojans infect machines: people install them and they abuse security holes to gain further access | 19:30 |
| desrt | doing 'the real deal' would be pretty exciting, i think | 19:30 |
| desrt | but short of that, just be honest with out users | 19:30 |
| desrt | *our users | 19:30 |
| JanC | yes, it's ultimately the user's fault | 19:30 |
| jono | if this solution is not an option, the 100% solution needs too many resources? | 19:30 |
| JanC | but they don't know any better | 19:30 |
| jdstrand | mhall119: empathy doesn't create the socket, mission-control does. I don't remember this specific bug, but I'm thinking it could read from it, but not write to it. you need 'w' to 'c' | 19:30 |
| desrt | 'installing this could massively mess up your system. are you sure you trust the person who wrote it?' | 19:30 |
| desrt | mix that with code reviews to the best of our abilities | 19:31 |
| jono | desrt, right, so you would be supportive so long as the messaging makes it clear that a level of risk is present | 19:31 |
| jdstrand | JanC: this isn't a security hole. you have an editor. you tell it to "edit this". it does so | 19:31 |
| desrt | and a big 'report malicious software' button with quick pull-downs | 19:31 |
| mhall119 | ok, so mission-control was running under an AppArmor profile that wasn't allowed to write to the IPC file it needed to write to? | 19:31 |
| jono | instead of "this will work flawlessly, rock on" | 19:31 |
| jdstrand | mhall119: yes | 19:31 |
| jono | desrt, gotcha | 19:31 |
| desrt | jono: i still think it's a waste of resources :) | 19:31 |
| jdstrand | mhall119: more that one it needs to creat() | 19:31 |
| mhall119 | jdstrand: so then wouldn't it be a simple matter of adding a line to the apparmor profile allowing write access? | 19:31 |
| mhall119 | s/write/create/ | 19:32 |
| jdstrand | mhall119: it indeed was. and that opens a hole | 19:32 |
| mhall119 | to what? | 19:32 |
| jono | desrt, I think doing nothing is a waste of an opportunity :-) | 19:32 |
| desrt | (and it does somewhat hamper the app developer experience) | 19:32 |
| jono | we can't sit on our fingers and not solve this problem | 19:32 |
| desrt | jono: i think the wasted opportunity is not undertaking a project to do it 'the real way' | 19:32 |
| desrt | someone other than google is eventually gonna have to crack this nut | 19:32 |
| jono | desrt, we will have to agree to disagree :-) | 19:32 |
| mhall119 | desrt: is doing it 'the real way' a practical option? | 19:32 |
| JanC | jdstrand: it's still a security hole (even if it's smaller than if the application would be able to write to all files as-is) | 19:33 |
| desrt | mhall119: let's say i'd be happier taking the limited engineering resources available and putting them on a project to have 'the real way' ready in 2-3 years from now than i would to have some apparmor hacks done to be ready in 6 months | 19:33 |
| desrt | because at least we'd be having real progress | 19:33 |
| mterry | kenvandine, see comments in MIR bug | 19:33 |
| jdstrand | JanC: it is not something that can be protected against in general. that said, we can do certain things-- is this ascii? no? then reject | 19:34 |
| kenvandine | mterry, you looked at the wrong stuff man | 19:34 |
| kenvandine | :) | 19:34 |
| desrt | much better still if we have enough people to do it properly and on a reasonable timeline | 19:34 |
| mhall119 | desrt: and how many resources would it take to get it done in 2-3 years, realistically? | 19:34 |
| mterry | kenvandine, I just commented again | 19:34 |
| desrt | but if that's not possible, it's not | 19:34 |
| jono | desrt, we don't have the luxury of waiting 2 - 3 years in my mind | 19:34 |
| desrt | jono: is ubuntu going to be around in 2-3 years? | 19:34 |
| JanC | of course, we could disallow text editors editing any files outside ~/Documents and ~/Projects or something like that | 19:34 |
| jono | for Ubuntu to be able to compete with Windows / Mac, we need to offer a good solution | 19:34 |
| jono | desrt, I hope so :-) | 19:34 |
| desrt | jono: then we should probably start thinking about this at some point | 19:34 |
| JanC | but even that wouldn't be 100% safe ;) | 19:35 |
| jdstrand | JanC: I expect the trusted picker will do input validation. but bottom line, don't use a random file editor to edit your /etc/shadow file and then tell it that it is allowed to modify it. no sandboxing can know the intent at that level | 19:35 |
| mhall119 | jdstrand: I still don't understand what adding 'create' access to the IPC file for mission-control did to open security holes | 19:35 |
| kenvandine | mterry, njpatel wasn't in 0.2 | 19:35 |
| jono | desrt, right, but when you say "we" working on the solution, it basically equates to Canonical investing in this | 19:35 |
| * kenvandine looks at the other issue | 19:35 | |
| jono | and this is a significant amount of work | 19:35 |
| mterry | kenvandine, yup, just noticed that too. :-/ | 19:35 |
| mterry | kenvandine, the other is still there! | 19:35 |
| desrt | jono: yup... but right now canonical is investing in something that (in my opinion) offers very little improvement at all | 19:35 |
| jono | desrt, right, I guess we see things a little differently | 19:36 |
| desrt | could well be | 19:36 |
| desrt | i understand the highlevel goal here | 19:36 |
| desrt | easier for joe random programmer to get apps available to our users | 19:36 |
| desrt | that's really really important | 19:36 |
| jono | right | 19:36 |
| jdstrand | mhall119: apparmor doesn't (currently) mediate creat() on its own. 'w'rite allows a bunch of stuff like creat, append, truncate, etc. so now the telepathy profile has write on the dconf socket | 19:36 |
| desrt | but this isn't helping with that | 19:36 |
| jdstrand | mhall119: that is not ideal | 19:36 |
| jdstrand | but it is also a limitation of the *current* apparmor and confinement solutions we have | 19:37 |
| mhall119 | jdstrand: ah, I see now. | 19:37 |
| jdstrand | we want to address these sorts of things | 19:37 |
| mhall119 | jdstrand: but a fixable limitation, right? | 19:37 |
| jdstrand | (which is why that is on the checklist) | 19:37 |
| jdstrand | mhall119: not via apparmor alone, no | 19:37 |
| jdstrand | but there are thigns that can be done, to be sure | 19:37 |
| jono | desrt, but given the resource constraints we have, and given the high-level we are shooting for and jdstrand's assurances, it seems to me we can edge much closer to the goal with solution | 19:37 |
| mhall119 | jdstrand: why is that? because filesystems don't differentiate different kinds of "write"? | 19:37 |
| jono | and clearly set the expectations in our users | 19:37 |
| jono | anyway, I really must run | 19:38 |
| desrt | jono: enjoy :) | 19:38 |
| jono | thanks desrt for the input, was an interesting discussion :-) | 19:38 |
| jdstrand | mhall119: oh, we could have apparmor mediate creat(), absolutely. I'm not 100% sure that would have been enough for this bug | 19:38 |
| desrt | i'm happy to give it :) | 19:38 |
| jdstrand | mhall119: since, you know, I can't actually test it :) | 19:38 |
| mhall119 | jdstrand: right, right, I'm just trying to understand if this was a limitation in the implementation or in the design | 19:39 |
| jdstrand | the design of the gnome desktop is a an utter failure for application confinement | 19:39 |
| jdstrand | because everything is in the same user context | 19:39 |
| desrt | jdstrand: hey! we totally agree! | 19:39 |
| desrt | :) | 19:39 |
| jdstrand | (this is nothing against gnome per se, it wasn't part of their goals) | 19:40 |
| JanC | I think some basic sanity-cleaning would be useful to weed out scriptkiddies and the like, but it will never work against a dedicated team trying to attack Ubuntu users (such as the (alleged) US/Israeli team that attacked Iranian nuclear installations) | 19:40 |
| desrt | jdstrand: yup. 100% true. | 19:40 |
| mhall119 | jdstrand: right, but that's only a problem when two apps both expect to access the same thing, right? | 19:40 |
| mhall119 | like the telepathy IPC sockey | 19:41 |
| mhall119 | \socket | 19:41 |
| jdstrand | mhall119: so, we will have to figure out how to detangle gsettings, dbus, et al to have usable applications that can run well under confinement | 19:41 |
| desrt | let's talk about dconf | 19:41 |
| desrt | since i have a lot of interest in that | 19:41 |
| desrt | what do you have in mind? | 19:41 |
| mhall119 | jdstrand: right, but also keeping in mind that we're targetting stand-alone applications, not system services or things with a very inter-connected nature | 19:42 |
| jdstrand | mhall119: yes-- which is a very important distinction from telepathy's confinement | 19:42 |
| desrt | jdstrand: do we consider reading arbitrary dconf keys to be a security issue? | 19:42 |
| desrt | like, a lot of applications are storing things like email addresses and login information there (but not passwords, hopefully) | 19:43 |
| jdstrand | desrt: that is a good question | 19:43 |
| desrt | that's some kind of a not-totally-awful-but-potentially-annoying security breach | 19:43 |
| seb128 | mterry, nautilus 3.4 is (almost) all good for me | 19:43 |
| jdstrand | desrt: a simple approach would be to read from session dconf and write to separate dconf (or something along those lines) | 19:43 |
| jdstrand | desrt: but yeah- then they can see anything in there | 19:44 |
| desrt | jdstrand: so here's what i mean by app authors understanding the OS | 19:44 |
| desrt | i'm the upstream developer of dconf | 19:44 |
| seb128 | mterry, the (almost) is that apt-get install nautilus didn't bring the new-old nautilus-data and it was aborting on a gsettings schemas issue until I upgraded-dowgraded that binary, but I'm a weirdo for not doing full upgrades :p | 19:44 |
| desrt | i want you to come to me and say "we need to sandbox an app to only write to a specific subpath in dconf." | 19:44 |
| mhall119 | desrt: we need to sandbox an app to only read and write to a specific subpath in dconf | 19:45 |
| desrt | and i want to understand how your security system works and how i can make that possible for you | 19:45 |
| desrt | mhall119: read and write is much more interesting! | 19:45 |
| mhall119 | :) | 19:45 |
| JanC | ☺ | 19:45 |
| jdstrand | desrt: indeed. tbh, we haven't thought deeply about how to deal with dconf yet | 19:46 |
| desrt | so i think we want to have some sort of very small well-defined tunnel between apparmor-isolated dconf-using apps | 19:46 |
| desrt | and the "real world" | 19:46 |
| kenvandine | mterry, The desktop file is harmless, but I fixed it in unity-scope-gdocs=0.2-0ubuntu2 | 19:46 |
| desrt | so that the only thing dconf does, when inside of that tunnel, is to push requests out through it | 19:46 |
| jdstrand | desrt: we've mostly just identified it as problematic | 19:46 |
| desrt | and not touch other random things around | 19:46 |
| desrt | so like "uses dconf under path /x/y/z" would be a possible thing to put in the apparmor profile for the app | 19:47 |
| JanC | it might be difficult to restrict what keys to access too | 19:47 |
| jdstrand | desrt: how do you see that tunnel working, as a trusted dbus service? | 19:47 |
| desrt | JanC: leave that to me, the dconf developer! | 19:47 |
| desrt | jdstrand: maybe. | 19:47 |
| desrt | jdstrand: a pattern i see developing in my mind is more like this: | 19:47 |
| JanC | desrt: I mean, applications sometimes need to access keys that are not their "own" | 19:47 |
| jdstrand | desrt: yeah, so, have you seen the apparmor discussion from months ago on dbus integration? | 19:47 |
| desrt | (and again, it looks like a proxy, like all my other suggestions) | 19:47 |
| desrt | we have this two-process setup | 19:47 |
| desrt | one of them is the app that the user downloaded | 19:47 |
| desrt | the other is a services 'bridge' | 19:48 |
| desrt | it has all of the interaction with the OS | 19:48 |
| mhall119 | JanC: not very often, and we can probably make a white-list of "okay to read" keys, and reject everything else | 19:48 |
| desrt | libdconf would know that in the apparmor situation it should attempt to communicate with the bridge | 19:48 |
| desrt | rather than doing things for itself | 19:48 |
| desrt | since that's likely to cause trip-ups with apparmor | 19:48 |
| desrt | meanwhile we'd have a 'full' dconf running in the non-isolated bridge process | 19:48 |
| desrt | and it would be touching random files, etc.... but only subject to the user's configuration setup | 19:49 |
| desrt | which is safe because it only contains trusted code and it was written with security in mind | 19:49 |
| jdstrand | desrt: fyi, I asked jjohansen to come in since he is head apparmor developer | 19:49 |
| jdstrand | jjohansen: let me get the backscroll | 19:50 |
| desrt | the bridge could be a trusted dbus service (in which case it would act on behalf of all things in the session) or it could be a little private thing that talks to the app over a unix socket or something | 19:50 |
| jdstrand | jjohansen: http://paste.ubuntu.com/1163282/ | 19:51 |
| desrt | although i really think that letting things on dbus to begin with is a bad idea :) | 19:51 |
| jjohansen | alright /me is actually here now | 19:52 |
| jdstrand | desrt: the trick is that applications don't know that they are under confinement without modification, which is why dbus has selinux hooks (and eventually will have apparmor). libvirt is the same way. sounds like dconf would need to be similar. I'll let jjohansen comment further | 19:52 |
| jdstrand | jjohansen: you say the backscroll paste, no? | 19:53 |
| desrt | jdstrand: i think putting isolation hooks in dconf could be appropriate | 19:53 |
| desrt | jdstrand: and it completely goes toward what i way saying about library authors needing to be aware of the security system when they design their libraries -- not layering things on after the fact at the distro level | 19:53 |
| jdstrand | desrt: ok, for libdconf, certainly :) for glibc, less so :) | 19:54 |
| mhall119 | jdstrand: any chance you fan bring the lead dbus developer in there too? :) | 19:54 |
| desrt | ideally you're not calling anything 'controversial' on glibc | 19:54 |
| desrt | we have higher-level APIs for everything that you should want to do | 19:54 |
| desrt | and most of them have appropriate abstractions at which we could insert this stuff | 19:55 |
| jdstrand | desrt: you were talking from the perspective of libdconf, I was from glibc. we are on the same page now :) | 19:55 |
| mterry | kenvandine, ok | 19:55 |
| jdstrand | mhall119: that discussion started a while ago, we just need to pick it up again :) | 19:55 |
| desrt | mhall119: there is no lead dbus developer | 19:55 |
| === jibel__ is now known as jibel | ||
| mterry | seb128, I guess that's a problem that normal nautilus has even on normal upgrades... But I'm not worried about a partial upgrade issue | 19:56 |
| jdstrand | desrt: no, nothing controversial at all, just an anology to illuminate our points of view when we spoke earlier | 19:56 |
| desrt | mhall119: which is fine since it doesn't see a lot of changes these days :) | 19:56 |
| desrt | jdstrand: ok | 19:56 |
| mterry | seb128, if you're happy, can you promote as you see fit to quantal proper? | 19:56 |
| desrt | jdstrand: apparmor is probably a fine system if you're looking to police libc | 19:56 |
| jjohansen | well, it depends what you me by hooks in libdconf, I am not opposed to that but it should be restrictions an app can't by-pass by writing/injecting its own libdconf code | 19:56 |
| jdstrand | jjohansen tells me he is having an irc client issue | 19:56 |
| jdstrand | ah, there he is :) | 19:57 |
| desrt | jdstrand: but most application-interesting libraries are one hell of a lot more complicated | 19:57 |
| desrt | and even with glibc... once nss gets involved, who the hell knows anymore? | 19:57 |
| desrt | jjohansen: remember the good old says of setuid helpers? | 19:58 |
| desrt | *days | 19:58 |
| jjohansen | desrt: sure, the point being the trusted state has to be in a separate process, be it X, dbus etc that the app is a client of | 19:58 |
| jjohansen | desrt: yep :) | 19:58 |
| desrt | jjohansen: what i'm saying is that we should have some sort of trusted helper app that can do anything the user can normally do in their own session | 19:58 |
| jdstrand | desrt: sure. point is, some bits are more painful than others. we are trying to identify the most painful and going down from there (dbus and dconf are among the most painful otoh (not to mention gnome-keyring)) | 19:58 |
| desrt | and we should allow apparmor'd apps to communicate with this helper | 19:58 |
| desrt | to do things like read dconf keys | 19:58 |
| desrt | the helper would enforce policy | 19:59 |
| desrt | this is also the natural place that you'd implement the "show the user an open file dialog and give me the result of that" thing | 19:59 |
| desrt | as well as about 100 other things you might want to do | 19:59 |
| desrt | as the author of dconf i'd probably look at just making my own helper | 19:59 |
| desrt | but if you tell me that your security system already has this construct, i'd try to use it | 20:00 |
| desrt | as not to have my own separate process (and we end up having 100 of them) | 20:00 |
| jjohansen | desrt: sure, but it would be nice to have that policy in one place, this is how dbus apparmor works. The policy is in apparmor but the dbus daemon is enforcing it. And if dbus moves to af_dbus then apparmor kernel module would enforce it | 20:00 |
| desrt | jjohansen: what i'm trying to get at is that you need to police the application to the interface | 20:00 |
| desrt | and dbus is not it | 20:01 |
| desrt | *interface to the application, sorry | 20:01 |
| desrt | if i'm trying to do a notification, as an app | 20:01 |
| desrt | i'm not talking to dbus | 20:01 |
| desrt | i'm talking to libnotify | 20:01 |
| jjohansen | desrt: sure, and I completely understand that as an upstream you want this to be generic and not tied specifically to apparmor | 20:01 |
| desrt | i don't care if it's apparmor or not | 20:02 |
| desrt | i'd be happy to have it tied to apparmor | 20:02 |
| desrt | (although i'd be happier with that if apparmor were used by more than us) | 20:02 |
| jjohansen | desrt: hrmm, well in generally I think it should be generic and apparmor could implement its own hooks to enforce its policy, selinux its own etc | 20:02 |
| desrt | i just get really pissed off when you guys are applying apparmor policies to packages using my libraries after the fact | 20:03 |
| desrt | and later on i start getting _very_ weird bug reports | 20:03 |
| jdstrand | desrt: fyi, suse uses apparmor. not sure who else | 20:03 |
| jjohansen | desrt: heh I can understand that, there are a few suse still supports it and there are a few other minor distros using it | 20:03 |
| jdstrand | (by deafult. it is availabel in debian and other places) | 20:04 |
| jjohansen | yeah the debian support is coming along now (that took long enough) | 20:04 |
| desrt | btw: i consider the use of apparmor for random trusted pieces of code (that might have exploitable bugs) to be quite different than using it as a front-line against untrusted code... | 20:04 |
| desrt | but i've seen enough problems caused by the first to know that they will be 10 times worse when we try to start doing the second... | 20:05 |
| jjohansen | desrt: heh, yeah they are some what different. Fundamentally the same but in practice ... | 20:06 |
| jdstrand | desrt: yes. we will be focusing on the latter to improve the app developer process. the side benefit is we get a lot new stuff that admins and others can use | 20:06 |
| desrt | i still think you guys are on a bad path unless you're planning to rewrite the platform | 20:06 |
| desrt | but i'm more than happy to help you by rewriting my little corner of it | 20:06 |
| desrt | i'm quite busy, but we should definitely chat at UDS | 20:07 |
| jjohansen | desrt: definitely | 20:07 |
| jdstrand | desrt: also, we are talkinga bout 'apparmor' here, and while it will be an important part of this app isolation stuff, we understand that there will be more to it than that. ie, the trusted picker, this dconf stuff, etc | 20:07 |
| desrt | jdstrand: 'trusted picker', 'dconf stuff' are great. 2 good ideas. | 20:08 |
| desrt | jdstrand: you will need 100 other :) | 20:08 |
| mhall119 | desrt: you will be at UDS? | 20:08 |
| jdstrand | desrt: excellent-- thank you for that. I expect sessions at UDS surrounding all this, and dconf is definitely something we want to address :) | 20:08 |
| desrt | mhall119: i've been to every UDS :) | 20:08 |
| jdstrand | desrt: indeed :) | 20:08 |
| mhall119 | desrt: excellent, we'll definitely be talking more about this and app development processes | 20:08 |
| jdstrand | desrt: we will of course focus initially on things with highest impact (both in terms of usability and security) | 20:09 |
| jdstrand | but definitely want to get as many of those 100 as possible :) | 20:09 |
| desrt | jdstrand: the attackers will just focus on the other 98.... | 20:10 |
| jdstrand | of course, but we have to start somewhere | 20:10 |
| * desrt still thinks you're on the wrong path, but alas... | 20:10 | |
| jdstrand | and those 98 will just not be allowed intially | 20:10 |
| desrt | jdstrand: so you're going to prevent apps from connecting to X? :) | 20:10 |
| seb128 | desrt, I didn't see you in Paris UDS :p | 20:10 |
| desrt | seb128: damnit. i knew you'd catch that. | 20:10 |
| seb128 | ;-) | 20:10 |
| desrt | seb128: i was in the montreal non-UDS, though | 20:11 |
| seb128 | that doesn't make it for the missing one :p | 20:11 |
| kenvandine | :-D | 20:11 |
| desrt | so the answer to the question "how many UDS have there been?" and "how many UDS have you been to?" is the same, in my mind :) | 20:11 |
| kenvandine | nothing gets past seb128 | 20:11 |
| jdstrand | desrt: and here I was thinking that we had common ground :) we *want* to talk to the library authors like yourself to solve difficult problems like dconf | 20:11 |
| JanC | desrt: I think there is no way to go 100% without excluding more than half of the useful applications ;) | 20:11 |
| jdstrand | desrt: oh, X has definitely been identified and is something we need to address too | 20:11 |
| * desrt wants to install a defrag app from the app store! | 20:11 | |
| mhall119 | desrt: that's fine, but you won't be doing it through Extras | 20:12 |
| desrt | i just really really hope you guys don't attempt to lull users into thinking that installing things from extras will be even _vaguely_ secure | 20:12 |
| mhall119 | desrt: we'll avoid lulling | 20:13 |
| jdstrand | JanC: the IOS app store has a bunch of stuff people like-- I think we (ie, greater FLOSS community) can have similar or better confinement and usability if we work together | 20:13 |
| jjohansen | desrt: define secure :D | 20:13 |
| desrt | jjohansen: "can't erase all of my files" seems like a good definition | 20:13 |
| mhall119 | desrt: always a good start | 20:13 |
| desrt | i'd also go with "can't steal all of my saved password out of firefox" as a reasonable symbolic alternative | 20:13 |
| jdstrand | desrt: we definitely want to prevent that | 20:13 |
| jdstrand | desrt: and that too :) | 20:14 |
| desrt | jdstrand: here's the thing... | 20:14 |
| desrt | jdstrand: i'll make a bet with you here and now that i can write an app to steal all of your firefox passwords | 20:14 |
| mhall119 | well that's easy | 20:14 |
| mhall119 | getting it into Extras though | 20:14 |
| desrt | well | 20:14 |
| desrt | apparently anyone is allowed to upload? | 20:15 |
| mhall119 | no | 20:15 |
| desrt | what's the trust process? | 20:15 |
| mhall119 | currently, full code review | 20:15 |
| desrt | jono said the plan was to get rid of that because it doesn't scale | 20:15 |
| mhall119 | correct | 20:15 |
| desrt | so what will stop me? | 20:15 |
| desrt | it certainly won't be apparmor :) | 20:15 |
| mhall119 | your concern for your own reputation | 20:16 |
| jdstrand | desrt: keep in mind-- this is a long term goal, not what you can expect to see in 12.10 or 13.04 | 20:16 |
| * desrt uses a fake name | 20:16 | |
| mhall119 | fake names won't be allowed | 20:16 |
| desrt | you will do ID document checks, or so? | 20:16 |
| JanC | CC checks maybe | 20:16 |
| * desrt gets a $25 visa debit card | 20:16 | |
| * desrt pays with cash | 20:17 | |
| JanC | but those aren't really safe of course | 20:17 |
| mhall119 | desrt: that hasn't been defined yet, but there will be some review of who is requesting upload access | 20:17 |
| jdstrand | so, we are are working on the hard bits | 20:17 |
| desrt | mhall119: okay. i feel a bit better | 20:17 |
| * mhall119 is glad | 20:17 | |
| desrt | still has nothing to do with apparmor, though :) | 20:17 |
| mhall119 | desrt: we're currently torn between requiring millimeter-wave full body scans, or manual pat-downs | 20:17 |
| JanC | desrt: you can't sell or buy anything through Canonical without a credit card, unfortunately ;) | 20:17 |
| jdstrand | if we can get things like X, dbus, dconf, gnome-keyring, etc under control with usability like trusted file pickers implmented, then we can say 'it isn't supported' until we can implement it | 20:18 |
| dobey | desrt: DNA sample | 20:18 |
| desrt | mhall119: i always take the patdown | 20:18 |
| mhall119 | seb128 will be administering them | 20:18 |
| JanC | they don't take debit cards or cash :p | 20:18 |
| desrt | mhall119: they object to me wearing my tinfoil hat in the scanner | 20:18 |
| mhall119 | because nothing get's past seb128 | 20:18 |
| desrt | something about microwaving metal....? | 20:18 |
| seb128 | mhall119, lol, good one :p | 20:18 |
| seb128 | give it to robert_ancell rather | 20:18 |
| jdstrand | desrt: also, do keep in mind, apparmor is only part of it. we absolutely will have to redesign/rewrite things to get there | 20:18 |
| dobey | JanC: debit cards work fine in US/CA afaik | 20:19 |
| robert_ancell | seb128, oh, timing | 20:19 |
| desrt | robert_ancell: not really | 20:19 |
| seb128 | robert_ancell, hey, I just mentioned your name because you joined ;-) | 20:19 |
| desrt | robert_ancell: unless you actually fancy reviewing all submissions to the 'extras' in software centre... | 20:19 |
| robert_ancell | no | 20:19 |
| desrt | 'no'? just like that? | 20:19 |
| seb128 | robert_ancell, they are arguing on security,sandboxing,id checking and making users secure | 20:19 |
| desrt | step 1) unplug your computer | 20:19 |
| seb128 | robert_ancell, you will check the IDs of all app devs right? | 20:19 |
| robert_ancell | they're dreaming if they think they can do this manually | 20:20 |
| robert_ancell | not in the slightest | 20:20 |
| desrt | robert_ancell's arrival adds more fuel to the now-simmering fire | 20:20 |
| seb128 | robert_ancell, got your N9 already? | 20:20 |
| seb128 | robert_ancell, congrats for that btw :p | 20:20 |
| desrt | wtf | 20:20 |
| seb128 | you can join desrt | 20:20 |
| desrt | picsaw won? | 20:20 |
| seb128 | desrt, apparently picsaw is worth a n9 | 20:20 |
| seb128 | desrt, no, it finished 3rd | 20:21 |
| desrt | thank god | 20:21 |
| seb128 | desrt, it's not worth a laptop but it's worth a n9 | 20:21 |
| desrt | please tell me a non-canonical-employee won 1st :p | 20:21 |
| seb128 | indeed | 20:21 |
| seb128 | the second as well | 20:21 |
| robert_ancell | so the next step is finding someone to trade the n9 for a nexus | 20:21 |
| desrt | robert_ancell: done | 20:21 |
| seb128 | desrt, you like the n9, don't you? ;-) | 20:22 |
| desrt | ya. i seriously love it. | 20:22 |
| JanC | dobey: I unsuccessfully tried using a Maestro debit card to buy music in U1MS and other stuff from the Ubuntu store several times over the years (despite Maestro being listed as supported!), but if that actually works now that would be nice ☺ | 20:22 |
| desrt | it's a fantastic device | 20:22 |
| dobey | then find someone to trade the nexus for a prē | 20:22 |
| seb128 | desrt, don't get use to it, you will not be able to find the next generation equivalent | 20:22 |
| dobey | JanC: your card is a special case, yes | 20:22 |
| desrt | i rarely find myself wanting to throw it against the wall | 20:22 |
| seb128 | used | 20:22 |
| desrt | which is more than i can say for any other smartphone i've ever used | 20:22 |
| desrt | seb128: ya. sad story :( | 20:23 |
| desrt | i hope it lasts a long time | 20:23 |
| seb128 | desrt, I don't have my issue with my old dumbphone, the thing last a week without charging and call fine ;-) | 20:23 |
| JanC | dobey: my card is a Maestro card as standardised for debit card payments in the EU | 20:23 |
| desrt | maybe android will stop sucking by then | 20:23 |
| robert_ancell | dobey, no, I want a platorm with a future | 20:23 |
| desrt | or maybe we'll have phonebuntu :) | 20:23 |
| dobey | robert_ancell: so clearly you pick the one that's built on java, whilst oracle steamrolls it into the ground from the sidelines? :) | 20:23 |
| seb128 | robert_ancell, don't buy a lumina, apparently they won't get upgraded to win8 :p | 20:23 |
| desrt | dobey: s/steamrolls/tries to steamroll and fails/ | 20:24 |
| robert_ancell | dobey, that's not going so well for oracle | 20:24 |
| kenvandine | hey robert_ancell! | 20:24 |
| robert_ancell | kenvandine, hello | 20:24 |
| JanC | (and debit card standardisation in the EU happened several years ago) | 20:24 |
| seb128 | robert_ancell, you joined earlier than usual btw? seems like you caught a busier time than usual to be online ;-) | 20:24 |
| robert_ancell | seb128, yeah, I want to take a longer lunchtime | 20:24 |
| seb128 | robert_ancell, ok, welcome to what IRC looks line during the hours you are offline :p | 20:25 |
| JanC | dobey: actually, the bug was that Canonical used a UK-only Maestro payment system... | 20:25 |
| mhall119 | offline? what's that? | 20:25 |
| robert_ancell | so no work being done this morning? ;) | 20:25 |
| desrt | seb128: can you SRU gnome-control-center 3.5.90 into dapper? | 20:25 |
| kenvandine | hahahha | 20:25 |
| dobey | desrt, robert_ancell: you misconstrued my use of 'steamrolls' to be a reference to the patent trolling :) | 20:25 |
| seb128 | desrt, can do, want it to warty as well? | 20:26 |
| desrt | seb128: maybe robert will do warty, since he's here | 20:26 |
| dobey | JanC: yes. which has nothing to do with debit cards in general. only maestro | 20:26 |
| kenvandine | seb128, great news... the clutter version of gnome-control-center-signon landed :-D | 20:26 |
| desrt | you might need to backport a thing or two... i think there's been a new gtk release or something like that | 20:26 |
| robert_ancell | dobey, well, regardless of any big company fighting android is the most useful platform (along with iOS) for the next few years | 20:26 |
| jdstrand | desrt: +1 on unplug computer. it would make my life a lot easier | 20:27 |
| seb128 | kenvandine, it's past troll our, I don't care anymore at this time :p | 20:27 |
| jdstrand | though admittedly, harder to push out updates... | 20:27 |
| JanC | Maestro is *the* worldwide debit card system; I have been able to use it in lots of countries for more than a decade, but Canonical's Maestro support is (was?) UK-only... | 20:27 |
| kenvandine | seb128, awesome... we are free to trash the archive! | 20:27 |
| kenvandine | :-D | 20:27 |
| desrt | jdstrand: updates are just another vector. i don't trust you anymore :) | 20:27 |
| dobey | robert_ancell: for varying definitions of 'useful' sure | 20:27 |
| jdstrand | desrt: aw shucks, but I'm trying to protect you :P | 20:27 |
| desrt | next thing you're going to tell me that i can't have my cigarettes | 20:28 |
| desrt | and it's "for my own good" | 20:28 |
| dobey | JanC: no it isn't. for instance 'america' is a continent within 'worldwide' and we don't use maestro here | 20:28 |
| dobey | JanC: so unless you mean the biblical definition of 'worldwide' it's not true :) | 20:28 |
| JanC | dobey: I used my Maestro-compatible debit card in NYC in 1993... | 20:28 |
| jdstrand | well, it would be, but no, I won't do that ;) | 20:28 |
| mhall119 | desrt: cigarettes can open a security hole in your trachea | 20:28 |
| jjohansen | desrt: no we will recommend against using cigarettes but if you must please do it in this isolated little pod :) | 20:29 |
| dobey | JanC: yes; works, and is what provides debit cards everywhere, are two different things | 20:29 |
| mhall119 | +1 for sandboxing smokers | 20:29 |
| seb128 | kenvandine, stop dreaming, I'm not THAT tired :p | 20:29 |
| desrt | "Canonical adopts official policy advising smoker's to throw their cigarette butts in children's play areas" | 20:29 |
| desrt | *smokers | 20:29 |
| mhall119 | that's were everyone else seems to throw them | 20:30 |
| * mhall119 speaks as a parent | 20:30 | |
| kenvandine | seb128, :) | 20:30 |
| jbicha | desrt: you don't smoke, do you? | 20:32 |
| * desrt was wondering when someone was going to mention that | 20:32 | |
| desrt | jbicha: i try not to let things like facts get in the way when i'm formulating an argument | 20:32 |
| ricotz | desrt, just for a response, yeah that is the uptream background panel in g-c-c | 20:38 |
| desrt | ricotz: madness | 20:38 |
| ricotz | desrt, ;) | 20:39 |
| failedassertion | I want to autogenerate a GRUB entry like "Blahblah-blah (fallback)" but with a different set of options | 20:42 |
| failedassertion | is there a more-correct way to do this than either editing 10_linux.conf or making a custom copy of it that does different stuff? | 20:43 |
| failedassertion | Alternatively, is there a way to make the fallback option not run the fallback options menu? | 20:44 |
| failedassertion | Basically, this is a headless system where the first entry will mount most things read-only, but I need to be able to reboot read/write over SSH (say, with grub-reboot) | 20:45 |
| failedassertion | upps, this should probably be #ubuntu | 20:46 |
| JanC | failedassertion: editing /etc/default/grub is not enough for your purposes? | 21:00 |
| ricotz | desrt, while you are being a brave updating tester, is totem working alright? | 21:01 |
| desrt | wtf | 21:02 |
| desrt | when did backspace stop working in nautilus? | 21:02 |
| failedassertion | Basically, my default is to append "fsprotect=64M" to the kernel cmdline. I want to be able to reboot without that option, but I need to be able to do it remotely. I've got the recovery mode booting without the option, so I can just grub-reboot 1, but it hangs on the friendsly recovery menu thing | 21:02 |
| desrt | ricotz: seems okay | 21:03 |
| failedassertion | Basically, I'd rather abuse /etc/default/grub than have to edit the 10_linux.conf script or copy it. | 21:04 |
| failedassertion | but if there's no clean way to do it, I'll probably just make a copy of it | 21:04 |
| ricotz | desrt, good | 21:04 |
| === jbicha is now known as Guest41777 | ||
| failedassertion | JanC: ^ | 21:05 |
| desrt | the slider appears not to be working, actually | 21:07 |
| desrt | as in, it doesn't move | 21:07 |
| desrt | and when i move it, the video stops playing | 21:08 |
| desrt | and won't start again | 21:08 |
| JanC | failedassertion: check /etc/grub.d/10_linux about how it works, especially at what environment variables (as set in /etc/default/grub) it uses for what | 21:08 |
| JanC | (removing the recovery menu package shoult make it boot in single user mode, it seems) | 21:10 |
| JanC | should* | 21:11 |
| failedassertion | JanC: Yeah, I saw that linux-recovery thing. I may just copy 10_linux to something like 08_linux and tweak it. At least then it won't get clobbered during upgrades | 21:12 |
| failedassertion | unfortunately, I need the network to come up as well | 21:13 |
| failedassertion | so I don't think single is quite going to work | 21:13 |
| JanC | yeah, 08_whatever should work | 21:15 |
| JanC | and maybe submit a feature request or patch to improve the current 10_linux ;) | 21:15 |
| robert_ancell | robru, hi, welcome | 21:16 |
| JanC | say, if $GRUB_CMDLINE_RECOVERY is defined & non-empty, use that instead of the current "recovery nomodeset" or "single nomodeset" | 21:17 |
| mlankhorst | death to nomodeset :s | 21:17 |
| JanC | mlankhorst: I'm pretty sure nomodeset is still useful on some hardware if you have to fix certain issues... | 21:18 |
| mlankhorst | there's the modesetting driver still | 21:19 |
| failedassertion | JanC: Sounds good. I'll try making that work and submit a patch | 21:19 |
| JanC | I'm pretty sure i have several computers with hardware that don't have a modesetting driver ;) | 21:20 |
| mlankhorst | and for those the old vesa fallback will continue to work | 21:20 |
| mlankhorst | and those wouldn' t be affected by nomodeset removal anyhow | 21:20 |
| failedassertion | JanC: thanks for your help | 21:21 |
| JanC | mlankhorst: actually, one of them never worked with the vesa driver... ;) | 21:22 |
| mlankhorst | crappy arms? :/ | 21:23 |
| JanC | but AFAIK it doesn't work with the dedicated driver anymore either | 21:23 |
| JanC | no, SiS | 21:23 |
| JanC | at some point it stopped working with the sis driver, and it wasn't useful enough to try to find out why ;) | 21:23 |
| JanC | (and vesa not working was because the vesa bios was broken) | 21:26 |
| === seb128_ is now known as seb128 | ||
| === Guest41777 is now known as jbicha_ | ||
| mfisch | does the unity app lens use the Categories field? from what I can see it does not | 21:42 |
| mfisch | looks like it uses the Comment field | 21:42 |
| seb128 | mfisch, use for what? | 21:45 |
| mfisch | seb128: for searching, i just remember there's the categories filter | 21:48 |
| mfisch | seb128: I was trying to find all my humble bundle games | 21:48 |
| mfisch | so when I type in "Game" it found things that had Game in the name or comment field in the .desktop file | 21:49 |
| seb128 | mfisch, not sure, it probably uses it for the filters' categories on the side | 21:53 |
| mfisch | seb128: yep, that part does work, I'll just use that | 21:54 |
| robru | robert_ancell, hi, thanks | 22:00 |
| === zyga_ is now known as zyga | ||
| === Ursinha` is now known as Ursinha | ||
| === Guest70479 is now known as everydaylinuxuse | ||
| robert_ancell | Laney, hey | 23:24 |
| robert_ancell | Laney, Can you have a look at https://bugs.launchpad.net/ubuntu/+source/clutter-gst/+bug/1040930 and see if we match what Debian will do? | 23:29 |
| ubot2` | Ubuntu bug 1040930 in clutter-gst "Update to 1.9.90" [Wishlist,Triaged] | 23:29 |
| chrisccoulson | i've finally managed to trick flash in to thinking that hal is installed | 23:31 |
| chrisccoulson | jasoncwarner_, ^^ | 23:31 |
| chrisccoulson | hmmm, it's a shame that the flash plugin now crashes when i resize the browser window :/ | 23:33 |
| TheMuso | chrisccoulson: The sooner we can do away with flash, the better. :) | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!