It’s nice to have the option to use a passcode when I switch on my phone.
I personally preferred not to have it and have a phone which boots all the way to the GUI when switched on.
I had to reinstall my phone to debug some of the bugs in the latest version of SailfishOS.
I was forced to use the new passcode on boot.
This feel like nasty user design - to decide that the phone now NEEDS user interaction just tio switch on, without asking the user if that’s what they want.
Do you mean lock screen code, or encryption code? Lock screen code can be disabled.
This has been asked before - and yes, even the encryption can be disabled (before first boot!).
Search and you shall find.
Your reply would be so much more helpful if you either explained how to do it or provided a link rather than saying “search and you shall find” Perhaps they have already searched and not found?
… and to boot into recovery mode: https://together.jolla.com/question/202775/using-recovery-to-access-the-root-and-home-file-system/
Seems like the most appropriate topic to share this:
If you are familiar with linux, similar result ( boot without asking for password ) can also be achieved after encryption and without recovery mode.
As root ( devel-su ):
pkcon install cryptsetup cryptsetup-reencrypt
### test your password
cryptsetup --verbose open --test-passphrase /dev/mapper/sailfish-home
### verify luks
cryptsetup luksDump /dev/mapper/sailfish-home
### generate keyfile
dd if=/dev/urandom of=/root/home_keyfile bs=512 count=4
### add it
cryptsetup luksAddKey /dev/mapper/sailfish-home /root/home_keyfile
### verify it
cryptsetup --verbose open --key-file /root/home_keyfile --test-passphrase /dev/mapper/sailfish-home
### recheck your password
cryptsetup --verbose open --test-passphrase /dev/mapper/sailfish-home
vi /etc/crypttab ### change the third field, key file, from none to /root/home_keyfile
reboot ### and test
Obviously encryption will be useless, but we don’t need recovery mode and didn’t lose any data.
Hmm, interesting.
So this could enable some kind of “panic mode” where upon some action of the user this new key file is deleted, rendering the device permanently encrypted without known key. (Also, it probably will not boot until re-flashed.)
Is there a way to remove the existing PIN/password completely?
As far as I know, there can be only limited amount of keys in the header, so does the counter/slot roll over back to 0 if you try to add new key after the limit is reached?
Also for the panic mode, if the aim is to permanently encrypt the device without anyway to recover, wouldn’t it be just as easy to overwrite the LUKS header and force reboot?
Sure but removing a file is much easier and failure-resistant than dd-ing some partition in a certain place.
(And isn’t there the possibility that zeroing would leave the header intact on some part of the flash memory? What with wear levelling and things.)
Yes, but with overwriting, you could implement the panic mode -feature also to phones without a key-file. I’m not trying to sell this as an better option over anything, this was just something that came to my mind when I read your thought on the key-file.
Probably and this sounds like a real concern to me, but would it help if we kept overwriting the header in a loop first?