=== mfisch is now known as Guest45087 [06:46] good morning [06:50] * didrocks is going to look with a fresh eye why this test is failing [07:04] didrocks: bonjour! [07:07] hey pitti :) [07:16] good morning! [07:25] hey larsu [07:35] hi didrocks! How's it going? [07:36] larsu: it's going, and you, feeling better? :) [07:37] didrocks: not really :( [07:39] good morning desktopers [07:39] hey didrocks larsu [07:41] hi seb128 :) [07:41] morning seb128 [08:12] seb128, just upgraded my u8 machine and installed metacity, now u8 session or u7 session will not start :/ [08:12] might just be me though [08:12] morning btw :D [08:14] hi willcooke! [08:15] hey larsu [08:16] hey willcooke, what error do you get [08:17] seb128, which log file should I be looking in? [08:18] .cache/upstart/gnome-session-Unity.log [08:18] that's for unity7 [08:18] what happens at login? [08:18] mlankhorst, I just pulled your latest PPA too, just in case that's involved ^^ [08:18] morning willcooke [08:18] seb128, @ login -> type password -> nada [08:19] nada like you stay on the greeter? [08:19] yeah - but [08:19] :) [08:19] or does the greeter goes away? [08:19] I removed metacity and now I can log in to U7 [08:19] let me just recheck that [08:19] weird [08:19] seb128, I might be wasting your time again [08:19] :) [08:20] lol [08:20] what you describe is weird for sure [08:20] have an extra wm installed shouldn't impact on existing sessions [08:20] but maybe there is something in the daily updates or in the ppa you opted in for [08:21] doesnt seem metacity related, unsurprisingly [08:21] ok U7 working fine, U8 b0rked [08:22] where b0rk = greeter stays on the screen [08:22] sounds like a Mir issue [08:22] mlankhorst, is there any new Mir stuff in your ppa? [08:22] ohhh - mlankhorst is off todayu [08:22] it's Friday [08:24] I suspect it's a bleeding edge Mir which is the problem, so panic over [08:24] ;) [08:25] Does anyone *want* to go to MWC? [08:25] and work I mean [08:25] not, ya know, look round [08:26] lol [08:27] where/when is it and what can we do that is useful there? [08:27] 24_27 feb in Barcelona? [08:28] larsu, I'm running your updated theme, things are better with it ;-) [08:29] 2->5 March - http://www.mobileworldcongress.com/ [08:29] * didrocks puts back swim clothes to the closet :p [08:32] seb128: :) === mfisch is now known as Guest3214 [11:32] willcooke, mlankhorst's PPA definitely has the latest Mir, now with dependencies on new protobuf still stuck in -proposed, so will probably munge your system until that's cleared up (which may have happened by now) [11:33] check /var/log/lighdm/* for errors [11:33] thx bregma [11:35] yup [11:35] [+36.81s] DEBUG: Seat seat0: Creating display server of type mir [11:35] [+36.81s] DEBUG: Using VT 8 [11:35] [+36.81s] DEBUG: DisplayServer: Logging to /var/log/lightdm/unity-system-compositor.log [11:35] [+36.81s] DEBUG: Launching process 2377: /usr/sbin/unity-system-compositor.sleep --file '/run/lightdm-mir-0' --from-dm-fd 12 --to-dm-fd 21 --vt 8 --enable-hardware-cursor=true [11:35] [+36.81s] DEBUG: DisplayServer: Waiting for system compositor for 60s [11:35] [+36.93s] DEBUG: DisplayServer: Compositor closed communication channel [11:35] [+36.93s] DEBUG: Process 2377 exited with return value 127 [11:35] [+36.93s] DEBUG: DisplayServer: Unity system compositor stopped [11:35] [+36.93s] DEBUG: Releasing VT 8 [11:36] [+36.93s] DEBUG: Seat seat0: Display server stopped [11:36] and then in the u-s-c.log: [11:36] /usr/sbin/unity-system-compositor: relocation error: /usr/lib/x86_64-linux-gnu/libmirplatform.so.4: symbol _ZN3mir7logging3logENS0_8SeverityERKSs, version MIR_COMMON_3 not defined in file libmircommon.so.3 with link time reference [11:37] that nutty Mir and it's totally unstable ABI [11:37] so I'm assuming that libmirplatform 4 doesnt work with libmircommon 3 [11:37] try adding -proposed to your sources and updating [11:37] oooh [11:37] plan [11:37] ! [11:37] I take no responsibility for the result [11:38] ha [11:38] if it breaks I'll give up on that for today [11:38] (I have -proposed on on my test machine, it was fine yesterday) [11:39] do I need to add it to everything in /etc/apt/sources.list? [11:39] maybe just main? [11:39] I think just main is all you really need for this [11:40] BTW, the Steam client now runs on Unity 8 with the latest PPA build [11:41] O_o [11:41] whaaa! [11:41] that's awesome! thank you! [11:41] bregma, in Xmir right? [11:41] yes [11:41] * willcooke upgrades to proposed and has some qtmir stuff upgrading [11:42] updated qtmir is also i the PPA [11:42] ahh - and also libmirplatform4 :) [11:42] it's depndencies all the way down [11:42] * bregma gos to take the dog for a walk [11:42] ttfn [11:45] hrm [11:45] I think libmircommon is still too old [11:46] never mind [11:46] I'll try again later [12:11] protip of the day: do backups. often. [12:11] :D [12:14] for some reason my work notebook did a hard reset and didnt boot through after that. I had all the joy of system recovery and expected some data to be lost, with the last full backup 6 months old. [12:16] * larsu notes to back up his laptop after lunch [12:17] I had to boot from a LiveCD, mount the encrypted drive (crossing my fingers) and then tell fsck, which already screamed at me that my primary superblock is gone, to just "fix(y)?" 2 bazillion things into the blind on the fs ... [12:19] yikes [12:19] I could do a a full backup then, and even boot -- though I am not sure about the extend of corruption. My syslog for the event is just graced with a huge set of interesting binary characters ... [12:20] meh [12:20] backups are hard and take a long time [12:20] ;) [12:21] willcooke: bullets fear the brave! === alan_g is now known as alan_g|lunch [13:53] sometimes i feel like i miss out on the best times by not being european [13:56] everything's nicer here, not only the time zone [13:56] you shuld consider moving ;) [13:56] * larsu knows just the right city for you....... [14:02] i hope it's not berlin [14:02] ts [14:02] tedg: https://bugzilla.gnome.org/show_bug.cgi?id=741156 [14:02] Gnome bug 741156 in gdbus "gdbus: add g_dbus_object_path_{un,}escape" [Normal,New] [14:03] hey desrt, happy friday ;-) [14:04] seb128: :( [14:05] larsu, Cool, I'd add some 16-bit characters to your tests: http://bazaar.launchpad.net/~indicator-applet-developers/pay-service/trunk.15.04/view/head:/tests/dbus-interface-tests.cpp#L262 [14:05] larsu, That screwed me up once already :-) [14:05] i hate it already :D [14:05] double-escaped utf8? awesome [14:06] tedg: no. ascii. [14:07] larsu, DBus needs ascii, but I dont' think we can assume that as input, no? === alan_g|lunch is now known as alan_g [14:08] larsu, Ah, also you don't handle the first character can't be a number case. [14:08] tedg: ya systemd does this as well, but the spec says nothing of the sort [14:09] tedg: what do you want to encode? [14:09] larsu, Hmm, I'm pretty sure Lennart linked me to the place. Let me look. [14:10] btw: if we allow non-ascii in these strings then you either need to decide if you're going to enforce valid utf8 (seems a bad idea) or document that the API is not returning a string but rather a guint8[] [14:10] desrt: why is utf8 a bad idea? [14:11] tedg: http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-marshaling-object-path [14:11] larsu, Hmm, okay, I can't find it. I can't imagine that I would have done it for consistency with systemd... [14:11] because if this is encoding filenames for example (which i suspect it is) then enforcing utf8 will cause problems [14:12] larsu, The thing I was encoding where payment item ids, which are UTF8 and configured by the application developer. So they could be "magic-potion-35" or what ever that is in Chinese. [14:12] tedg: ya I was suspecting this as well and I'd argue that this is a bad idea... [14:12] Why not convert to utf8? [14:13] utf8 should work by ignorance, no? [14:13] I'm not as worried about filesystem names. But it seems in that case you should convert to utf8. [14:13] it does byte-wise escaping... [14:19] larsu: sorry about the grumpy review. you caught me before coffee. [14:25] desrt: no worries. This should indeed be >=, not > (but nul isn't a problem because of lazy evaluation) [14:25] desrt: as for input, I'd argue the string should be utf8 as per glib convention. Doi you think we need to verify it? [14:26] desrt: as I said before, I didn't think anyone but the process that called escape() would call unescape(), hence the critical [14:29] you really need to make that a lot more clear [14:29] because i might think that i can call that on systemd unit file object paths in order to grok them, for example [14:30] what else would you want? Taking an error? [14:30] if you say this is something that people might want to do, ok [14:30] well, there is a conflict here [14:30] we must choose one property that we want more: [14:31] 1) canonical encoding (with non-canonical forms rejected) [14:31] 2) a mapping that always succeeds [14:31] you can't have both [14:31] (right now we have neither...) [14:31] i'd prefer a simple NULL return in the invalid case, though [14:32] (2) can never be correct [14:32] so ya, (1) [14:32] so then return NULL if it's non-canonical [14:32] I'd still accept the ambiguous ones like I do now [14:32] desrt: this is what the code did before and I changed it ... [14:32] but I think you convinced me [14:33] my security spidy-sense is tingling here [14:33] this is the sort of function that somebody somewhere is going to expose to people sending untrusted strings to it [14:33] what bad can happen? [14:33] i can imagine a few things [14:34] * larsu listens [14:34] one is that there is a whole class of attacks where non-equal-but-equivalent encodings can be used to attack systems [14:34] which is why non-canonical-encoded utf8 is now rejected [14:34] there have been all sorts of issues there in the past... [14:34] the other is that we can cause crashes in the receiving program.... like with your p[2] issue in the patch [14:35] this is never evaluated... [14:35] if p[1] is 0 [14:36] and p[0] isn't in the loop [14:36] ah. interesting. [14:36] so. you want a utf8 check? [14:37] no [14:37] i think i prefer the 'this is not utf8' annotation on the return value [14:37] I didn't know that that is convention - if you have an untrusted string, check it before giving it to glib functions [14:37] absolutely [14:37] almost everything in glib assumes that it's getting valid utf8 [14:37] a/glib/glib world/ [14:38] if I return uint8*, won't that break the 99% case? [14:38] you don't actually return guint8 [14:38] you just annotate that you do [14:38] I want to put this into another string-processing function but now need to cast [14:38] oh. what? [14:38] * Returns: (transfer full) (array zero-terminated=1 length=length) (element-type guint8): [14:39] something like that [14:39] minus the 'length' crap [14:39] but then I have the problem in bindings [14:39] that will prevent python from assuming that the string is utf8 and trying to transcode it to unicode [14:39] i.e., I get a byte in python, not a string [14:39] you'll get a bytestring in python [14:39] which is what you want.... [14:40] and then take a byte string in unescape() and return a string? [14:40] yes [14:40] interesting [14:40] thanks [14:43] i would be nice if we could use the kdbus transition as a time to relax object path rules [14:43] desrt: do I need to annotate that in the same way? [14:43] but i don't think it's really possible :/ [14:43] larsu: hm? [14:43] the input parameter to unescape() [14:43] yes [14:43] wait. no. [14:43] that will always be a ascii string [14:44] you need to annotate the input to escape() though [14:44] in order to allow the wider range of stuff that could be in there [14:44] the input to escape is a utf8 string... [14:44] maybe it's a filename? [14:44] it's docuemnted as must be a utf8 string [14:44] (now) [14:45] hm, I guess I misunderstood you before then [14:45] I thought you meant escape() is utf8 -> bytestring and unescape() the other way around [14:46] escape() is bytestring -> ascii (with heavy restrictions) [14:46] unescape is therefore ascii -> bytestring [14:46] and both of those need annotations on both input and return params? [14:47] the ascii is fine as just a gchar* [14:47] since ascii is a subset of utf8 [14:47] makes sense [14:47] of course, if you find any characters out of the range of the object path rules (including non-ascii utf8 content) then it should be rejected... [14:48] you just said I don't have to verify utf8-iness [14:48] on return [14:48] there's no way that an escaped string should have utf8 in it [14:48] but an unescaped string may... or may not... [14:48] why isn't it enough to escape byte-wise? [14:48] it could be anything at all [14:49] you _should_ escape bytewise [14:49] that's what I'm doing.. [14:49] there should be absolutely nothing utf8-specific in these functions at all [14:49] right. You just said I should reject non-ascii utf8 content [14:49] i'm just noting that you should reject stuff according to the dbus rules (ie: outside of A-Za-z0-9_ or whatever) and this will automatically exclude non-ascii utf8 content [14:49] * larsu is throroughly confused [14:50] yes. That's what my plan was [14:50] (and what the patch does right now) [14:50] all that's missing are the annotations, then [14:50] the patch you posted rejects nothing... [14:51] it prints a critical [14:51] andthing that's not a _ gets copied straight through... [14:51] but ya, we already discussed that I'll change this to returning NULL, like I had before [14:51] okay [14:51] desrt: I changed it because I checked how systemd does it [14:51] i think we're just confusing each other at this point -- i'll wait for the patches :) [14:51] ya, I think so too [14:52] sorry === Guest3214 is now known as mfisch [15:09] seb128: I'm having the "can't click inside windows anymore" problem again [15:09] desrt: patch updated. Thanks for the feedback [15:09] larsu, I don't even understand that bug, what do you mean by "can't click"? [15:10] does it happen to all windows? [15:10] seb128: yes. No mouse input events are forwarded to any windows. [15:10] seb128: mouse input in unity works (panel, dash, ...). Keyboard works everywhere [15:10] do you have a touch screen? [15:11] does it do on any toolkit? [15:11] e.g same issue in firefox? [15:20] yes [15:20] no touch screen [15:20] definitely in every app [15:24] k, no idea about that :-/ [15:25] me neither. It's annoying [15:25] thanks tough [15:25] *though [15:29] np [15:30] could be an xorg issue [15:30] though that didn't change much [15:30] but neither did compiz/unity [15:58] larsu: new patch looks a lot better [15:58] still some nit-picks though :) [17:00] desrt: ah very good points. Thanks [17:35] desrt: escape() is nullable? [17:35] unescape is (and I documented is as such but forgot the (allow-none)) [17:36] i would imagine not [17:36] maybe i botched the review [17:37] nope -- look at the review. the comments are filed inside the docstring for _unscape() [17:38] desrt: ah sorry! I misread the escape() in the comment as the header, when it was the explanation [17:42] desrt: what's the point of dismissing non-canonical encodings? [17:42] "security" [17:42] also consistency [17:43] the gist is thus: [17:43] someone might resonably assume that string comparison (or building hashtables, or anything else) on escaped strings is equivalent to doing it with the unescaped version [17:43] and it ought to be [17:43] man, I just cleaned up the loop, now I have two places to return an error from [17:43] but if that assumption is false, someone could exploit it in unexpected ways [17:43] thanks for pointing out the hi = lo = 0 one [17:43] larsu: maybe not [17:43] you could add another && to that already-long else if [17:44] && (hi || lo) && !is_ascii((hi<<4)|lo) [17:44] and do (hi << 4 | lo) three times? [17:44] ya... [17:44] your choice [17:44] and then again in the append_c [17:44] * larsu thinks [17:44] btw: _strictly_ << and | are undefined on signed ints :) [17:45] (erm. maybe that's actually only true for signed ints that contain negative values. i always forget...) [17:45] I know, but then I thought about it and didn't care [17:45] fair enough :) [17:45] it's true in general, but we know the precise range for those numbers... [17:46] desrt: thanks for explainign the non-canonical thing. Makes sense [17:47] larsu: you used to be able to use utf8 to encode ascii characters like '.' and '/' [17:47] or strings like "../../" for example [17:47] you might imagine that this resulted in quite some fun [17:47] ugh.. [17:48] now the rule is that you must take the shorest possible form [17:48] which is ... just sane [17:48] but pretty much everything that handles utf8 in glib-world doesn't do that check [17:49] because it assumes it to already be valid [17:52] * desrt engages in some black pointer magic [17:52] let's hope valgrind doesn't get too upset... [17:53] (one of those "i technically shouldn't read from this address but it's impossible for it to crash" cases) [17:56] desrt: updated [17:56] desrt: don't. Or better: Why??? [17:56] gvariant alignment requirements [17:57] the problem comes with a message like ('a', 'b', 1234) where 'a' is sent as a memfd [17:58] gvariant would encode that like so: 'a \0 'b \0 \4 \3 \2 \1 \2 \4, noting that the int \4\3\2\1 is at an offset that is a multiple of 4 [17:58] but if we take off the "a\0" from the start (because it's a memfd) then the \4\3\2\1 part now comes aligned at an offset of 2 mod 4 inside of the second message part [17:59] so we have to cheat a bit when we allocate the buffer for our copy -- shifting it back two bytes [18:00] the nice bit is that we only ever cheat by 7 bytes maximum and it will always result in a more-aligned pointer (since the kernel does the same thing for us) -- so we cannot possibly crash [18:00] ...unless we're on a system that has a page size of less than 8 bytes === alan_g is now known as alan_g|EOW [18:09] larsu: arghghg. more annotation problems :( [18:22] desrt: :( I'll fix those later. gotta run now [18:23] larsu: thanks for all the work so far [18:23] and apologies for so many roundtrips