08:00:40 <flypig> #startmeeting Sailfish OS, open source, collaboration -- 20th January 2022
08:00:40 <sailbot> Meeting started Thu Jan 20 08:00:40 2022 UTC. The chair is flypig. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:40 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:49 <flypig> #info Meeting information and agenda can be found here:
08:00:53 <flypig> #link https://forum.sailfishos.org/t/community-meeting-on-irc-20th-january-2022/9549
08:01:01 <flypig> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please respect the timings. As an "NQT", please also go gentle on me today, try not to get too rowdy.
08:01:14 <flypig> It's my first time :)
08:01:20 <flypig> It's my first time :)#topic Brief introduction (5 min). Please prefix your name/handle with #info
08:01:27 <flypig> As you can tell.
08:01:30 <flypig> #topic Brief introduction (5 min). Please prefix your name/handle with #info
08:01:34 <ApB> i don't think i've seen a meeting get rowdy
08:01:52 <flypig> Let's hope this isn't the first then!
08:02:17 <Nico> #info Nico, community/dev who successfully pushed for a close button
08:02:25 <ExTechOp> #info Otto Mäkelä, community
08:02:42 <karry> #info Lukáš Karas, community, developer
08:03:02 <jpetrell> #info Joona Petrell, sailor at Jolla
08:03:18 <sledges> #info Simonas Leleiva -- privateer for Jolla
08:03:19 <spiiroin> #info Simo Piiroinen, sailor at Jolla
08:03:29 <flypig> #info David Llewellyn-Jones, sailor @ Jolla
08:04:44 <Thaodan> #info Björn Bidar, sailor @ Jolla
08:07:08 <flypig> It's nice to see everyone. Let me also take this opportunity to thank sledges for his superb and tireless chairing of the community meetings over the last two years. I hope you'll join me in sharing your appreciation. Thank you sledges!
08:07:26 <Nico> Hurray, sledges! <3
08:07:48 <sledges> take it away, flypig! :))
08:07:58 <flypig> #topic Open the source code of the entire system (10 minutes -- asked by ddobrev)
08:08:06 <flypig> First the question that was asked.
08:08:12 <flypig> #info <ddobrev> Some parts of the system, such as the GUI (Silica) are still proprietary.
08:08:16 <flypig> #info <ddobrev> This repels many users and contributors - some of the latter have explicitly stated this and the old Qt as the reasons they left Sailfish for.
08:08:21 <flypig> #info <ddobrev> I'm not talking about the Android layer the opening of which while still useful it seems to me is legally impossible.
08:08:24 <flypig> #info <ddobrev> I only mean the OS itself, and perhaps the built-in applications.
08:08:35 <flypig> And here is the answer we prepared earlier, before we continue the discussion.
08:08:42 <flypig> #info <Jolla> Jolla is an advocate of open source. We benefit from it, we contribute to it and we have an open development model for our open source components (we invite PRs, we invite anyone to comment on our PRs).
08:08:50 <flypig> #info <Jolla> We aim to fulfil both the letter and the spirit of the open source licences we work with. Internally, we often have discussions about open-sourcing components.
08:08:57 <flypig> #info <Jolla> That's the context. However Jolla doesn't work in a vacuum. We have a business model which funds the development of Sailfish OS, and right now that business model relies on some proprietary components (I'll share a link on this below).
08:09:03 <flypig> #info <Jolla> So the answer is that we have no short-term plans to release Silica as open source. In the longer term this could change.
08:09:08 <flypig> #info <Jolla> I cannot emphasise enough that we open up components whenever we can.
08:09:12 <flypig> #info <Jolla> For example, recent new components have been released as open source: WebView/MPL-2 and WebAuth/BSD. We also acknowledge the importance of open source to our community; we do not underestimate it.
08:09:16 <flypig> #link https://techcrunch.com/2021/08/25/jolla-hits-profitability-ahead-of-turning-ten-eyes-growth-beyond-mobile/
08:09:39 <flypig> A bit of a long answer, but hopefully clear.
08:10:14 <fridlmue> #info fridlmue - community (little late, sorry)
08:10:30 <flypig> I don't see ddobrev here, but maybe others have comments.
08:10:37 <dcaliste> #info Damien Caliste, community
08:10:58 <ApB> well its a subject that has been discussed foa ages
08:11:03 <Nico> I think it would be great to have a few of the more visible part open. Those are usually the most accessible (fixing call stuff is hard, fixing a button much easier) and they are often what people have the most opinions about. For example it is really awesome the browser is open, because I could just patch it to have a close button for the last few months and even upstream that :D
08:11:28 <Nico> But maybe they are already, I always have a hard time telling what is open and what is not
08:12:25 <Nico> I understand, why some parts are closed, so no need to discuss that I guess, but having more stuff open is of course appreciated <3
08:12:38 <dcaliste> As a side note on the topic, https://github.com/sailfishos/mapplauncherd-booster-silica was published recently, while it was proprietary before. Not a big deal, because not very useful stand-alone, but looking at the git history (because it came with its full history), show some background about silica.
08:13:03 <ApB> personally i don't mind closed stuff as long as they get improved and bugs are fixed.
08:13:33 <ApB> many of the close jolla apps need some love and care
08:13:39 <Nico> The mapplauncher-booster could probably use some docs or at least a description, what it is :3
08:13:49 <flypig> #info mapplauncerd-booster-silica was open sourced recently, with interesting silica history
08:13:52 <flypig> #link https://github.com/sailfishos/mapplauncherd-booster-silica
08:14:17 <Nico> Email app would be great to have open :3
08:14:24 <Thaodan> Nico: it is a booster for mapplaucherd specific to silica apps
08:14:31 <dcaliste> I fully agree with Nico about the browser being open source and the work done by Jolla to "librify" xulrunner and gecko so one can freely play with QML text files and change the browser layout.
08:14:35 <Thaodan> I think mapplauncherd needs more docs
08:14:48 <Nico> Thaodan: I see, ty! Someone should add that to the github description :3
08:15:37 <ApB> the other issue how willing is jolla to accept modifications by the community. ie the brower design is a bit bad to put it mildly
08:15:45 <rinigus> email, accounts are also asking for being open. but it is clear that the current business model requires some components to be closed
08:16:03 <ApB> and damien wrote some patches for it
08:16:11 <flypig> ApB, we just accepted a community PR to the browser yesterday, I believe.
08:16:14 <Nico> ApB: They merged one contribution at least after some discussion. It just takes a while :3
08:16:20 <Thaodan> Personally I think it really depends on what a customer wants, if there's a customer want wants invest into foss apps that will change. The person that pays has the say.
08:16:25 <Nico> flypig: Yes, mine! <3
08:16:28 <ApB> didn't notice that. appologies
08:16:29 <Thaodan> Thats not really specific to this case thou.
08:16:34 <flypig> Ah, nice, thanks Nico!
08:16:45 <dcaliste> flypig, indeed, see https://forum.sailfishos.org/t/browser-redesign-in-sailfish-4-2-feedback-thread/7867/105
08:16:57 <Nico> Thaodan: I did pay a few bucks at least :3
08:17:14 <Nico> How much would I need to pay per app to have it open? ;p
08:17:20 <dcaliste> Thank you Nico for your devotion to push this patch forward by the way !
08:17:25 <flypig> #info Nico's recent PR accepted to the browser.
08:17:28 <flypig> #link https://forum.sailfishos.org/t/browser-redesign-in-sailfish-4-2-feedback-thread/7867/105
08:17:29 <ExTechOp> I remember how one of the most impressive parts of my first impression of Sailfish was that all the different communications channels (phone, text, email, chats,...) got integrated into the same UI.
08:17:29 <ExTechOp> This seems to have fallen somewhat onto the wayside as things have progressed, and eg. chat protocols don't have such OS support any longer.
08:17:29 <ExTechOp> Is this a matter of people just not doing this, or are there some closed-source hurdles on the OS side?
08:17:30 <ApB> Thaodan: can you find a customer that will demand newer QT :P
08:17:44 <flypig> Just a minute to go on this topic.
08:18:02 <Nico> dcaliste: No worries, I was tired of having to reapply the patch anyway. Now I just need to reapply yours every time :3
08:18:11 <lolek> ApB: I think never QT would be more problematic than just paying customer
08:18:34 <flypig> Time to move on I'm afraid. Let's continue the discussion in General later!
08:18:40 <Thaodan> ApB: I think new customers are always nicer so please do ;)
08:18:53 <flypig> #topic lowmemory killer and memory state reporting (10 minutes -- asked by Karry)
08:19:03 <flypig> Again, here's some more info about the topic.
08:19:10 <flypig> #info <Karry> Sailfish OS has mechanism for notifying applications when system has not enough memory (by mce daemon, via D-Bus api).
08:19:15 <flypig> #info <Karry> Together with lowmemory killer (kernel module) that kills applications when memory is under pressure, it maintain free memory reserve.
08:19:18 <flypig> #info <Karry> It is good idea. But it is not working properly on Sony mobiles without memnotify api.
08:19:23 <flypig> #info <Karry> Mce is counting free memory wrongly with cgroup api. And kernel lowmemory killer has multiple downsides. See:
08:19:28 <flypig> #link https://forum.sailfishos.org/t/4-1-0-24-xperia-10-ii-unknown-memory-level-reported-by-mce/6856
08:19:31 <flypig> #info <Karry> and my blog post:
08:19:34 <flypig> #link https://www.karry.cz/en/karry/blog/2021/11/07/sailfishos_memory.
08:19:36 <flypig> #info <Karry> So my question is, what are Jolla's plan in this area? Specifically:
08:19:39 <flypig> #info <Karry> - do Jolla want to use lowmemory killer in kernel in future, or migrate to user-space daemon, similar as Android does?
08:19:41 <ApB> Thaodan: if i start an automotive company i'll be more than pleases to get jolla to help with the SW in the car. its just that i am missing a few billions :P
08:19:44 <flypig> #info <Karry> - do you agree with my conclusion that mce computes memory incorrectly? :-) what api to use, when memnotify
08:19:47 <flypig> #info <Karry>   is not available? Cgroup don't provides enough details. I can imagine just parsing `/proc/meminfo`...
08:19:56 <flypig> And the answer we prepared in advance.
08:20:00 <flypig> #info <Jolla> We read your blog post on the topic with interest back in July and we're grateful for your work on this.
08:20:07 <flypig> #info <Jolla> Your post did trigger us to look in to this in more detail, but work on this is still ongoing and we have made changes as a result. The latest situation is that it is still unclear if there is actually an issue on X10II after all of the current PRs are taken into use.
08:20:12 <flypig> #info <Jolla> So in short, we are studying the issue, but it's too early to say anything about what we eventually end up doing.
08:20:16 <flypig> #info <Jolla> To try to answer your ancillary questions directly:
08:20:23 <flypig> #info <Jolla> 1. Since there might not be an android low memory killer in future kernels as an oom-killer, we are looking in to the latter. For example systemd-oomd and Androd lmkd are options for userspace oom killers, but we're also considering others.
08:20:28 <flypig> #info <Jolla> 2. We agree with your conclusions, yes, but haven't yet come to a conclusion about what API is going to work best.
08:20:39 <flypig> #info <Jolla> To add some context the lowmemory killer is a kernel module from Android that is an implementation of an oom-killer that was maintained by Google but replaced with the userspace oom-killer lmkd. We'll provide some links at the end.
08:20:42 <flypig> #info <Jolla> We are actively working on it and we'd welcome more discussion on the topic.
08:20:48 <flypig> #link https://source.android.com/devices/tech/perf/lmkd
08:20:52 <flypig> #link https://man.archlinux.org/man/systemd-oomd.8
08:21:22 <Nico> The answers this time are lengthy, I like it :D
08:21:53 <flypig> That's good Nico, it just takes a while to get through :)
08:21:57 <flypig> That's the answer. karry feel free to elaborate on your original point.
08:22:18 <karry> Thanks for the answers!
08:23:06 <karry> Great to hear that you are evaluating it. Is the discussion public somewhere? Or it was internal?
08:24:03 <flypig> I think the answer is talking about internal discussion, but it can be discussed more on the forum, and here of course.
08:24:14 <karry> I will look to systemd-oomd, I am not aware of that... The key from my point is to use the same metrics in mce (memory reporting) and low-memory-killer...
08:25:21 <Thaodan> Low-memory-killer is an Android thing we just reused that.
08:26:57 <spiiroin> karry: same metric would be nice, but basically memory pressure metric just needs to be good enough that sailfish userspace memory hoggers have a chance to flush out stuff before oom killer gets triggered
08:26:57 <Thaodan> IMHO the whole terminology is confusing since the kernel still has an oom-killer.
08:27:47 <karry> Thaodan: I understand it. It is good to have such mechanism even on Sailfish. The basic idea is simple.
08:27:59 <Thaodan> I'd say PSI is quite good for that given that Android and systemd both use it.
08:28:00 <ApB> isn;t systemd-oomd in a version much newer than what is used in the phone?
08:28:03 <Nico> Is there a way for apps to get notified, when memory is low, so that they can drop caches?
08:28:08 <Thaodan> #link https://www.kernel.org/doc/html/latest/accounting/psi.html
08:28:14 <ApB> i think it was in 247 and the phone is on 238
08:28:50 <Thaodan> ApB: Yes that's true but I think that's better than developing something new.
08:29:12 <flypig> A couple of minutes to go on this.
08:29:13 <ApB> an undate to systemd i believe will be more than welcome
08:29:54 <spiiroin> Nico: there is https://docs.sailfishos.org/Reference/Core_Areas_and_APIs/Device_Management/Mce/, but the problem is that like karry says measuring/tracking status via cgroups has issues
08:29:56 <karry> Nico, there is "memory leve" api: https://docs.sailfishos.org/Reference/Core_Areas_and_APIs/Device_Management/Mce/
08:30:12 <Nico> I see, thanks!
08:30:36 <flypig> #link https://docs.sailfishos.org/Reference/Core_Areas_and_APIs/Device_Management/Mce/
08:31:12 <Nico> Sounds like something neat to play around with, if it becomes reliable enough at some point :3
08:31:13 <karry> it was working fine with memnotify on Jolla 1 and Jolla C, but this is not upstream kernel api
08:31:34 <flypig> Okay, time is up I'm afraid. Do you need more time karry?
08:31:47 <Thaodan> Here are Fedoras docs on moving to Systemd-oomd those also can help to explain the situation
08:31:57 <Thaodan> #link https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Can_we_integrate_this_with_GIO.27s_GMemoryMonitor_API.3F
08:32:02 <karry> no... the topic is complex. There is not enough time on the meeting...
08:32:30 <flypig> Yes, sorry, it is complex. I hope you can continue in the forum, or post-meeting IRC.
08:32:35 <flypig> Let's move on.
08:32:36 <flypig> #topic better phone lock (10mins -- asked by lolek)
08:32:45 <flypig> #info <lolek> We finally get encryption even tho it's bad right now but there has been information that it will be improved which is great!
08:32:54 <flypig> #info <lolek> So I'd like to get back to the old idea of the picture password, more about this can be read here:
08:32:58 <flypig> #link https://forum.sailfishos.org/t/picture-password/9834
08:33:10 <flypig> #link https://forum.sailfishos.org/t/picture-password/9834
08:33:13 <flypig> #info <lolek> A special warning, please do not confuse this with Android picture password which is very very weak, it's totally different thing.
08:33:24 <flypig> And our prepared answer.
08:33:38 <flypig> #info <Jolla> This is an interesting idea, and we're always looking for ways to improve Sailfish OS security and authentication.
08:33:49 <flypig> #info <Jolla> This particular approach has been patented by Blackberry, which would complicate it's use in Sailfish OS.
08:33:54 <flypig> #info <Jolla> Most phones nowadays come with fingerprint support, which (when it works reliably enough) can speed up unlocking of the device a lot already.
08:34:04 <flypig> #link https://patents.google.com/patent/US9064104B2/en
08:34:09 <flypig> #info <Jolla> There are also many other approaches and there's been a lot of work done on evaluating authentication. Here are some links on the topic.
08:34:12 <flypig> #link https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-817.pdf
08:34:15 <flypig> #link https://www.flypig.co.uk/papers/sa-cd-gj-kk-dlj-tm-fs-2020.pdf
08:34:19 <flypig> #info <Jolla> As well as the factors mentioned in these, another important consideration is that any alternative must fit with the existing authentication components and UI.
08:34:24 <flypig> #info <Jolla> So please do share your ideas, we'd love to hear them, but be aware that making any change like this requires a great deal of care. One good step forward would be to provide a better mechanism in the OS for installing additional authentication methods and letting users choose what they prefer.
08:34:50 <flypig> lolek, please feel free to expand on your question.
08:35:48 <flypig> Maybe lolek isn't around right now. Any other comments?
08:35:50 <lolek> Yeah this is what I was afraid of course that they did patent it, so maybe there would be an option to expose an api so someone could make their own unlocking screen/method. Right now I found some old app that adds android picture password but it just "press numbers in the background"
08:36:52 <lolek> so your idea with providing the mechanism so someone could actually handcraft it is imho fine enough. Also please keep in mind that fringerprint unlock is generally considered as unsafe. You can even see this info on fresh android instalation.
08:37:01 <ExTechOp> (I've found that I'm getting old enough that when I do heavy work with my hands my fingerprints go missing, so I can't use them to unlock the phone)
08:37:35 <Nico> ExTechOp: Don't worry, Sailfish forgets about the fingerprints sometimes too :3
08:37:57 <lolek> ExTechOp: that's obvious and perfectly normal, yet right now SFOS doesn't have any safe and strong unlocking mechanism, pin/fingerprint are not.
08:38:30 <flypig> lolek, so your main concern is security?
08:38:32 <Nico> Probably ties in with the next question :3
08:38:38 <Apb> alphanumeric -that is coming- will be good enough i think
08:38:44 <ExTechOp> (I know it's a matter of worn fingertips, since after a couple of days of just office work they start working again)
08:39:11 <Apb> ExTechOp: wear gloves to protect them maybe?
08:39:54 <lolek> flypig: long story short - yes. Since our mobile devices have access to our mail accounts and so on, it's important to be able to sleep well having in mind no one can spot how to unlock your phone. Also maybe that's a bit funny but a real world scenario. With fingerprint, your kid can take your phone and unlock it with your finger while you sleep to access your bank account to buy some game.
08:40:07 <lolek> flypig: and with the pin code it's the same, the kid can spot it
08:40:32 <flypig> Thanks for clarifying and for the examples; I was curious.
08:40:41 <lolek> flypig: I'm not saying this is important as it's just matter of rising the kid but it's just to show the general problem
08:41:29 <flypig> Understood. Phones are very personal devices, and different auth mechanisms have different pros and cons, for sure.
08:41:32 <lolek> flypig: and imho providing some api/authentication mechanism that can be used by developer to write an app for this would probably help a lot
08:42:18 <lolek> flypig: but I also do understand that for this we still need to wait first for the new implementation of encryption. I think someone from Jolla already mentioned that on the forum when I gave link to rinigus solution
08:42:55 <flypig> It's convenient that we have this topic coming up :)
08:43:09 <flypig> We have a couple more mins on this topic first though.
08:44:02 <lolek> well from my point of view, ifJolla is willing/planning and will provide auth mechanism to allow crating apps that will unlock the phone i.e. replace the built in solutions, I think the only question is when we can see it say that, this year, or next year or even longer?
08:44:40 <flypig> I don't think there's any timeline to provide right now, I'm afraid.
08:44:41 <Thaodan> For my pov the issue is the UI side, from the backend side there's pam which can be extended.
08:44:55 <Thaodan> And of course planing everything.
08:45:21 <flypig> Time is up. Since the next topic is related, I suggest we move directly on.
08:45:35 <flypig> #topic Use of FOSS storage encryption solution as a base for official storage encryption on SFOS (15 min -- asked by rinigus)
08:45:38 <flypig> This is the final topic for the meeting today. Some more detail.
08:45:39 <lolek> flypig: ok let's do this... consider this topic has been handled and I'll remind it in the next few months if this has been on the agenda - i.e. there are some estimations when we can see this.
08:45:50 <flypig> Thanks lolek!
08:45:55 <flypig> #info <rinigus> There is an open source storage encryption solution that has been enrolled on some unofficial ports.
08:46:01 <flypig> #link https://github.com/sailfishos-open/sailfish-device-encryption-community
08:46:09 <flypig> #info <rinigus> It has support for plain LUKS alphanumeric passwords, passwords backed up by Android HW security solutions, integration with SFOS Settings, to name the few.
08:46:13 <flypig> #info <rinigus> The license has been selected to allow such integration (GPLv2).
08:46:17 <flypig> #info <rinigus> So, I wonder whether Jolla would consider joining forces and develop its future alphanumeric solution using our code for it as a base.
08:46:27 <flypig> And this is the answer we prepared.
08:46:32 <flypig> #info <Jolla> Sailfish Device Encryption has been in use since Sailfish 3, integrated to our Settings, Startup Wizard flow, multi-user flows, minui-based unlock UI shown in the boot sequence, etc.
08:46:40 <flypig> #info <Jolla> Replacing it now partially or fully with another solution (which lacks these integrations) would not be a small undertaking.
08:46:48 <flypig> #info <Jolla> In comparison the alphanumeric support is smaller, much more incremental addition that we have already developed (unfortunately in parallel to the community work), and are now finishing up.
08:46:55 <flypig> #info <Jolla> The community implementation uses hardware-assisted encryption using the Android Keymaster API, which is a nice improvement over the original solution, but unfortunately seems to only use non-authenticated keys.
08:46:59 <flypig> #info <Jolla> Further getting the Keymaster API is often complicated due to the varying support and closed nature of vendor TEE implementations.
08:47:05 <flypig> #info <Jolla> We do follow these activities with a lot of interest, e.g. if there are different ways to extend the usage of TEE further in the OS as improving the security is a very important goal for us.
08:47:21 <flypig> Do we have rinigus here?
08:47:26 <rinigus> yes
08:47:44 <flypig> Great. Please do feel free to expand, etc.
08:48:10 <rinigus> well, I would say community version has all the same integrations (settings, wizard is separate as you have it closed source)
08:48:37 <rinigus> minui is not used for simple reason - you need android layer booted up to use hw integration
08:49:04 <rinigus> so, you can get already full silica stack for UI
08:49:37 <rinigus> I don't understand what you mean by "unfortunately seems to only use non-authenticated keys"
08:50:18 <flypig> jpetrell, is that something you could expand on?
08:51:17 <rinigus> also, how is encryption related to multi-user flows? there is a settings module that should work for all users. in addition, it actually allows each user to have their own LUKS password
08:51:22 <jpetrell> afaik you need to use GateKeeper with KeyMaster to use authenticated keys
08:52:46 <jpetrell> you can bootup to silica UI for unlocking encryption, but that is slower
08:53:17 <rinigus> jpetrell: the used key mechanism as done in community edition would work even if the phone is cracked in root access mode. such as if someone boots into recovery. as LUKS key is available via signing by RSA (same mechanism as used by Android btw) and that is done in rate limited manner, it is not relying on any android extra protection to keep you safe
08:53:30 <rinigus> not sure I replied to your gatekeeper concern
08:53:35 <rinigus> hopefully I did
08:54:43 <rinigus> as for use of silica for unlocking being slower - well, how many times do you boot in practice? this allows you to have proper security (due to TEE involvement), something that you cannot do early in the boot
08:55:11 <Nico> Don't you need to fully boot the OS in the end anyway?
08:55:25 <jpetrell> yeah it is definitely not _the reason_, but one concern
08:55:33 <jpetrell> it = performance
08:55:43 <rinigus> what I would argue is that just having alphanumeric pwd is insufficient and you need some hw backing anyway
08:56:15 <rinigus> jpetrell: note that UI can be redone in minui, I just didn't see a reason for it
08:56:28 <jpetrell> I've understood that the protection you get from TEE can be compromised if others can get access to the key, which is a risk with non-authenticated keys
08:56:55 <Thaodan> Since bootloader are mostly unlocked keymaster is affected or is it?
08:57:41 <rinigus> unless you break into TEE, that signing key sits there and allows you to sign once in 3 or 5 seconds. that key is not really available outside device for cracking, if it is what you mean
08:58:11 <flypig> Just for info, we have another 5 mins on this topic.
08:58:14 <rinigus> so, if you are limited to one try in 3 seconds, on the phone only, your alphanumeric pwd becomes way stronger
08:58:39 <jpetrell> true
08:58:56 <rinigus> jpetrell: what I have seen from Android APIs was that key protection assumes that root is protected. which we don't have in recovery
08:59:20 <rinigus> hence the solution was to rely on something that can withstand root
09:00:35 <rinigus> any other concerns preventing the switch?
09:00:59 <flypig> Could you elaborate on how the signing is turned into the LUKS key?
09:00:59 <lolek> well I'm voting for what rinigus done if I may add cause only adding alphanumerics to current solution is improvement for sure but imho still not enough
09:01:07 <rinigus> as far as I understand, you prefer to continue using closed source implementation
09:01:32 <flypig> (or maybe you have a good link on the topic)
09:01:41 <jpetrell> you said community version has all the same integrations, and then listed settings, wizard, boot flow not being integrated, which was kind of the main points
09:02:08 <flypig> One more minute on this topic. Time to wrap up I'm afraid.
09:02:11 <Thaodan> Hm it does have those
09:02:17 <rinigus> flypig: your password that you enter is salted by argon first. result is signed by RSA and that is used for LUKS
09:02:24 <Thaodan> only wizard is separate
09:02:28 <Thaodan> since its closed source
09:02:34 <flypig> Perfect, thank you rinigus.
09:03:03 <rinigus> settings is there; wizard had to be separate as yours is closed source; boot flow is integrated
09:03:21 <flypig> Okay, let's move on to general discussion. You're welcome to continue with this topic there of course.
09:03:36 <flypig> #topic General discussion (20 min)
09:04:05 <rinigus> bonus, in addition to hw keys support, is ability to have encryption for ports that have /home together with /. this is via loopback device that is encrypted and used to provide /home for such ports
09:04:18 <rinigus> in addition, you can switch off encryption if you wish
09:04:37 <rinigus> jpetrell: reply above
09:05:51 <jpetrell> I look at the two implementations and no migrating to community version is not trivial. and we have alphanumeric encryption done in parallel already so it would be hard to justify the switch
09:05:53 <Apb> (unrelated to the encryption) sfos as a distro feels more cluttered and complex than that of my normal pc. granted a phone is different but is it only me that feels that or its because things have pilled up and dragged along since its begining
09:06:29 <Nico> jpetrell: But the community version has a lot more features, is open source and works on ports!
09:06:56 <flypig> Apb, could you elaborate on what you mean by "cluttered"? The UI, the package structure, the filesystem?
09:07:09 <jpetrell> Nico: it has other features, not much more features. open source and ports are sure nice :)
09:07:48 <Nico> Fair
09:08:08 <rinigus> let me ask in relation to encryption - do you now unbind /home LUKS key from PIN?
09:08:19 <rinigus> in future?
09:08:20 <Thaodan> I think community encryption has more features regarding security like locking / and the salting and signing of the password
09:08:22 <Apb> flypig:  the filesytem. it seems like we have a million different conf files compared to my pc
09:09:13 <flypig> Thanks for the clarification.
09:09:18 <rinigus> as for transition from closed source to community implementation: it is all packaged and in use already. I can tell you which package to replace in your package list :)
09:09:22 <Thaodan> Apb: Its very similar some packages have workarounds for sandboxing or use older style of config files (like shipping default config fikles into /etc).
09:10:39 <ExTechOp> I've been thinking about the hardware officially supported for Sailfish by Jolla. Could there be devised a process (likely involving money) where a community port for some device could be transformed into a part of the "core" Jolla-supported devices?
09:11:00 <Apb> Thaodan: to me it feels kind of different TBH. even the whole multi user thing feels different to what i do on a normal pc. (that might be related to the gui thouhg)
09:11:08 <Thaodan> I'd say switching between community encryption is quite easy for ports. I didn't replaced an existing install but using it in a port is easy. I use official encryption and another one that works on kumano ports (voidanix) switch to community encryption in one commit.
09:11:13 <Nico> ExTechOp, I feel like having a way to get jolla apps on it is more important
09:11:22 <Nico> Like Android support :3
09:11:40 <Thaodan> Apb: That's mostly ui stuff which is different, the rest is quite similar.
09:11:40 <Nico> Although Jolla adopting popular ports could be interesting
09:11:41 <ExTechOp> Nico Well, yes, this is kinda what I was thinking of when I said "Jolla-supported"
09:11:49 <rinigus> regarding more features: well, it is done till the last step taking into account HW integration. also knowing that you can examine security related code in open is an important aspect. something that your company customers can, but not the end users of them
09:12:12 <Nico> ExTechOp: Afaik there were some plans for that, but they probably happen in Jolla time
09:12:20 <Apb> ie. i create users with systemd-homed but writing a gui around that should be easy probably
09:12:40 <Apb> (assuming systemd was new enough)
09:12:41 <rinigus> jpetrell:  to my understanding, Jolla's alphanumeric will be just that without HW backed keys
09:13:59 <jpetrell> as said in the intro we are looking at utilizing TEE more
09:14:36 <ExTechOp> Nico What I kinda was thinking of was the Fairphone4
09:15:28 <Nico> ExTechOp: The FPs are certainly far too undersupported :3
09:16:11 <ExTechOp> And now for something completely different: are there any dates yet for the Xperia 10 III support (I think SFOS 4.4)?
09:16:25 <Apb> fairphones (from a hw pov) don't compliment sfos
09:16:32 <Apb> but nothing does sadly
09:16:55 <ExTechOp> Er, what does "don't compliment" mean?
09:17:01 <Nico> ExTechOp: I feel like Jolla hates giving dates, but it was mentioned early 2022 in the community news, afaik
09:17:04 <Apb> sie wise
09:17:07 <Apb> size
09:17:21 <flypig> ExTechOp, I don't think we have *new* info to share on 10 III release dates. Some broad times were already mentioned elsewhere.
09:17:27 <Apb> and specs but i can live with tht
09:17:45 <sledges> ExTechOp: you can build it yourself already :) https://github.com/sailfishos/docs.sailfishos.org/blob/aed11a16662f1e76b9be9d9e5b2e20b9394ada46/Develop/HW_Adaptation/Sailfish_X_Xperia_Android_11_Build_and_Flash/README.md
09:18:04 <sledges> (PR will be merged RSN https://github.com/sailfishos/docs.sailfishos.org/pull/21 )
09:18:33 <ExTechOp> sledges There is a reason why I'm "community" and not "developer", I have too many things going on as it is :-/
09:18:37 <Nico> Also, now that the first browser patches have been merged, Jolla should take a look at the other ones :3
09:18:37 <rinigus> well, in the end, it is Jolla's choice regarding encryption implementation. before I started working on it, everyone were tight-lipped and did not reply on official forum regarding any alphanumeric plans. so, I managed to implement and roll it out and only after that some noises from Jolla camp arrived that you have it in works. fortunately, implementation is quite complete and I can use it as long as I wish despite official SFOS
09:18:37 <rinigus> decision
09:18:46 <Nico> The ones from dcaliste look great!
09:18:53 <flypig> Nico, we will!
09:18:58 <sledges> ExTechOp: you as in plural, also one doesn't need to be developer to build this one (that's why porters community is that big:)
09:19:05 <Nico> flypig: FASTERRRRR! <3
09:19:16 <Thaodan> Also its helpful to look into the upstream bugtracker for issues. https://github.com/sonyxperiadev/bug_tracker/issues
09:19:38 <sledges> most of the relevant bugs linked in the PR
09:19:47 <Nico> "need to reflash every 7 boots" o:
09:20:00 <sledges> that has a fix already
09:20:02 <flypig> Nico, I know, it's taken a while. I'm afraid that is the nature of the process as you know. But we will try, and thanks for the prod :)
09:20:14 <sledges> Nico: and, reflash only boot partition btw
09:20:37 <flypig> We have 5 more mins of general discussion.
09:20:50 <Nico> flypig: No worries, I've got time. I'm mostly just joking around at this point. I am still super hyped my patch got merged after all
09:21:25 <flypig> Nico, it's good on many levels :)
09:21:27 <dcaliste> flypig: I think the PR on long press to close is less controversial than the pull down menu to add a new tab ;)
09:21:27 <Nico> sledges: That sounds fun :D
09:21:43 <fridlmue> How is the VoLTE/VoNR proceeding? Is Jolla happy with the progress? ;-P
09:21:46 <Apb> what rinigus said about the info on the encryption is the only sad part. its bad to have people working on the same thing in parallel
09:22:14 <Nico> Having a way to trigger pulleys on long phones would be great .-.
09:22:20 <Nico> Or in long lists
09:22:25 <Nico> rather
09:22:40 <sledges> Nico: like i said, fix was found
09:22:44 <flypig> dcaliste, yes, I agree :) They're nice changes, but all design changes require careful consideration... of course!
09:22:51 <sledges> 08:17 < ExTechOp> This seems to have fallen somewhat onto the wayside as things have progressed, and eg. chat protocols don't have such OS support any longer.
09:23:07 <sledges> there was a community effort, search web for "08:17 < ExTechOp> This seems to have fallen somewhat onto the wayside as things have progressed, and eg. chat protocols don't have such OS support any longer.
09:23:18 <sledges> *"build.sailfishos.org kaffeine telepathy"
09:23:37 <sledges> in hopes that it could be picked up again by someone
09:23:51 <flypig> Just 2 more mines on this now.
09:24:18 <dcaliste> flypig, sure, there is no hurry. While looking a bit less consistent the current behaviour is in my opinion quite alright already anyway..
09:24:21 <Nico> mines? o.o
09:24:30 <ExTechOp> Yet another different question: has anyone built a camera app for the multi-camera hardware like Xperia 10 devices to trigger cameras simultaneously, so as to produce pictures at multiple zoom levels?
09:24:45 <Thaodan> sledges ExTechOp: Kaffeine  did spend some time into pushing those but he could not do it alone.
09:25:15 <flypig> dcaliste, I appreciate you saying so, and it's also good to have your changes. It certainly generates discussion.
09:25:17 <sledges> ExTechOp: from community i bet it's piggz who could implement in this advanced camera app
09:25:36 <Thaodan> There was also work into using a newer connection manager for tel:// calls that is already used by ubports.
09:25:50 <flypig> We're wrapping up now I'm afraid. Final words?
09:26:05 <flypig> And does anyone want any conclusions logged to the minutes?
09:26:05 <Apb> will something break bad in the OS if i modify the defaultuser name to something else?
09:26:09 <Thaodan> In general it requires more manpower.
09:27:00 <flypig> Alright, time to wrap up. Thanks for all the excellent discussion today.
09:27:06 <flypig> #topic Next meeting time and date (5 min)
09:27:08 <Nico> Final words for flypig: Thank you and everyone else for the meeting. It was a very enjoyable experience!
09:27:18 <flypig> Nico, great, thank you!
09:27:19 <flypig> Proposing Thursday 3rd February at 08:00am UTC
09:27:26 <flypig> Any objections?
09:27:31 <Apb> flypig: see. we were cool. we didn't start a fight or something :P
09:27:43 <Thaodan> Hit us up in #sailfishos or #sailfishos-porters if you want to contribute
09:27:52 <Thaodan> PRs always welcome
09:28:06 <flypig> Apb, thank you for the orderly behaviour :) Everyone here gets gold stars!
09:28:13 <ExTechOp> 2022-02-03T08:00Z works for me!
09:28:21 <Nico> Thaodan, link me the email app repo please for my PRs ;p
09:28:45 <flypig> Alright, we're going for the 3rd then.
09:28:49 <flypig> #info Next meeting will be held on Thursday 3rd February 2022 at 08:00am UTC:  2022-02-03T0800Z
09:29:00 <flypig> That's it. Have a good fortnight everyone!
09:29:02 <flypig> #endmeeting