[09:31] <JamesTait> Good morning all!  Happy Wednesday and happy Carrot Cake Day! 😃
[14:22] <zaolin> http://www.golem.de/news/smartphone-security-root-backdoor-macht-mediatek-smartphones-angreifbar-1602-118888.html
[14:22] <zaolin> uiui
[14:23] <zaolin> https://twitter.com/jcase/status/687151870255755264?lang=de
[14:23] <ogra_> zaolin, yeah ... but not really harmful in ubuntu
[14:23] <ogra_> (apps cant access the property system, you would have to have shell access to abuse it)
[14:27] <zaolin> orga_: I guess so because of the lxc container. Did Canonical disable the debug feature ?
[14:29] <ogra_> zaolin, that has nothing to do with the container the app and security concept is simply different... to have someone abuse it you would have to hand him/her your phone with an unlocked terminal app open ... or hacve enabled ssh access and handed someone your secret ssh key .... or have developer mode enabled and given them the unlocked phone to access it via adb ...
[14:30] <ogra_> i think the container still has devel enabled and it is surely a bug that it does ... but it isnt really critical due to the above
[14:32] <matv1> that #reinvent campaign. Is it a smartwatch?
[14:33] <zaolin> orga_: Does a security target or detailed security architecure overview exists for ubuntu touch ?
[14:35] <ogra_> zaolin, it surely does, ask the security team ... i guess jdstrand could point you somewhere
[14:36] <ogra_> essentially apps cant access anything outside their workdir though
[14:36] <ogra_> or exec processes outside of it
[14:39] <zaolin> orga_: ah thanks
[14:40] <ogra_> the adb hack they describe wouldnt work on ubuntu, our adb is patched to always check if the screen is unlocked before letting you in .... so even with that hack you would first have to unlock the screen witrh your PIN or password
[14:40] <ogra_> (and thats the only possible remote expliot they describe)
[15:23] <jdstrand> zaolin: fyi, https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
[15:41] <zaolin> jdstrand: thank you ^^
[15:54] <zaolin> jdstrand: Will be there data encryption or FDE in the future ?
[15:54] <ogra_> zaolin, once the phone switches to snappy a s a base full disk encryption will come for free
[15:55]  * ogra_ isnt sure anyone will work on implementing that in the current system-image based setup ... it would be throw-away work
[16:02] <jdstrand> ogra_: well... that depends
[16:02] <jdstrand> zaolin: data encryption is planned at some point, yes
[16:02] <ogra_> jdstrand, well, given the manpower and given the many issues with existing features it would be a waste of time
[16:03] <ogra_> but indeed, up to the managers ;)
[16:03] <jdstrand> depending on what would be implemented, it wouldn't be a waste of time
[16:03] <jdstrand> ie, encrypted home would work either way
[16:03] <ogra_> snappy will encrypt all of 7writable at some point
[16:03] <ogra_> */writable
[16:04] <zaolin> jdstrand: Does snappy uses cryptsetup or is it filesystem encryption ?
[16:04] <ogra_> (which is essentially full disk encryption since the squashfses all live in /writable now)
[16:04] <jdstrand> I don't know the details of that, but fde is fine for a single user system, but doesn't help for encrypting differently per user
[16:04] <jdstrand> zaolin: atm, neither
[16:05] <jdstrand> put it another way
[16:05] <ogra_> it is a longstanding TODO item ;)
[16:06] <jdstrand> touch is lacking per-user data encryption. that is still something desirable on Touch and Ubuntu Personal (snappy)
[16:06] <pmcgowan> ogra_, did you lose the internal irc server or is it just me?
[16:06] <ogra_> pmcgowan, i'm, in
[16:06] <seb128> pmcgowan, just you
[16:06] <pmcgowan> hmm
[16:06] <jdstrand> what that will look like and when it will be implemented is TBD
[16:07]  * ogra_ still thinks the switch to snappy will happen before that and give us fde 
[16:08] <ogra_> (whi9ch is sufficient on single user phones ... not so much in multi user envs indeed)
[16:10] <zaolin> jdstrand: Yep but filesystem encryption sucks. Ext4 enc. is currently shit and encfs, ecryptfs should be used.
[16:10] <zaolin> * shouldn't
[16:13] <tyhicks> zaolin: what are the issues with ext4 encryption?
[16:14] <zaolin> tyhicks: Google didn't finished the implementation and it currently leaks meta data. It will need some time to get matured.
[16:14] <tyhicks> zaolin: what metadata is leaked?
[16:17] <zaolin> tyhicks: Take a look at the slides http://kernsec.org/files/lss2014/Halcrow_EXT4_Encryption.pdf
[16:18] <ogra_> from 2014 ?
[16:19] <zaolin> tyhicks: They wanted to impl. it in steps. I don't now the current state but my first rule for applied cryptography is: Don't trust fde software which is younger than 5 years
[16:19] <tyhicks> file size, name, and perms are metadata that's typically leaked with file level encryption
[16:19] <tyhicks> zaolin: Ok, thanks. I was just wondering if you had any solid gripes that I could pass on to the ext4 crypto developers.
[16:20] <tyhicks> They're aware of and accept the metadata leaks that you mentioned and there's obviously nothing they can do about your 5 year rule.
[16:22] <ogra_> heh
[16:22] <ogra_> time machines ftw :)
[16:22] <zaolin> tyhicks: Yeah it will mature and on some point it will replace encfs and ecryptfs.
[16:22] <tyhicks> zaolin: that's the hope
[16:23] <dobey> eh, /dev/null is the only secure encryption :)
[16:24] <ogra_> sudo mount /dev/null /
[16:24] <ogra_> ?
[16:24] <zaolin> I guess it's a step into the right direction anyway.
[16:25] <dobey> ogra_: writing all your sensitive data to /dev/null. nobody will ever get it out, not even you!
[16:25] <ogra_> !
[16:25] <ogra_> indeed ...
[16:25] <zaolin> Does ubuntu touch uses the trustzone for key management ?
[16:25] <ogra_> ... you shoudl blog about that
[16:26] <tyhicks> zaolin: no
[16:26] <zaolin> That would be also interesting to combine it with the selected encryption solution
[16:26] <ogra_> zaolin, i dont think so (though the only key i'm aware of currently in use is the 2Fa token for the ubuntu one account for the store)
[16:27] <coretex__> can i move the launcher to the right?
[16:27] <ogra_> (well ... and perhaps ssh keys but they use the known directories)
[16:27]  * coretex__ j/k
[16:27] <ogra_> coretex__, nope
[16:27] <coretex__> ogra_, thanks!
[16:27] <coretex__> :))
[16:27] <ogra_> :)
[16:27] <dobey> ogra_: online-accounts has several credentials
[16:27] <ogra_> coretex__, you can lock the screen rotation and hold it upside down ;)
[16:27] <coretex__> lol
[16:28] <dobey> it should be theoretically possible to write a gnome-keyring backend that uses the hardware assisted credentials storage though
[16:28] <zaolin> It would be good to bind the encryption to the hardware itself. So you can stop bruteforce attacks on short passwords
[16:28] <ogra_> zaolin, as long as we use 4 digit pins for everything thats rather moot ... but yeah
[16:28] <ogra_> :)
[16:29] <ogra_> (currently your PIN is also your sudo password for example ... that is changing though)
[16:29] <dobey> eh, anything that requires the user to retain knowledge of a token, is breakable
[16:32] <zaolin> Maybe you should take a look at the android key derivation process for disk encryption. They did some good stuff. I guess using argon2 as key derivation function would be better than scrypt: https://android.googlesource.com/platform/system/vold/+/master/cryptfs.c
[16:35] <ogra_> if thats usable out of the vold context ... why not
[16:35] <ogra_> or out of the android context i should have said :)
[16:39] <zaolin> orga_: It's more about the concept itself than the code. But sure you could use around 70% of the code.
[19:48] <kastegir> Can anyone assist me with an install issue?
[19:57] <kastegir> Can anyone assist me with an install issue?
[19:58] <dobey> !ask | kastegir
[19:58] <ubot5`> kastegir: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
[20:00] <stakewinner00_> where are the logs of music app?
[20:01] <ahayzen> stakewinner00_, most likely here /home/phablet/.cache/upstart/application-click-com.ubuntu.music_music_2.3.964.log
[20:01] <stakewinner00_> thanks, i was searching on .local
[20:01] <kastegir> I am trying to install ubuntu touch to my Nexus 7 (2013) All went well until the ubuntu-device-flash portion. On the workstation all seemed to go fine but when the tablet rebooted it is stuck in recovery mode with tons of e2fsck error 8s
[20:04] <stakewinner00_> ahayzen, i can't find ~/.cache/upstart/application-click-com.ubuntu.music* is there another place?
[20:04] <ahayzen> stakewinner00_, not for the music-app, try doing $ ls ~/.cache/upstart | grep music
[20:07] <stakewinner00_> nothing, about 3 or hours the music app crashes, there are some "autoclean"¿?
[20:07] <ahayzen> stakewinner00_, try running the app again, or maybe it isn't even getting to the point of the app starting?
[20:08] <stakewinner00_> ahayzen, it crashed when scrolling the list of artist, normally don't crasehs, but sometimes does
[20:08] <ahayzen> hmm, so there should be a log
[20:08] <ahayzen> after each reboot the logs get rotated IIRC
[20:09] <stakewinner00_> i restarted music app, now there are a log
[20:14] <stakewinner00_> can i configure remote logging without touching too much?
[20:18] <stakewinner00_> music app seems to be very buggy with the last update. Now i reopen music app, it doesn't crash yet, but there a lot of error messages
[20:18] <ahayzen> stakewinner00_, can you copy the output to pastebin ?
[20:18] <stakewinner00_> 84 messages of libust[20770/20799]: Error: Error opening shm /lttng-ust-wait-5-32011 (in get_wait_shm() at lttng-ust-comm.c:958) and similar, is this normal?
[20:18] <ahayzen> stakewinner00_, yeah that is normal, and isn't an issue
[20:19] <ahayzen> stakewinner00_, bug 1404302
[20:19] <ubot5`> bug 1404302 in webbrowser-app (Ubuntu) "liblttng-ust0 Error opening shm /lttng-ust-wait-5" [High,Confirmed] https://launchpad.net/bugs/1404302
[20:19] <stakewinner00_> i'll try to reproduce the last crash
[20:20] <ahayzen> thanks, stakewinner00_ please report a bug against the music-app with the log attached if you do :-)
[20:20] <ahayzen> and if any .crash files appear in /var/crash they maybe useful
[20:23] <kastegir> Sorry new error Failed to copy version-5.tar.xz to '/cache/recovery/': Is a directory
[20:24] <stakewinner00_> now it crashed, that happended a lot of time,   some songs caused music app to stop working, and i have to close it and start it again, i 'll see if this is a know issue
[20:24] <ahayzen> stakewinner00_, there are bug such as bug 1449790 which could be causing some of the issues
[20:24] <ubot5`> bug 1449790 in qtubuntu-media (Ubuntu RTM) "Fails to play a file with a # (hash symbol) in the path" [Low,Triaged] https://launchpad.net/bugs/1449790
[20:25] <stakewinner00_> this song has a normal title
[20:25] <stakewinner00_> i can upload the song too
[20:25] <ahayzen> if it is reproducible that is useful :-)
[20:25] <ahayzen> stakewinner00_, also the media-hub and mediascanner2 logs maybe useful in that case (in the same directory)
[20:26] <stakewinner00_> "Failed to get current playback duration:  org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist"
[20:27] <ahayzen> stakewinner00_, that sounds like media-hub crashed
[20:28] <jhodapp> ahayzen, stakewinner00_ yep, either crashed or dbus timed out (but most likely media-hub crashed and restarted)
[20:29] <stakewinner00_> media-hub log is of 3.3 M...
[20:30] <jhodapp> stakewinner00_, just select 200 or so lines that center around the song filename that you were trying to play
[20:30] <pmcgowan> kastegir, I think you are hitting this http://askubuntu.com/questions/674179/ubuntu-device-flash-fails-on-nexus-7-2013-android-5-0-2-cant-copy-image-to/675499
[20:30] <jhodapp> and then of course around the area where it failed to play
[20:30] <pmcgowan> kastegir, there are folks working to make the fix standard
[20:31] <stakewinner00_> seems to be related with the path name, this is a japanese song, with a some strange path, something like "02-%a5%a2%a5%a4%a5%bd%a5%c8%a1%bc%a5%d7 (second line).mp3"
[20:32] <stakewinner00_> http://pastebin.com/cBvAVhc8
[20:32] <jhodapp> stakewinner00_, how is the filename if you view it on the filesystem?
[20:33] <jhodapp> ahayzen, look at the file path that it's trying to open, how would media-hub have received this path? file:///media/phablet/3E3C-7B26/Music/Acidman/Slow Rain/02-�������ȡ��� (second line).mp3
[20:33] <jhodapp>  /media/phablet !?
[20:34] <stakewinner00_> "02-%a5%a2%a5%a4%a5%bd%a5%c8%a1%bc%a5%d7 (second line).mp3" seems to be the filename
[20:34] <ahayzen> jhodapp, that is an SD card
[20:34] <jhodapp> ahayzen, ah ok :)
[20:34] <ahayzen> jhodapp, looks like either our url encoding is breaking it, or media-hub isn't liking the unicode stuff
[20:34] <jhodapp> ahayzen, indeed
[20:35] <jhodapp> stakewinner00_, does the file browser show the Japanese characters in the filename or does it show up like how it does in IRC here?
[20:35] <ahayzen> jhodapp, stakewinner00_ probably best to open a bug against music-app and media-hub (ubuntu) with all the relevant logs, with the file if possible.
[20:35] <jhodapp> stakewinner00_, or if you look at it with Nautilus on an Ubuntu Desktop?
[20:35] <stakewinner00_> jhodapp, i'll do it tomorrow,
[20:38] <stakewinner00_> jhodapp, i don't have any graphical file browser, but other songs with strange unicode show like a square, but this songs seems like a url encoding. Maybe the media-hub crash with any url encoding like %df ¿?
[20:39] <jhodapp> stakewinner00_, yeah indeed...looks like we could use some tests that try some more edge cases with filenames
[20:40] <ahayzen> i wrote some tests for ASCII characters for the music-app in the past, just not all of unicode :')
[20:42] <stakewinner00_> i played a little bit
[20:42] <stakewinner00_> ir crash when scrolling the list of songs, no log
[20:43] <stakewinner00_> no log of music-app
[20:43] <ahayzen> stakewinner00_, does anything appear in /var/crash ?
[20:44] <stakewinner00_> yep
[20:44] <ahayzen> stakewinner00_, could you attach all of this information to a bug report, i've gotta go but i'll look at the bug report later
[20:53] <stakewinner00_> the bug i mentioned seems tu be a duplicated of https://bugs.launchpad.net/music-app/+bug/1220370 but the last update is from 2013-10-11 and the status is "fix released" i should add a comment with the crash log or open a new bug report?
[20:53] <ubot5`> Launchpad bug 1220370 in Ubuntu Music App "Music app crashes when scrolling a big list of artists" [High,Fix released]
[21:10] <dobey> stakewinner00_: new bug
[21:10] <dobey> well, a bug should probably be created from the already uplaoded error report (presumably it was uploaded)
[21:10] <kastegir> I followed those instructions and it won't boot at all now. I guess I will just go back to android until it is part of the main image
[21:14] <dobey> kastegir: followed what instructions?
[21:15] <dobey> kastegir: were you running android 4.4 on the device before flashing? is this the wifi or lte model?
[21:15] <kastegir> It is the wifi model and no I was running 6.0 because it had updated a bunch of times since I bought it
[21:15] <kastegir> I followed these instructions http://askubuntu.com/questions/674179/ubuntu-device-flash-fails-on-nexus-7-2013-android-5-0-2-cant-copy-image-to/675499
[21:16] <dobey> kastegir: flashing doesn't work right if you have android 5 or 6 on the device. also, very late production nexus 7 had a change in the MMC i think, and may not work at all
[21:18] <dobey> kastegir: did your nexus 7 come with adnroid 5 on it already? or did it originally come with 4.4?
[21:20] <kastegir> it came with 4.4
[21:22] <dobey> kastegir: ok, do this then: grab the original 4.4 image from google, flash it back on using the script provided with it, boot up to android welcome screen, reboot to the bootloader, and then do ubuntu-device-flash --bootstrap --channel ubuntu-touch/stable/ubuntu
[21:34] <kastegir> oh dobey... you deserve all the socks. That worked mate. Thanks!
[21:37] <dobey> kastegir: no problem. enjoy :)
[21:39] <pmcgowan> nice dobey