#sailfishos-meeting: Sailfish OS, open source, collaboration -- 20th January 2022

Meeting started by flypig at 08:00:40 UTC (full logs).

Meeting summary

    1. Meeting information and agenda can be found here: (flypig, 08:00:49)
    2. https://forum.sailfishos.org/t/community-meeting-on-irc-20th-january-2022/9549 (flypig, 08:00:53)

  2. Brief introduction (5 min). Please prefix your name/handle with #info (flypig, 08:01:30)
    1. Nico, community/dev who successfully pushed for a close button (Nico, 08:02:17)
    2. Otto Mäkelä, community (ExTechOp, 08:02:25)
    3. Lukáš Karas, community, developer (karry, 08:02:42)
    4. Joona Petrell, sailor at Jolla (jpetrell, 08:03:02)
    5. Simonas Leleiva -- privateer for Jolla (sledges, 08:03:18)
    6. Simo Piiroinen, sailor at Jolla (spiiroin, 08:03:19)
    7. David Llewellyn-Jones, sailor @ Jolla (flypig, 08:03:29)
    8. Björn Bidar, sailor @ Jolla (Thaodan, 08:04:44)

  3. Open the source code of the entire system (10 minutes -- asked by ddobrev) (flypig, 08:07:58)
    1. <ddobrev> Some parts of the system, such as the GUI (Silica) are still proprietary. (flypig, 08:08:12)
    2. <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. (flypig, 08:08:16)
    3. <ddobrev> I'm not talking about the Android layer the opening of which while still useful it seems to me is legally impossible. (flypig, 08:08:21)
    4. <ddobrev> I only mean the OS itself, and perhaps the built-in applications. (flypig, 08:08:24)
    5. <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). (flypig, 08:08:42)
    6. <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. (flypig, 08:08:50)
    7. <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). (flypig, 08:08:57)
    8. <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. (flypig, 08:09:03)
    9. <Jolla> I cannot emphasise enough that we open up components whenever we can. (flypig, 08:09:08)
    10. <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. (flypig, 08:09:12)
    11. https://techcrunch.com/2021/08/25/jolla-hits-profitability-ahead-of-turning-ten-eyes-growth-beyond-mobile/ (flypig, 08:09:16)
    12. fridlmue - community (little late, sorry) (fridlmue, 08:10:14)
    13. Damien Caliste, community (dcaliste, 08:10:37)
    14. mapplauncerd-booster-silica was open sourced recently, with interesting silica history (flypig, 08:13:49)
    15. https://github.com/sailfishos/mapplauncherd-booster-silica (flypig, 08:13:52)
    16. Nico's recent PR accepted to the browser. (flypig, 08:17:25)
    17. https://forum.sailfishos.org/t/browser-redesign-in-sailfish-4-2-feedback-thread/7867/105 (flypig, 08:17:28)

  4. lowmemory killer and memory state reporting (10 minutes -- asked by Karry) (flypig, 08:18:53)
    1. <Karry> Sailfish OS has mechanism for notifying applications when system has not enough memory (by mce daemon, via D-Bus api). (flypig, 08:19:10)
    2. <Karry> Together with lowmemory killer (kernel module) that kills applications when memory is under pressure, it maintain free memory reserve. (flypig, 08:19:15)
    3. <Karry> It is good idea. But it is not working properly on Sony mobiles without memnotify api. (flypig, 08:19:18)
    4. <Karry> Mce is counting free memory wrongly with cgroup api. And kernel lowmemory killer has multiple downsides. See: (flypig, 08:19:23)
    5. https://forum.sailfishos.org/t/4-1-0-24-xperia-10-ii-unknown-memory-level-reported-by-mce/6856 (flypig, 08:19:28)
    6. <Karry> and my blog post: (flypig, 08:19:31)
    7. https://www.karry.cz/en/karry/blog/2021/11/07/sailfishos_memory. (flypig, 08:19:34)
    8. <Karry> So my question is, what are Jolla's plan in this area? Specifically: (flypig, 08:19:36)
    9. <Karry> - do Jolla want to use lowmemory killer in kernel in future, or migrate to user-space daemon, similar as Android does? (flypig, 08:19:39)
    10. <Karry> - do you agree with my conclusion that mce computes memory incorrectly? :-) what api to use, when memnotify (flypig, 08:19:44)
    11. <Karry> is not available? Cgroup don't provides enough details. I can imagine just parsing `/proc/meminfo`... (flypig, 08:19:47)
    12. <Jolla> We read your blog post on the topic with interest back in July and we're grateful for your work on this. (flypig, 08:20:00)
    13. <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. (flypig, 08:20:07)
    14. <Jolla> So in short, we are studying the issue, but it's too early to say anything about what we eventually end up doing. (flypig, 08:20:12)
    15. <Jolla> To try to answer your ancillary questions directly: (flypig, 08:20:16)
    16. <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. (flypig, 08:20:23)
    17. <Jolla> 2. We agree with your conclusions, yes, but haven't yet come to a conclusion about what API is going to work best. (flypig, 08:20:28)
    18. <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. (flypig, 08:20:39)
    19. <Jolla> We are actively working on it and we'd welcome more discussion on the topic. (flypig, 08:20:42)
    20. https://source.android.com/devices/tech/perf/lmkd (flypig, 08:20:48)
    21. https://man.archlinux.org/man/systemd-oomd.8 (flypig, 08:20:52)
    22. https://www.kernel.org/doc/html/latest/accounting/psi.html (Thaodan, 08:28:08)
    23. https://docs.sailfishos.org/Reference/Core_Areas_and_APIs/Device_Management/Mce/ (flypig, 08:30:36)
    24. https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Can_we_integrate_this_with_GIO.27s_GMemoryMonitor_API.3F (Thaodan, 08:31:57)

  5. better phone lock (10mins -- asked by lolek) (flypig, 08:32:36)
    1. <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! (flypig, 08:32:45)
    2. <lolek> So I'd like to get back to the old idea of the picture password, more about this can be read here: (flypig, 08:32:54)
    3. https://forum.sailfishos.org/t/picture-password/9834 (flypig, 08:32:58)
    4. https://forum.sailfishos.org/t/picture-password/9834 (flypig, 08:33:10)
    5. <lolek> A special warning, please do not confuse this with Android picture password which is very very weak, it's totally different thing. (flypig, 08:33:13)
    6. <Jolla> This is an interesting idea, and we're always looking for ways to improve Sailfish OS security and authentication. (flypig, 08:33:38)
    7. <Jolla> This particular approach has been patented by Blackberry, which would complicate it's use in Sailfish OS. (flypig, 08:33:49)
    8. <Jolla> Most phones nowadays come with fingerprint support, which (when it works reliably enough) can speed up unlocking of the device a lot already. (flypig, 08:33:54)
    9. https://patents.google.com/patent/US9064104B2/en (flypig, 08:34:04)
    10. <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. (flypig, 08:34:09)
    11. https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-817.pdf (flypig, 08:34:12)
    12. https://www.flypig.co.uk/papers/sa-cd-gj-kk-dlj-tm-fs-2020.pdf (flypig, 08:34:15)
    13. <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. (flypig, 08:34:19)
    14. <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. (flypig, 08:34:24)

  6. Use of FOSS storage encryption solution as a base for official storage encryption on SFOS (15 min -- asked by rinigus) (flypig, 08:45:35)
    1. <rinigus> There is an open source storage encryption solution that has been enrolled on some unofficial ports. (flypig, 08:45:55)
    2. https://github.com/sailfishos-open/sailfish-device-encryption-community (flypig, 08:46:01)
    3. <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. (flypig, 08:46:09)
    4. <rinigus> The license has been selected to allow such integration (GPLv2). (flypig, 08:46:13)
    5. <rinigus> So, I wonder whether Jolla would consider joining forces and develop its future alphanumeric solution using our code for it as a base. (flypig, 08:46:17)
    6. <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. (flypig, 08:46:32)
    7. <Jolla> Replacing it now partially or fully with another solution (which lacks these integrations) would not be a small undertaking. (flypig, 08:46:40)
    8. <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. (flypig, 08:46:48)
    9. <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. (flypig, 08:46:55)
    10. <Jolla> Further getting the Keymaster API is often complicated due to the varying support and closed nature of vendor TEE implementations. (flypig, 08:46:59)
    11. <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. (flypig, 08:47:05)

  7. General discussion (20 min) (flypig, 09:03:36)
  8. Next meeting time and date (5 min) (flypig, 09:27:06)
    1. Next meeting will be held on Thursday 3rd February 2022 at 08:00am UTC: 2022-02-03T0800Z (flypig, 09:28:49)


Meeting ended at 09:29:02 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. flypig (139)
  2. Nico (40)
  3. rinigus (31)
  4. Thaodan (29)
  5. Apb (15)
  6. ExTechOp (14)
  7. sledges (14)
  8. ApB (12)
  9. lolek (12)
  10. jpetrell (11)
  11. karry (8)
  12. dcaliste (7)
  13. spiiroin (3)
  14. sailbot (2)
  15. fridlmue (2)


Generated by MeetBot 0.1.4.