systemd already has integration for that so why should we duplicate work?
It seems that you’re feeling frustrated. I’ve been there (I too originally came from the community), Do rest assured that our intention is to work with the community.
I’ll try and answer some points - I apologise if I miss any context and I’m very much just getting up to speed with community life after a long hiatus working on other personal projects. Please be gentle
I think you should also bear in mind that Jolla, as an organisation, has commercial interests and is not a pure open source project so we do acknowledge that these limit our ability to share future plans and we’re also very limited in the resources (basically time) that any individual can allocate to the community - I think all of us do at least some of community work on our own time and as community members.
Formalising things is a double-edged sword. It makes it clear how to get things done and can also be seen as a barrier.
As Thaodan said - we, as sailors, need to ensure that what we communicate is in fact what’s being planned, usually by another busy team. This needs us to ask around and often discuss what to say.
Questions are not a one-way street. We would like discsussion so asking for people to be present to ask their questions (or to nominate a proxy to do it for them) happened when people would ask questions and not be present for the discussion afterwards - that’s reasonable isn’t it?
As an aside these community meetings are not far off what I (as a community guy) tried to get way back in MeeGo times.
So you would like us to track these promises to respond in a more formal manner? I’ll discuss it internally
Seriously, I agree and will ask Sim who chairs the meetings to say how he handles this.
(Actually someone made a suggestion… would you like to take on that role/responsibility? Serious offer.)
This usually is a response to questions about future plans or dates (like Qt6 etc). Of course keeping packages updated is in our plans - but plans change all the time and making public statements about them and then failing to meet those dates would result in more ‘feedback’ so we tell you why we don’t comment on them… and people ask anyway… sigh
It’s going to vary and some is not going to be what may be hoped for (especially when it’s about plans, like VoLTE, XMPP as above). Also bear in mind that we don’t and can’t plan externally. There are simply too many commercial considerations that affect prioritisation and direction.
Saying sailors “usually” offer “nothing constructive” seems a bit harsh don’t you think?
Aside if you want to follow the work then please see the public git repos in the relevant packages.
We do take extensive code from the community - I think Damien is a great example of that.
Sometimes however I think we need to find a way to say “sorry, that approach doesn’t fit” and sometimes it’s difficult to find a way to say that. Maybe we should hire the old Linus?
In your previous point you say “only to use the community as paying beta testers” and now we should “extract so much out of the community”? It’s a hard balance isn’t it.
Contributing code to packages and an OS is hard. It takes a lot of time and energy - and often specialised knowledge.
Quite a few people who work for Jolla would differ - because that’s how they came to work for Jolla
Anyway, I suppose I’m trying to show you the other perspective. The passion (and frustrations) that comes in from the Jolla side (do you seriously think that individual sailors don’t want to share our plans and shout about what we’re working on?) . The community and company may not always be perfectly aligned and there may be miscommunication on both sides - but there is a real caring on both sides.
Hope this comes across as a constructive post…
No, I don’t want to duplicate it if I can avoid it. So far, hwcrypt implements missing functionality and is something that would be needed anyway if we want to use Android HW backed keystore to assist with LUKS password/passkey generation. Nothing duplicating here.
Now, ideally I should have systemd-ask-password daemon implemented in yamui or something else (OSK comes in here as an alternative) to provide UI for user interaction in the unlocking process. Here, Jolla’s solution is closed source and cannot be even checked/expanded, unfortunately. So, have to come up with something different.
If we want to let systemd to unlock the encryption, it can be done by
- asking for user password
- generation of LUKS password key (
scrypt PWD | hwcrypt | scrypt > /tmp/luks/home-pwkey)
- feeding LUKS pwd key location to systemd through boot argument
- removing pwd key after unlocking
At least that is the scheme used for TPM2 password protected secrets. Except you don’t even need to rm pwd key as it is done in initrd and before switching root.
For FIDO2 and others not asking for password, systemd can handle it all automatically. So, that would be easier.
As you see, main obstacle for me now is to get UI up where I can get user password.
As I plan to use Android Keystore as one of the mechanisms for LUKS unlocking, I have moved /home mounting further down in the boot sequence by changing
/etc/fstab configuration as required for systemd.mount. As a result, also regular Silica UI can be used through
hwcomposer. While there are limitations, they are relatively minor when compared to writing UI in something like minui.
@Thaodan - are you able to share systemd update plans? Asking in the context of UI for unlocking.
In principle, I can write a small app that asks for password and tries to unlock by itself. This is what was done by postmarketOS (Osk-sdl - postmarketOS), but they don’t have systemd anyway. Similar was done by nixOS/Mobile - stage-1: Add interactive LUKS decrypting by samueldr · Pull Request #234 · NixOS/mobile-nixos · GitHub.
Alternative is to write systemd-ask-password agent that will fire up UI asking for password. That is not a rocket science either and as we can use systemd working implementations I think it will be similar time in doing this as a dedicated app.
I am inclined to go systemd-ask-password route. That would allow to have flexibility in unlocking volumes and for whatever passwords are needed while booting.
Question is just how to make systemd-ask-password UI streamlined and not confusing for users. Namely, we could have multiple passwords for LUKS volume opening requested at the same time:
- password for generation keyfile using keystore. that one has to go
- recovery or any other plain-text password
- some password to unlock FIDO2 device or similar
As it is all coupled to password checking (read, it takes time), will have figure out how to make it reasonable for users. But that will come in the polishing phase…
I don’t know nothing about encryption, but I wanna say: fingertip or face unlocking are most wunerable and stupid. When user is under arrest, cops can simple touch fingertip sensor to handcuffed guy. Same with face. So password and master delete pass is crucial.
project repositories have moved into Sailfish OS Open · GitHub . You could follow GitHub - sailfishos-open/sailfish-device-encryption-community: Support for device storage encrypti issues as a progress indicator.
Decryption of /home is implemented using systemd units and scripts that request password(s) via
Passwords can be entered through dedicated UI which is started during a boot. For that, keyboard is available (English chars, numbers, symbols).
Proof of concept has been reached with the full text password, either plain or piped through Android hardware bound key for signing, used to decrypt
Solution should work for ports based on official devices approach (such as Sony Tama devices) and regular unofficial ports. Latter could just use loopback file for encrypting
More work is needed, but it is getting there.
- instead of
scrypt, I decided to use
argon2as that is fully packaged already as a part of ownKeepass efforts. In addition, as LUKS accepts larger key files as well, I skipped post-processing after signing with hardware bound key. So, key derivation scheme for Android keystore backed scheme is
echo UserPassword | argon2 ... | hwcrypt. Implementation at sailfish-device-encryption-community/hwcrypt-key at master · sailfishos-open/sailfish-device-encryption-community · GitHub
Will now work on enabling encryption on devices via GUI, as a part of the first boot.
Great progress! argon2 is the original, no 2i or 2d? I don’t think it ‘really’ matters in our case, but I’m not sure.
See used command:
That doesn’t tell me which version of argon2. libargon-tools in 4.1 same as in 3.4?
OK, I misunderstood. It is from Chum: GitHub - sailfishos-chum/libargon2 . So same version for all supported versions.
Thanks! I’ll have a look!
EDIT: in the original, it looks like the default is to build all the variants (Argon2i, Argon2d, and Argon2id are parametrized by:…)
use Argon2d instead of Argon2i callargon2d_hash_raw
Are these available?
It is calling with
-id option that should combine
i after each other. As far as I understood, this is a recommended way of key derivation by argon2
Cool. I’m going to have to try this, but it probably makes more sense to get version 4.1 running on my second volla phone, or?. I also have an fp2 with 3.4 that might do.
Sadly, I still haven’t been able to flash 4.1 on the volla.
I am writing now startup wizard and settings app. It has started with support library which would be responsible for the actions. It would make sense to wait with trials until those are sorted. Then testing by myself, testing by you, and I hope someone can take time and review the code. After that, roll out
So, in this respect - you have few days to sort out Volla situation
Cool. I’ll get the next test device going.
Got first version of setup wizard written and managed to hit …
Edit: found a workaround
@piggz has made a video with the startup: Pinephone /home encryption using SailfishOS - YouTube
We have just reached the state where all the initially planned functionality is ready. All packages involved in providing encryption solution as discussed above are tagged with their first release tags. I am planning to roll out this solution on Sony Tama port and I hope other devices will follow.