Sunday, 2020-10-18

malThaodan: are you using --fetch-submodules? try without it00:35
Thaodanmal: it was something with the manifest , used rinigus unchanged manifest and everything was fine01:10
Thaodanwent not further, had to extend my build scripts01:11
ThaodanRecursion is complicated :D01:22
rinigusThaodan: morning! Not clear when that error was hit. Is it with some auto-generated manifests (assuming it from your statement regarding unchanged manifest)?05:47
archer_3123_I was wondering if anyone was on here that's working on the pinephone port06:00
riniguspiggz: and that's why there is no point in adding 'encryption' to the ports:
r0kk3rzthats a pretty easy hack09:25
T42<adampigg> yeah, interesting09:25
rinigusI guess if we want to have proper encryption, we should somehow allow users to generate and input long(er?) key.09:29
r0kk3rzor, they should not be dumb and salt + rehash it09:30
rinigusif you know the algorithm of salt+rehash, it should be trivial to brute force that as well.09:34
rinigus(if I understand that correctly)09:34
r0kk3rzish, but slower09:34
r0kk3rzwhich is the point09:34
r0kk3rzyou can brute force anything, its a question of how long it takes09:35
r0kk3rzif you hash the pin 100x, then any brute forcing is 100x slower for eg09:35
rinigusyes, I agree that you can brute force anything. we just have to make it impractical. just salt with rehash will not probably impact it that much09:36
rinigusnow, don't we have some "secure" storage on devices? something that can generate random key and used as a salt with pin? assuming that this random key cannot be lifted from device ...09:37
rinigusdon't know whether such secure storage exists, please correct09:38
r0kk3rzsome probably do yeah09:38
Thaodanrinigus: i tried updating to Android 9 r6111:33
rinigusThaodan: I see. such update is going to be very messy - probably would require reflash of the device.11:34
rinigus... or is it done as a part of updates for sony devices via rpm?11:34
rinigusdon't think so11:35
Thaodanit's just a minor update in the same version11:36
rinigusbut in this sense, we better keep aosp9 as it is, with the same version as we have on devices.11:39
rinigusin a sense as it is on official devices - we shouldn't touch base unless there is a major reason to do so.11:39
rinigusThaodan: now some good reasons for reflash: switch to aosp10, switch to aarch64 :)11:40
Thaodaneven that can work without reflaah11:40
Thaodanat least without manual reflash11:41
rinigusprobably we can update system & vendor without reflash. but that is some effort and uncharted so far. (I hope I understood you right)11:42
rinigusThaodan: ^11:42
Thaodanyou did11:43
Thaodanthe problem with updating major versions is updating odm but that's easier as community port as you don't necessary have the proper process to distribute the odm partition11:45
rinigusThaodan: note that in case of tama, any system & vendor update means recompilation for 6 devices. at least 3 + 3 via patching, whatever is easier.11:45
rinigusThaodan: odm is this sony-distributed bit?11:46
rinigusgoing to oem_{a,b}?11:47
Thaodanit is but it's the major problem as it contains the blobs you need to update but can't distribute11:47
Thaodanin our case we could just request the user to download them and put them somewhere on the device11:48
rinigusThaodan: as far as I have seen, on android aosp, you make an update, shutdown, and then fastboot flash oem. so, it is responsibility of the user to perform it11:49
rinigusin case of aosp9, we already have the latest version of that blob installed. for aosp10, new will be needed11:50
ThaodanIf anyone wants to build sony tama devices he can now do so automatically with my hadk-build tools:
rinigusThaodan: very nice. so how does it work? which parts does it compile?13:29
Thaodanall of them14:38
Thaodanexcept some I have forgot for mw14:39
*** amccarthy_ is now known as amccarthy21:29
T42Harold Ballard %lastname% was added by: Harold Ballard %lastname%23:34

Generated by 2.17.1 by Marius Gedminas - find it at!