[09:31] <tboston> moin
[09:31] <tboston> I installed Android 5.1 on my Aquaris E5 HD Ubuntu Edition
[09:31] <tboston> now I was wondering how I could get back on Ubuntu Touch
[09:32] <tboston> since I can not unlock the Bootloader I guess
[09:50] <oSoMoN> Saviq, hey, can the milestone for bug #1433138 be updated please? it wasn’t fixed in ota9.1
[10:00] <lotuspsychje> tboston: did you read the install guide from topic?
[10:01] <tboston> lotuspsychje: yes I did, installing Ubuntu in a VM right now
[10:03] <lotuspsychje> tboston: ok, good luck :p
[11:06] <[tj]> moin
[11:49] <abeato> ogra_, hi, I have this MP for touch ramdisk: https://code.launchpad.net/~phablet-team/ubuntu/vivid/initramfs-tools-ubuntu-touch/support-adb-lollipop/+merge/288917
[11:49] <abeato> ogra_, mind taking a look?
[11:50] <ogra_> abeato, uuuh, why did you duplicate the adb upstart job code into the initrd ?
[11:50] <ogra_> oh, i see, its the panic function ...
[11:50] <abeato> ogra_, that is for the "panic" mode, which we enter before something else fails
[11:50] <abeato> *when
[11:50] <abeato> yep
[11:51] <ogra_> that should actually be removed altogether instead of being made functional ... its a security hole
[11:51] <abeato> well, to enter it you need to change one of the init scripts
[11:52] <abeato> if you can do that you already have full control ;)
[11:52] <ogra_> (modify the rootfs in a way that it triggers the panic and you have 100% root control from initrd over all data, even if the bootloader and recovery are locked down)
[11:53] <ogra_> you dont need to change the init scripts but andything on the MMC ...
[11:53] <ogra_> *any
[11:53] <ogra_> (or the kernel cmdline or whatnot, there are many attack vectors here)
[11:53] <ogra_> this function should be in a developer initrd ... but not in production
[11:55] <ogra_> abeato, technically the code is indeed fine ... but conceptual you guys should probably discuss if that should be in a production intird at all ...
[11:55] <ogra_> john-mcaleely, ^^^
[11:56] <ogra_> (it was on a long standing list (together with dropping all vars from /etc/environment for example) for removal in the old phablet team)
[11:57] <john-mcaleely> ogra_, if you wish to veto some feature of the phone initrd, I'm not going to contradict you. However, we'll not be making a separate developer initrd as a maintained thing anytime soon
[11:58] <john-mcaleely> so don't assume we will
[11:58] <ogra_> well, you guys make the decision, i can just give hints ;)
[11:58] <john-mcaleely> 'no' is a very strong hint
[11:58] <ogra_> the panic function in the initrd is a known risk though
[11:58] <abeato> ogra_, ok, if you think it is a real security risk I can add a line to return as soon as the script starts. we can remove that line if we want to debug
[11:58] <john-mcaleely> I'm not technically competent to make a call here
[11:59] <ogra_> perhaps someone from the security team, wants to chime in, perhaps i'm just over-cautious
[11:59] <ogra_> as i said, i think it should be discussed
[11:59] <ogra_> i'm fine with the code though
[11:59] <abeato> what I see is that we do a "panic" only when we cannot mount data or system partitions
[11:59] <john-mcaleely> is this worth a mail on ubuntu-touch?
[12:00] <ogra_> yeah, perhaps
[12:00] <ogra_> abeato, right, the question is how hard or easy is to trigger that for an attacker i guess ... the point is that it works around all lockdowns that vendors could do *if* you can actually exploit it
[12:01] <ogra_> john-mcaleely, i'm pretty sure ondra actually maintains such an initrd (with an adjusted adbd inside that actually allows you to debug the initial boot)
[12:02] <john-mcaleely> what he does in private between consenting adults his his business ;-)
[12:02] <ogra_> lol
[12:02] <ogra_> k
[12:03] <john-mcaleely> what we support as an org, is another matter
[12:03] <ogra_> well, if you want to do a port you need such an initrd .... it is very ulikely that you make a phone boot on first attempt
[12:03] <john-mcaleely> indeed
[12:03] <john-mcaleely> and without such a thing, we have perpetual 'undo the hacks' work items in porting
[12:04] <john-mcaleely> none of this is ideal
[12:04] <ogra_> in such an initrd the panic function is actually essential
[12:04] <abeato> certainly
[12:07] <ondra> ogra_ john-mcaleely abeato I understand all sides and kinda agree for both. We need it for bringup, and don't want it in production
[12:08] <john-mcaleely> ondra, I think you just picked up an action then - to document on a wiki how to hack the production initrd
[12:08] <ondra> another view is that, if we don't change adb binary in there, it's all academical anyway. since adbd will fail
[12:08] <ogra_> yeah, that too
[12:08] <john-mcaleely> and we remove this particular thing from the production initrd
[12:09] <abeato> correct, just keeping the hacked adbd out leaves us safe
[12:10] <ondra> despite all the efforts I did sneak into build options way to overlay initrd, for this exact reason
[12:10] <ondra> so I'd say, new git repo in phablet to host this "hacking" overlay for initrd, which we can trigger locally when building boot.img
[12:11] <ondra> and do not add anything to stock initrd, rather clean it from this half baked not working solution
[12:11] <ogra_> +1
[12:11] <abeato> ondra, +1 too
[12:11] <ogra_> just have a re-pack script in the pahblet tree
[12:12] <ondra> there are about 50 different ways to trigger panic in initrd, and this will open you whole front door to device,
[12:12] <ogra_> that pulls the right bits into the dev initrd you produce (here i'm totally in favour of re-packaing btw :) )
[12:12] <ondra> ogra_ that is already there, I sneaked it in :P
[12:12] <ogra_> great ...
[12:13] <ondra> we just need some git repo to host those bringup overlay, rather than mine and abeato chinstrap
[12:16] <ondra> I will create that, and may be some easy way to build it
[12:16] <ondra> who's gonna do a bit of cleaning on boot image then?
[12:17] <ogra_> i guess changing the panic() function to a "sleep 10; /sbin/reboot" or so would do
[12:17] <tboston> 2016/03/14 13:15:48 Expecting the device to be in the bootloader... waiting
[12:17] <tboston> 2016/03/14 13:15:49 Device is |VEGETAHD|
[12:17] <tboston> 2016/03/14 13:15:49 Device VEGETAHD not found on server https://system-image.ubuntu.com channel ubuntu-touch/stable/bq-aquaris.en
[12:17] <tboston> anyone?
[12:18] <ogra_> (or probably "/sbin/reboot recovery" so you dont end up with a boot loop that you need to intercept manually)
[12:18] <tboston> I see that theres 'vegetahd' instead of 'VEGETAHD' if that matters
[13:07] <tboston> 2016/03/14 14:05:44 Cache formatting was not successful, flashing may fail, check your partitions on device
[13:07] <tboston> 2016/03/14 14:05:44 Can't boot recovery image
[13:09] <ogra_> tboston, and that device was bought with ubuntu on it ?
[13:10] <tboston> ogra_: yup
[13:10] <tboston> btw found an article where there is a vegetahd recovery image
[13:10] <tboston> trying that now
[13:32] <tboston> hmm
[13:32] <tboston> still
[15:38] <peat-psuwit> Have anyone experienced this: When connect to some bluetooth headset, the phone thinks there's a keyboard and won't show OSK.
[15:40] <dobey> peat-psuwit: what headset is it btw?
[15:41] <ogra_> peat-psuwit, i think popey had a bug for "BT selfie buttons" (i.e. a single button that makes your camera take a pick), that likely the same issue (play/pause function on a headset)
[15:42] <ogra_> *pic
[15:42] <popey> bug 1451724
[15:42] <ogra_> they all register as input devices
[15:42] <ogra_> (of type "keyboard"
[15:42] <ogra_> )
[15:43] <peat-psuwit> ogra_ popey: It's Remax RB-S3
[15:44] <popey> doesn't really matter what make/model it is
[15:44] <popey> they're pretty much all the same
[15:44] <ogra_> yeah
[15:47] <peat-psuwit> popey: The phone can't separate between actuall bluetooth keyboard and remote/headset with play/pause button?
[15:47] <popey> indeed
[15:48] <ogra_> peat-psuwit, the device registers as input device of type keyboard
[15:48] <ogra_> even if it is just a one-key-kbd
[15:48] <dobey> i guess the client side needs to handle multiple profiles on a device better
[15:49] <ogra_> yeah
[15:49] <ogra_> or check for specific keys to exist that you definitely only have on a kbd or some such
[17:49] <mterry> bfiller: can you or someone look at https://code.launchpad.net/~phablet-team/camera-app/convergence_fullscreen/+merge/288844 ?
[17:49] <mterry> sister MP to the approved gallery-app and mediaplayer-app ones
[18:02] <mterry> Kaleo: ^ do you have someone in mind to review that
[18:37] <Kaleo> mterry, let me see
[18:38] <Kaleo> mterry, did you write that?
[18:38] <mterry> Kaleo: didn't you?
[18:39] <mterry> Kaleo: well you wrote the commit (in a superceded MP)
[18:39] <Kaleo> mterry, the code yes, that MR though it unknown to me
[18:39] <mterry> Kaleo: Saviq just reproposed it under a team branch so he could merge in trunk
[18:39] <mterry> Kaleo: but no one reviewed the original either (https://code.launchpad.net/~fboucault/camera-app/convergence_fullscreen/+merge/286340)
[18:39] <Kaleo> mterry, it was reviewed anyway
[18:40] <Kaleo> mterry, and the proper one is https://code.launchpad.net/~fboucault/camera-app/convergence_fullscreen_staging/+merge/286885
[18:40] <Kaleo> mterry, we don't merge in trunk
[18:40] <Kaleo> mterry, so, what do you need?
[18:40] <Kaleo> mterry, or rather, what does Michal need?
[18:40] <Kaleo> mterry, he was supposed to ping when the patch we require for that MR lands in the image
[18:40] <Kaleo> mterry, then we could land that MR
[18:41] <mterry> Kaleo: we're trying to land them at the same time in silo 41
[18:41] <Kaleo> mterry, won't happen
[18:41] <Kaleo> mterry, for 2 reasons:
[18:41] <Kaleo> mterry, 1) the app is a click
[18:41] <Kaleo> mterry, 2) we merge things in staging not in trunk
[18:41] <mterry> Kaleo: we have some manual upload click in the silo too
[18:41] <mterry> Presumably built from that branch
[18:42] <Kaleo> mterry, once the silo 41 is landed, I will make a camera release
[18:42] <Kaleo> mterry, not to worry
[18:42] <mterry> mzanetti: ^
[18:55] <bfiller> mterry, Kaleo: yes, gallery and camera should both land after that silo lands but seperately as they are clicks
[19:36] <21WAAFX9X> Hello. Is GPS working yet at Nexus 4? I'm using mako image, not bq.
[19:41] <dobey> GPS should work, yes
[19:53] <mzanetti> bfiller, Kaleo, ack
[20:04] <dobey> oh drive by question that was
[21:41] <matv1> i was wondering when scopes showdown winners will be announced?
[21:44] <popey> matv1: soon
[21:46] <matv1> popey nice. ever considered having all the devs that have an app in the store vote on it?
[21:48] <popey> matv1: people can manipulate votes like that, it's tricky
[21:48] <matv1> popey ah right
[21:49] <matv1> people suck