It sound like some (might be even “many”) people are not aware what the “community meetings” provide:
Depleting the energy of community members by creating additional, formal hurdles and efforts for community members: One has to propose questions at the right place and timely in advance, plus be present at the community meeting, or it will be ignored completely.
A way for Jolla to easily ditch questions from the community, without much visibility. Either by aforementioned formal hurdles, but also happens with most of the questions posed at the “community meetings” (e.g. by stating “We will discuss it internally” and no feedback is ever provided). And knowing that far less people read the “community meeting” logs than this forum.
If all this distraction fails, because someone has the energy to run through steps 1 and 2 multiple times with their question, Jolla’s way out is what you already observed: “Even thought i wouldn’t expect a proper answer.”
Jolla stated, that one purpose of this forum is community interaction, and obviously some Jolla employees read and sometimes even post here. But again, this is usually nothing constructive, like @Thaodan’s “Wait and do it differently, we may come up with something using that, at some time in the distant future”. And we all experienced many times, that “Jolla time” often means “never” (XMPP support, VoLTE support etc.).
It seems to be an inherent part of Jolla’s company culture only to use the community as paying beta testers (and even that is handled very awkwardly), but ignore almost all other input. Especially developers output and enhancements, rangeing from the many, useful Patchmanager Patches which would have been so easy for Jolla to integrate to big, valuable contributions as e.g. @llelectronicsupdated QtWebkit (which was proposed at “community meetings” at least three times: Ignored the first time, “we will look at it” without feedback the second time, “Oh, we forgot to handle that internally” without further feedback the third time).
Jolla could extract so much out of the community and there are so many examples of companies doing that successfully (e.g., RedHat, SuSE), but for some reason they do not seem to be interested (consistently since 2013).
The point is that in the community meeting we can give answers that were discussed internally to be able to give definitive answers. I can just state my opinion on it on how I would to do it or why I see the issue but I can’t decide for my self what will happen.
I think you should know how such things work. Including that I come from the community originally, I value community communication and try to improve relations where I can.
The logs linked on top of every community meeting announcement clearly visible. In any case you have to read them no matter where you post them.
Now you just blatantly post a black picture on what I said. I said how I would do it - I want as everyone else the best solution we can get, so I wrote my idea for it that would result in less duplication and NIH.
I prefer to use existing upstream work before I do my own things.
Please stop with this constant refrain. As a developer I get reasonable support from Jolla in exchange for reasonable effort on my part. I think recent efforts (to 4.1) demonstrate the willingness and stuff like the move to github and obs resurrection are signs of progress.
@olf, while I share many of your experiences, let’s get thread back on track in terms of discussion of encryption implementation. Your points, as well as response of @Thaodan and @poetaster are sufficient and if there is a wish to discuss general community meetings and community interaction with Jolla, please consider opening separate thread. Otherwise we get side tracked and loose the focus. Hence I am not going to reply to the points raised regarding communication between parties and I am sorry that my hesitance regarding raising the issue on the meeting. Still don’t know exact question to ask, but will deal with it if I find it necessary closer to the meeting.
@Thaodan - had to lookup NIH to realize what it means in addition to https://www.nih.gov/ . Find it funny when this term is used together with systemd as a part convincing to use systemd for everything. In principle, unlocking and managing LUKS is far from rocket science and probably the hardest part is now to hook it to GUI. @vknecht pointed to PostmarketOS postmarketOS / osk-sdl · GitLab that I will look into. As Jolla has closed-source implementation of unlocking UI, would have to find some alternative. Not sure I want to use OSK-SDL fully and whether it is able to show up during a boot - this will have to be tested. As pmOS doesn’t use systemd, they have to implement full stack. We are probably on “simpler” position.
Note that Ubuntu Touch and Droidian devs are also looking for LUKS unlocking implementation. So, there is a general interest in getting it done. Let’s see if we can come up with something multiplatform as well.
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
Community contributions are not just code for the OS - look at what @piggz and @rinigus have done with the OBS and Chum recently - look at what @Basil has done for years with OpenRepos.
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.
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
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.
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.
Decryption of /home is implemented using systemd units and scripts that request password(s) via systemd-ask-password
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 /home partition.
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 /home.
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_rawinstead ofargon2i_hash_raw`
It is calling with -id option that should combine d and 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
so we tell you why we don’t comment on them… and people ask anyway… sigh