elastic_dog has joined #maemo-leste
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #maemo-leste
Pali has quit [Quit: Pali]
xmn has quit [Quit: ZZZzzz…]
elastic_dog has quit [Remote host closed the connection]
elastic_dog has joined #maemo-leste
thunderysteak has quit [Ping timeout: 260 seconds]
xmn has joined #maemo-leste
Daanct12 has joined #maemo-leste
Daanct12 has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 268 seconds]
Daanct12 has joined #maemo-leste
joerg has quit [Ping timeout: 272 seconds]
joerg has joined #maemo-leste
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #maemo-leste
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Read error: Connection reset by peer]
System_Error has quit [Ping timeout: 255 seconds]
Daaanct12 has quit [Remote host closed the connection]
Twig has joined #maemo-leste
<Wizzup> freemangordon: I guess we try to store this in cal, and it just doesn't work on other devices
<freemangordon> right
<freemangordon> we have to come-up with CAL replacement
<freemangordon> or teach libcal to use some file if CAL partition is not available
<freemangordon> I think this is more sane
<freemangordon> we can just use nandsim and call it a day
<Wizzup> nandsim on microsd?
<freemangordon> nandsim on a loopback
<freemangordon> or, have a dedicated uSD partition
<Wizzup> would this be encrypted, or, what's the idea here?
<freemangordon> I guess having file is better
<Wizzup> does the n900 contain a hash of the lock code?
<Wizzup> on cal?
<freemangordon> yes
<Wizzup> and I guess it can just be read out?
<freemangordon> yes
<Wizzup> ok
<freemangordon> the point is emulating CAL is not having to rewrite a couple of libs
<freemangordon> also, before replacing CAL we have to come up with a replacement :)
<freemangordon> like - where to store the data?
<Wizzup> I've made this: https://github.com/maemo-leste/bugtracker/issues/684 - let's discuss in irc and summarise there
<Wizzup> where is cal used, other than for lock codes?
<Wizzup> like, what other data is stored
<freemangordon> some certificates, iirc
<freemangordon> battery calibration data
<freemangordon> wlan calibration
<freemangordon> BT/wlan mac addresses
<freemangordon> device/os data (device type, os release, etc)
<freemangordon> or, we can do nandsim specific per device
<freemangordon> and reuse some of the android partitions, somehow
<Wizzup> I don't think we want to re-use android partitions
<Wizzup> I'd much prefer loopback to any physical partition reuse
<freemangordon> loopback on a file on abdroid partition was my idea
<freemangordon> *android
<freemangordon> that way reinstalling leste will not lead to data loss
<freemangordon> als, we shall choose android partition in such a way that reionstalling android will not wipe it as well
<Wizzup> is data loss really a problem is you reinstall leste?
<Wizzup> I always found it kinda of crazy that lock code could live through fremantle flashing
<Wizzup> I don't think the lock code should live through a reinstall
<Wizzup> in any case I think we agree on loopback
<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
<freemangordon> so it makes perfect sense to me to survive
<freemangordon> so, nandsim+loopback on file?
<freemangordon> btw, IIRC nandsim can do loopback on its own
<freemangordon> no need to do loopN
<freemangordon> not 100% sure though
<Wizzup> I don't think it makes sense since it's easy to reflash any/all android devices and partitions
<freemangordon> even recovery partition?
<Wizzup> btw, I don't think our current wlan calibration saves things to cal, just to disk
<Wizzup> (which is probably not a bad thing)
<Wizzup> freemangordon: probably depends on the device
<freemangordon> well, on n900 CAL wln calibration is something written during the production
<Wizzup> yeah, we do it on first boot
<freemangordon> ok, we can at least try to come-up with something that is persistent across reinstalls
<Wizzup> if we end up only storing the lock code in it, I'm not sure if it really matters that much
<freemangordon> we can store battery calibration data as well
<freemangordon> but yeah
<freemangordon> the other option is to get rid of libcal
<freemangordon> for lockcode at least
<sicelo> android partition doesn't sound like good idea. there's pinephone
<freemangordon> so?
<sicelo> it doesn't have android partition. someday someone might port librem5 too
<freemangordon> by "android partition" I mean any partition that was created by the manufacturer on either eMMC or nand or whatever internal storage
<Wizzup> freemangordon: there is just mmc that it flashed by anyone on pinephone
<Wizzup> so there's no well defined structure or anything
<freemangordon> I think all of the devices have some partition that is dedicated to storing persistent data
<Wizzup> but if we don't actually want the lock code to persist, why bother?
<freemangordon> well, don;t know then
<freemangordon> but, we want to
<Wizzup> I don't :D
<sicelo> :-P
<freemangordon> otherwise it is more or less useless
<Wizzup> I've read some horror stories online about people having to use john to unlock their fremantle device
<Wizzup> that they bought online
<Wizzup> freemangordon: this is not true, the lock code prevents people from getting immediate access to your phone
<freemangordon> that's the point
<Wizzup> and to your data, rather
<freemangordon> not only
<sicelo> Wizzup I agree that lock code should persist if possible
<freemangordon> it should make it as hard as possible
akossh has joined #maemo-leste
<Wizzup> it's all 'easy mode' at this point
<Wizzup> even for the n900 there are relatively easy known ways to defeat it
<freemangordon> it is not, if you have encrypted fs
<Wizzup> in any case for the threat model we can disregard nand and libcal, as they add nothing there
<freemangordon> BTW, maybe we shall integrate lockcode with encryptfs
<Wizzup> I don't think a digit code is strong enough for fs encryption
<freemangordon> I think it just protects the keys anyway
<Wizzup> maybe as a way to unlock the real password/key
<freemangordon> yes
<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
<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
<Wizzup> how we move*
<Wizzup> this might be too much of a distraction too, atm :)
<sicelo> fde is a good goal for the future, yes. it's the modern way to secure things, and users expect it
<Wizzup> wonder if we want the system data to separate from that
<Wizzup> probably not I guess
<Wizzup> if it was me I'd want to add plausible deniability
uvos has joined #maemo-leste
<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
<Wizzup> hm
<Wizzup> posted that it's similar
<Wizzup> didn't close yet
Pali has joined #maemo-leste
<norayr> heh, i found some battery i ordered a couple of years ago for droid4. and it seems in not bad shape.
<norayr> i charged it fully yesterday and it said in the evening it'll work for 28 hours.
<norayr> i left it overnight without charge, turned on.
<norayr> and now it has 57% of charge.
<norayr> that other battery would already be dead.
<norayr> now, since this is a 'new' battery should i leave it till it dies to calibrate?
<norayr> it is painful to see batteries die.
<norayr> (btw droid3 under android leaves for 3 or maybe 5 days without charge)
<Wizzup> no surprise there since we don't do OFF mode
<Wizzup> (yet)
<Wizzup> uvos: I think my d4 gets warmer when left on charger on 6.1, did you notice any diff?
<uvos> Wizzup: no
<uvos> Wizzup: i also have it charge at 1000mA so it allways gets pretty warm
<uvos> 5 days on android is pretty poor for d4 at least
<uvos> but i gues d3 has smaller and older battery
<norayr> > since we don't do OFF mode
<norayr> that would be incompatible with running chats right? i prefer chats.
<norayr> folks shell i let the battery die since it is now put in droid4? for calibration?
Twig has quit [Remote host closed the connection]
thunderysteak has joined #maemo-leste
<uvos> norayr: no off mode is not suspend
<uvos> its simply not supported in the mainline kernel
<uvos> otherwise form a user perspective its exactly the same as RET
<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
<uvos> android dose not use suspend, this was only true on the very first android devices (htc dream/ magic) and some chineese socs.
<sicelo> ret/off + suspend ... i suppose that would mean one charge cycle per month :p
xmn has joined #maemo-leste
Twig has joined #maemo-leste
uvos has quit [Quit: Konversation terminated!]
Twig has quit [Remote host closed the connection]
<norayr> but i don't know what is RET. :/
akossh has quit [Quit: Leaving.]