#sailfishos-meeting: Sailfish OS, open source, collaboration -- 2nd February 2023
Meeting started by flypig at 08:01:21 UTC
(full logs).
Meeting summary
-
- Meeting information and agenda can be found
here: (flypig,
08:01:30)
- https://forum.sailfishos.org/t/community-meeting-on-irc-2nd-february-2023/14091
(flypig,
08:01:33)
- Brief introduction (5 min). Please prefix your name/handle with #info (flypig, 08:02:12)
- just a regular user (lolek,
08:02:35)
- David Llewellyn-Jones - Sailor @ Jolla and the
chair today (flypig,
08:02:41)
- Ville Nummela - sailor @ jolla (ViGe,
08:02:56)
- jojo regular user (jojo_,
08:03:06)
- nephros, community member, (and bug squishing
team) (nephros,
08:03:28)
- Simonas Leleiva -- privateer for Jolla
(sledges,
08:04:17)
- Damien Caliste, community (dcaliste,
08:04:20)
- Pekka Vuorela, Jolla (pvuorela,
08:05:51)
- Otto Mäkelä, community (ExTechOp,
08:06:18)
- Sailfish OS system encryption (5 mins -- asked by lolek) (flypig, 08:09:49)
- <lolek> Current encryption implementation
in SFOS is almost useless because of very easy way of breaking
it. (flypig,
08:09:57)
- <lolek> Some time ago there was info that
Jolla is working on improving it. (flypig,
08:10:04)
- <lolek> There's also a community version
of a solution made by rinigus to fix this issue. (flypig,
08:10:08)
- <lolek> When will this get finally
fixed/implemented as it's critical from the security point of
view. (flypig,
08:10:13)
- <Jolla> We recognise this is a feature
that many users consider important, and we commend rinigus's work on
a community implementation. (flypig,
08:10:47)
- <Jolla> In fact we've been working on an
implementation of alphanumeric security codes for some time, and you
can expect it to arrive in the next release. (flypig,
08:10:53)
- Björn Bidar - Sailor @ Jolla (Thaodan,
08:13:52)
- https://github.com/sailfishos-open/sailfish-device-encryption-community
(nephros,
08:18:42)
- rinigus's solution supports hwcrypt, and this
may be a topic to come back to in a future meeting. (flypig,
08:25:00)
- Different sounds for different sim/user/group/alarm (5 mins -- asked by lolek) (flypig, 08:30:38)
- <lolek> Different sounds for different
sim/user/group/alarm is a critical feature especially for those who
are using dual sim functionality. (flypig,
08:30:45)
- <lolek> So at least for the beginning it
would be great to have: (flypig,
08:30:52)
- 1) different ringtone for every sim
card; (flypig,
08:30:56)
- 2) different ringtone for contact specified as
favourites; (flypig,
08:31:00)
- 3) different ringtone for each alarm;
(flypig,
08:31:03)
- 4) different ringtone for every contact.
(flypig,
08:31:07)
- <lolek> Please state when we can expect
this. (flypig,
08:31:12)
- <Jolla> We agree this is a nice feature,
and changes that we've introduced in the upcoming release have been
designed to make an implementation easier, by routing ringtone
requests via the user interface code. See for example the following
PR. (flypig,
08:31:37)
- https://github.com/sailfishos/voicecall/pull/8
(flypig,
08:31:42)
- <Jolla> However, more work is needed to
integrate it with the Contacts app. We can't therefore give any
guarantees about a future implementation. (flypig,
08:31:50)
- <Jolla> For some context, the Personal
Ringtones app from rinigus offers this as a third-party
feature. (flypig,
08:31:57)
- https://openrepos.net/content/coderus/personal-ringtones
(flypig,
08:32:05)
- <Jolla> We discussed it during a
community meeting in August 2021 and some useful links for anyone
interested in contributing to development are provided in the
minutes. (flypig,
08:32:10)
- https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-08-05-07.00.html
(flypig,
08:32:13)
- It was noted that ringtones for simcard and
alarms would be a nice first step, and potentially
achievable. (flypig,
08:43:58)
- For community help, pvuorela noted that
profiled and voicecall are open source, and the contacts backend
too, but this requires UI side changes, so it may not be so easy to
propose changes from the community's side. (flypig,
08:47:22)
- Current Gallery App has a bug - loading files from unwanted folders (5 mins -- asked by lolek) (flypig, 08:48:06)
- Current Gallery App has a bug - loading files from unwanted folders (5 mins -- asked by lolek) (flypig, 08:48:21)
- <lolek> This is actually seen in the
gallery app but the issue is maybe related to tracker. (flypig,
08:48:25)
- <lolek> The second link mentions about
Folder View in gallery as also limiting which directory is scanned
for images. (flypig,
08:48:34)
- <lolek> The gallery app should get a
configuration option to allow us to exclude unwanted directories
from showing up in it. (flypig,
08:48:42)
- <lolek> When we can expect this to be
fixed/implemented? (flypig,
08:48:47)
- https://forum.sailfishos.org/t/gallery-app-loading-images-outside-of-image-folders/13516
(flypig,
08:48:50)
- https://together.jolla.com/question/1948/feature-request-folderalbum-view-in-gallery
(flypig,
08:48:53)
- <Jolla> After looking into this, it's
already the case that images in the Music folders don't appear in
the Gallery. (flypig,
08:49:09)
- <Jolla> On further discussion, it
transpired that the problem images were stored on an SD card.
(flypig,
08:49:16)
- <Jolla> We don't have any plans to change
the way tracker handles SD cards, or to introduce configuration
options in the user interface for this. (flypig,
08:49:21)
- <Jolla> However, tracker itself does have
configuration options, and the Gallery App QML can also be tweaked
for more specific requirements (see
/usr/share/jolla-gallery/gallery.qml), at your own risk!
(flypig,
08:49:30)
- https://gnome.pages.gitlab.gnome.org/tracker/faq
(flypig,
08:49:39)
- Cryx - community; late but here before my
topics (Cryx,
09:00:48)
- There was a lot of discussion about different
options, but none that lolek was satisfied with as a solution for
the issue experienced. (flypig,
09:03:13)
- lolek provided a useful link to the Android
approach. (flypig,
09:03:27)
- https://developer.android.com/training/data-storage/shared/media
(flypig,
09:03:36)
- Security of stored credentials (10 mins -- asked by lolek) (flypig, 09:04:34)
- <lolek> For the built in mail client
credentials are stored in plain text and easily accessible having
just elevated privileges. (flypig,
09:04:51)
- <lolek> This is something that shouldn't
be possible in current world. Malicious app can escalate privileges
and could easily get mail credentials. (flypig,
09:05:26)
- <lolek> I proposed a solution in the
following thread. I'd like to know what are the plans to fix the
problem of having password so easily accessible. (flypig,
09:05:34)
- https://forum.sailfishos.org/t/someone-else-with-clear-mail-password-in-home-defaultuser-config-signond-signon-secrets-db/10842/9
(flypig,
09:05:48)
- <Jolla> There are security benefits to
encrypting the credentials separately from the device encryption,
but these benefits are not as big as they may appear. (flypig,
09:06:18)
- <Jolla> Any implementation would require
the unencrypted credentials to be stored in memory, with similar
risks from elevated privileges as the current implementation.
(flypig,
09:06:24)
- <Jolla> In both cases developer
credentials, or a successful privilege escalation attack, are needed
to access the unencrypted credentials. (flypig,
09:06:33)
- <Jolla> Our focus is therefore on
avoiding the need to store any passwords on your device by moving
accounts to OAuth2 so there is no need to store passwords at
all. (flypig,
09:06:41)
- <Jolla> See for example this
StackOverflow comment for a similar perspective: (flypig,
09:06:52)
- https://stackoverflow.com/questions/1925486/android-storing-username-and-password#comment3608058_1925534
(flypig,
09:06:56)
- <Jolla> For app developers we recommend
storing credentials using Sailfish Secrets, since apps don't have
privileged access. (flypig,
09:07:01)
- https://docs.sailfishos.org/Reference/Core_Areas_and_APIs/Apps_and_MW/Secrets_and_Crypto/
(flypig,
09:07:04)
- Protection is still needed for accounts that
don't support OAuth2, TEE may therefore be something to consider for
that. (flypig,
09:20:48)
- New demo apps (5 mins -- asked by jojo) (flypig, 09:24:36)
- <jojo> Currently the only demo app we
have from Jolla is the component gallery app. (flypig,
09:24:43)
- <jojo> It would be nice to have
additional demo apps showing how to use other components of the
device such as the camera, Bluetooth sharing, uploading documents,
etc. (flypig,
09:24:48)
- <jojo> The docs on these topics are also
very thin. Could Jolla provide such docs? (flypig,
09:24:55)
- <jojo> To avoid having to dig into the
git repos of other apps to try guessing how it works. (flypig,
09:25:02)
- https://forum.sailfishos.org/t/component-gallery-app-more-functionalities-to-the-demo/14129
(flypig,
09:25:07)
- <Jolla> We do provide a few other
examples as part of the SDK: Camera Gallery, Lipstick Notifications
Gallery, Media Gallery as well as the Component Gallery.
(flypig,
09:25:34)
- <Jolla> Select "Welcome" then "Examples"
in the Sailfish IDE to try them (or check the examples folder in the
SDK installation). (flypig,
09:25:40)
- <Jolla> We also provide sample apps on
GitHub to demonstrate C, C++ and QML usage of libsailfishapp.
(flypig,
09:25:46)
- https://github.com/sailfishos/sample-app-c
(flypig,
09:25:50)
- https://github.com/sailfishos/sample-app-cppqml
(flypig,
09:25:56)
- <Jolla> We've been working hard updating
the docs recently, as you can see from Damien's Repository
Roundups. (flypig,
09:26:05)
- <Jolla> But we always like suggestions
for improving them. We're also always happy to receive PRs to our
docs or new example apps for the SDK. (flypig,
09:26:10)
- <Jolla> Ideally these should be provided
in a public git repo with a BSD licence. (flypig,
09:26:16)
- jojo suggested additional examples related to
the following would be useful: selecting documents using the Pickers
and controlling keyboard autocomplete suggestions. (flypig,
09:36:22)
- Please contact jojo on the forum with
suggestions for autocomplete usage code. (flypig,
09:39:52)
- Handling of X10 III hardware button (Assistant Button) (15 mins -- asked by nephros) (flypig, 09:40:05)
- <nephros> Question 1: Making the key
accessible to the OS components: (flypig,
09:40:13)
- <nephros> 1) re-use the existing
functionality of MCE and lipstic-jolla-home; (flypig,
09:40:22)
- <nephros> 2) Replicate handling HOME key
in MCE with separate signal to lipstick; (flypig,
09:40:26)
- <nephros> 3) Similar to 1 and 2 but
handle it in the evdev codepath of MCE; (flypig,
09:40:31)
- <nephros> 4) make the code known to Qt
instead of MCE; (flypig,
09:40:37)
- <nephros> 5) other? (flypig,
09:40:40)
- <nephros> Question 2: Handling key press
events: Once the button press can be signalled to the OS, it should
do something. Preferably this should be user-configurable:
(flypig,
09:40:43)
- <nephros> 1) hardcode UI actions in
Lipstick; (flypig,
09:40:51)
- <nephros> 2) something similar to the
power key using MCE and DBus calls; (flypig,
09:40:58)
- <nephros> 3) DConf key containing
.desktop file to launch; (flypig,
09:41:01)
- <nephros> 4) set of DConf keys to trigger
a DBus call; (flypig,
09:41:04)
- <nephros> 5) hardcode a Jolla-conceived
very sexy killer feature. (flypig,
09:41:07)
- https://forum.sailfishos.org/t/xperia-10-iii-make-google-assistant-button-a-camera-trigger/8983
(flypig,
09:41:17)
- <Jolla> Thanks for working on this, it
would certainly be nice functionality. (flypig,
09:41:53)
- <Jolla> As this is a detailed question,
rather than give a prepared answer, we've invited some of the
relevant Sailors to join the discussion. (flypig,
09:41:57)
- https://postimg.cc/gallery/YQP2hs2
(nephros,
09:50:06)
- https://github.com/sailfishos/mce/pull/21
(nephros,
09:55:46)
- pherjung, community (pherjung[m],
09:56:12)
- nephros still needs more input to make progress
with this. More discussion and direction on the PR would be
useful. (flypig,
09:56:44)
- Current policy for support of new devices (10 mins -- asked by lolek) (flypig, 09:57:23)
- <lolek> Maybe it's time again to rethink
the support of new device and skip every second one? (flypig,
09:57:28)
- <lolek> Or get back to some conversation
with the Indian government? Or maybe even add option to get
subscription-based support? (flypig,
09:57:34)
- <lolek> Either way is fine to get more
human power to move on and give us really viable alternative to iOS
and Android. (flypig,
09:57:41)
- https://forum.sailfishos.org/t/sony-xperia-10iv-for-299/14230
(flypig,
09:57:46)
- https://forum.sailfishos.org/t/why-doesn-t-jolla-lobby-indian-government-for-sailfishos-release/14190
(flypig,
09:57:50)
- <Jolla> Thanks for your suggestions. As
it happens, we're currently reviewing both our device support and
pricing strategy, so what you've provided is useful input.
(flypig,
09:58:21)
- <Jolla> We're not planning any changes in
the short term, but we've been following the discussions on the
forum carefully and are interested in all views. (flypig,
09:58:30)
- <Jolla> Please keep an eye on the forums,
as we plan to invite more feedback there. (flypig,
09:58:35)
- Behaviour of location services (5 mins -- asked by Cryx) (flypig, 10:07:52)
- <Cryx> Location service starts to get a
GPS fix when an app actively requests it. (flypig,
10:07:59)
- <Cryx> This way geotagging of photos is
not possible as the time for a fix is too long. (flypig,
10:08:06)
- <Cryx> It's unclear if this is a bug or
battery-saving feature. (flypig,
10:08:10)
- <Cryx> If the latter then there should be
a toggle implemented in location settings to choose between the
current behaviour and always-on. (flypig,
10:08:16)
- https://forum.sailfishos.org/t/q-how-can-i-change-behavior-of-location-in-upper-menu-turn-on-gps-immediately-after-enabling-location/14272
(flypig,
10:08:24)
- <Jolla> You raise a good point: there is
certainly a trade-off between a fast GNSS fix and battery
usage. (flypig,
10:08:37)
- <Jolla> Some work was already done on
this to support Advanced Mobile Location (AML) released in
4.4.0.64. (flypig,
10:08:43)
- <Jolla> We're not actively considering
continuous GNSS. However, if you'd like to look into it further, we
recommend the following steps. (flypig,
10:08:49)
- <Jolla> 1. In /etc/location/location.conf
and /var/lib/location/location.conf edit "enabled" to be "true" to
move positioning to a higher level of standby. (flypig,
10:09:00)
- <Jolla> 2. Create a service to
periodically poll position using geoclue. See the Positioning docs
for info about geoclue. Ideally, have the service reduce polling
when the screen is blanked. (flypig,
10:09:09)
- <Jolla> 4. If it works well, let us know
and we'll look at it seriously. (flypig,
10:09:13)
- https://docs.sailfishos.org/Reference/Core_Areas_and_APIs/Apps_and_MW/Positioning/#platform-api
(flypig,
10:09:16)
- Note: 3. Isn't missing; 4. was incorrectly
numbered. (flypig,
10:12:10)
- <sledges> if above suggestion is too
techy, there's a battery-hungry workaround: run CSD GPS test
continuously (launch from Settings | About product | tap Build
number 5 times | All tests | GPS Satellite Lock) (flypig,
10:13:05)
- https://forum.sailfishos.org/t/release-notes-struven-ketju-4-5-0-16/14290
(ViGe,
10:15:54)
- "Find my Phone"-Feature (5 mins -- asked by Cryx) (flypig, 10:18:17)
- <Cryx> Would it be possible to implement
a feature to locate the phone? (flypig,
10:18:21)
- <Cryx> I mainly think about support for
the NextCloud PhoneTrack feature, especially as NextCloud is already
implemented into the system. (flypig,
10:18:26)
- <Cryx> A second option would be writing
the last location data in regular cycles to a defined cloud
service. (flypig,
10:18:31)
- <Cryx>
https://apps.nextcloud.com/apps/phonetrack (flypig,
10:18:34)
- <Jolla> It would certainly be possible,
and it would be a great feature. We'd actually recommend using the
Sailfish MDM framework for this, specifically LocationSettings and
LocationInfo: (flypig,
10:18:46)
- https://sailfishos.org/develop/docs/sailfish-mdm/sailfish-mdm-locationsettings.html/
(flypig,
10:18:49)
- https://sailfishos.org/develop/docs/sailfish-mdm/sailfish-mdm-locationinfo.html/
(flypig,
10:18:52)
- Open PR discussion (5 mins -- asked by jolla) (flypig, 10:30:53)
- <jolla> Any open PRs to discuss?
(flypig,
10:30:57)
- https://github.com/sailfishos/sailfish-browser/pull/959
(pherjung[m],
10:33:28)
- Untracked bug reports (5 mins -- asked by pherjung) (flypig, 10:39:46)
- <pherjung> Untracked bug reports... (see
the forum) (flypig,
10:39:54)
- <Jolla> Thank you again for all of your
work in checking and collating bug reports. (flypig,
10:39:59)
- <Jolla> Here are the results:
(flypig,
10:40:03)
- <Jolla> - 8 high quality bug reports now
recorded internally and tagged as "tracked". (flypig,
10:40:06)
- <Jolla> - 2 bug reports tagged as
"fixed". (flypig,
10:40:10)
- General discussion (10 min) (flypig, 10:46:01)
- Next meeting time and date (5 min) (flypig, 10:56:20)
- Next meeting will be held on Thursday 16th
February 2023 at 08:00am UTC: 2023-02-16T0800Z (flypig,
10:57:54)
Meeting ended at 11:01:10 UTC
(full logs).
Action items
- (none)
People present (lines said)
- flypig (322)
- lolek (108)
- Thaodan (50)
- nephros (41)
- piggz_ (27)
- jojo_ (24)
- Cryx (16)
- pvuorela (15)
- pherjung[m] (13)
- ExTechOp (12)
- Nico (12)
- abr (12)
- ViGe (11)
- dcaliste (7)
- sledges (6)
- sailbot (2)
- Keto (2)
- sebix[m] (1)
Generated by MeetBot 0.1.4.