| Wizzup | https://twitter.com/jkepler/status/1603137923569917953 | 10:28 |
|---|---|---|
| Wizzup | freemangordon: I guess we try to store this in cal, and it just doesn't work on other devices | 10:29 |
| freemangordon | right | 10:30 |
| freemangordon | we have to come-up with CAL replacement | 10:30 |
| freemangordon | or teach libcal to use some file if CAL partition is not available | 10:31 |
| freemangordon | I think this is more sane | 10:31 |
| freemangordon | we can just use nandsim and call it a day | 10:32 |
| Wizzup | nandsim on microsd? | 10:34 |
| freemangordon | nandsim on a loopback | 10:34 |
| freemangordon | or, have a dedicated uSD partition | 10:35 |
| Wizzup | would this be encrypted, or, what's the idea here? | 10:35 |
| freemangordon | I guess having file is better | 10:35 |
| Wizzup | does the n900 contain a hash of the lock code? | 10:35 |
| Wizzup | on cal? | 10:35 |
| freemangordon | yes | 10:35 |
| Wizzup | and I guess it can just be read out? | 10:36 |
| freemangordon | yes | 10:36 |
| Wizzup | ok | 10:36 |
| freemangordon | the point is emulating CAL is not having to rewrite a couple of libs | 10:36 |
| freemangordon | also, before replacing CAL we have to come up with a replacement :) | 10:36 |
| freemangordon | like - where to store the data? | 10:37 |
| Wizzup | I've made this: https://github.com/maemo-leste/bugtracker/issues/684 - let's discuss in irc and summarise there | 10:37 |
| Wizzup | where is cal used, other than for lock codes? | 10:37 |
| Wizzup | like, what other data is stored | 10:37 |
| freemangordon | some certificates, iirc | 10:38 |
| freemangordon | battery calibration data | 10:38 |
| freemangordon | wlan calibration | 10:38 |
| freemangordon | BT/wlan mac addresses | 10:38 |
| freemangordon | device/os data (device type, os release, etc) | 10:39 |
| freemangordon | or, we can do nandsim specific per device | 10:40 |
| freemangordon | and reuse some of the android partitions, somehow | 10:40 |
| Wizzup | I don't think we want to re-use android partitions | 10:40 |
| Wizzup | I'd much prefer loopback to any physical partition reuse | 10:40 |
| freemangordon | loopback on a file on abdroid partition was my idea | 10:41 |
| freemangordon | *android | 10:41 |
| freemangordon | that way reinstalling leste will not lead to data loss | 10:41 |
| freemangordon | als, we shall choose android partition in such a way that reionstalling android will not wipe it as well | 10:42 |
| Wizzup | is data loss really a problem is you reinstall leste? | 10:43 |
| Wizzup | I always found it kinda of crazy that lock code could live through fremantle flashing | 10:43 |
| Wizzup | I don't think the lock code should live through a reinstall | 10:43 |
| Wizzup | in any case I think we agree on loopback | 10:44 |
| freemangordon | Wizzup: the point of lock code surviving reflash is that it is a security feature that shall not be easily removed, like, if the device is stolen | 10:45 |
| freemangordon | so it makes perfect sense to me to survive | 10:45 |
| freemangordon | so, nandsim+loopback on file? | 10:46 |
| freemangordon | btw, IIRC nandsim can do loopback on its own | 10:46 |
| freemangordon | no need to do loopN | 10:46 |
| freemangordon | not 100% sure though | 10:46 |
| Wizzup | I don't think it makes sense since it's easy to reflash any/all android devices and partitions | 10:48 |
| freemangordon | even recovery partition? | 10:48 |
| Wizzup | btw, I don't think our current wlan calibration saves things to cal, just to disk | 10:49 |
| Wizzup | (which is probably not a bad thing) | 10:49 |
| Wizzup | freemangordon: probably depends on the device | 10:49 |
| freemangordon | well, on n900 CAL wln calibration is something written during the production | 10:49 |
| Wizzup | yeah, we do it on first boot | 10:49 |
| freemangordon | ok, we can at least try to come-up with something that is persistent across reinstalls | 10:51 |
| Wizzup | if we end up only storing the lock code in it, I'm not sure if it really matters that much | 10:52 |
| freemangordon | we can store battery calibration data as well | 10:52 |
| freemangordon | but yeah | 10:53 |
| freemangordon | the other option is to get rid of libcal | 10:53 |
| freemangordon | for lockcode at least | 10:53 |
| sicelo | android partition doesn't sound like good idea. there's pinephone | 10:54 |
| freemangordon | so? | 10:55 |
| sicelo | it doesn't have android partition. someday someone might port librem5 too | 10:55 |
| freemangordon | by "android partition" I mean any partition that was created by the manufacturer on either eMMC or nand or whatever internal storage | 10:55 |
| Wizzup | freemangordon: there is just mmc that it flashed by anyone on pinephone | 10:56 |
| Wizzup | so there's no well defined structure or anything | 10:56 |
| freemangordon | I think all of the devices have some partition that is dedicated to storing persistent data | 10:56 |
| Wizzup | but if we don't actually want the lock code to persist, why bother? | 10:57 |
| freemangordon | well, don;t know then | 10:57 |
| freemangordon | but, we want to | 10:57 |
| Wizzup | I don't :D | 10:57 |
| sicelo | :-P | 10:57 |
| freemangordon | otherwise it is more or less useless | 10:57 |
| Wizzup | I've read some horror stories online about people having to use john to unlock their fremantle device | 10:57 |
| Wizzup | that they bought online | 10:57 |
| Wizzup | freemangordon: this is not true, the lock code prevents people from getting immediate access to your phone | 10:58 |
| freemangordon | that's the point | 10:58 |
| Wizzup | and to your data, rather | 10:58 |
| freemangordon | not only | 10:58 |
| sicelo | Wizzup I agree that lock code should persist if possible | 10:58 |
| freemangordon | it should make it as hard as possible | 10:58 |
| Wizzup | it's all 'easy mode' at this point | 10:58 |
| Wizzup | even for the n900 there are relatively easy known ways to defeat it | 10:58 |
| freemangordon | it is not, if you have encrypted fs | 10:58 |
| Wizzup | in any case for the threat model we can disregard nand and libcal, as they add nothing there | 10:59 |
| freemangordon | BTW, maybe we shall integrate lockcode with encryptfs | 10:59 |
| Wizzup | I don't think a digit code is strong enough for fs encryption | 11:00 |
| freemangordon | I think it just protects the keys anyway | 11:00 |
| Wizzup | maybe as a way to unlock the real password/key | 11:00 |
| freemangordon | yes | 11:00 |
| Wizzup | in any case I have doubts as to whether we want to keep libcal if it's just for lock code, if we're going to look at FDE eventually, we probably do something more simple | 11:02 |
| Wizzup | at the same time we have to be careful with how we more forward, if we for example implement lock code now by saving it to some /etc/ file, then any future changes might lock users out of their device | 11:03 |
| Wizzup | how we move* | 11:03 |
| Wizzup | this might be too much of a distraction too, atm :) | 11:03 |
| sicelo | fde is a good goal for the future, yes. it's the modern way to secure things, and users expect it | 11:04 |
| Wizzup | wonder if we want the system data to separate from that | 11:30 |
| Wizzup | probably not I guess | 11:30 |
| Wizzup | if it was me I'd want to add plausible deniability | 11:31 |
| sicelo | Wizzup: btw the GH issue you made is a duplicate of https://github.com/maemo-leste/bugtracker/issues/354. might make sense to close 354 in favor of the new one | 12:21 |
| Wizzup | hm | 12:22 |
| Wizzup | posted that it's similar | 12:27 |
| Wizzup | didn't close yet | 12:27 |
| norayr | heh, i found some battery i ordered a couple of years ago for droid4. and it seems in not bad shape. | 13:11 |
| norayr | i charged it fully yesterday and it said in the evening it'll work for 28 hours. | 13:11 |
| norayr | i left it overnight without charge, turned on. | 13:11 |
| norayr | and now it has 57% of charge. | 13:12 |
| norayr | that other battery would already be dead. | 13:12 |
| norayr | now, since this is a 'new' battery should i leave it till it dies to calibrate? | 13:12 |
| norayr | it is painful to see batteries die. | 13:12 |
| norayr | (btw droid3 under android leaves for 3 or maybe 5 days without charge) | 13:15 |
| Wizzup | no surprise there since we don't do OFF mode | 13:17 |
| Wizzup | (yet) | 13:18 |
| Wizzup | uvos: I think my d4 gets warmer when left on charger on 6.1, did you notice any diff? | 13:24 |
| uvos | Wizzup: no | 13:49 |
| uvos | Wizzup: i also have it charge at 1000mA so it allways gets pretty warm | 13:49 |
| uvos | 5 days on android is pretty poor for d4 at least | 13:53 |
| uvos | but i gues d3 has smaller and older battery | 13:53 |
| norayr | > since we don't do OFF mode | 15:32 |
| norayr | that would be incompatible with running chats right? i prefer chats. | 15:32 |
| norayr | folks shell i let the battery die since it is now put in droid4? for calibration? | 15:32 |
| uvos | norayr: no off mode is not suspend | 15:55 |
| uvos | its simply not supported in the mainline kernel | 15:55 |
| uvos | otherwise form a user perspective its exactly the same as RET | 15:56 |
| uvos | it just takes more energy and time to enter/exit off so it only makes sense if the device is less busy than for RET | 15:56 |
| uvos | android dose not use suspend, this was only true on the very first android devices (htc dream/ magic) and some chineese socs. | 15:59 |
| sicelo | ret/off + suspend ... i suppose that would mean one charge cycle per month :p | 16:18 |
| norayr | but i don't know what is RET. :/ | 23:07 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!