Correction: it is not a patch but stack of encryption enabling software. I haven’t patched any Jolla’s code as it is closed source
right, did update the subject.
- Name/IRC nick: lolek
- Topic: Security of stored credentials
- Some details about the topic:
Let’s take built in mail client as an example. The credentials are stored in plain text and what’s worse are easily accessible having just elevated privileges. This is something that shouldn’t be possible in current world. Malicious app can escalate privileges and could easily get mail credentials. Having these can ease the access to mail box. I proposed a solution in the following thread but I’m not a security expert but still the problem is there. I’d like to know what are the plans to fix the problem of having password so easily accessible. - Approx. time needed: 10
- Substitute (optional): I’d like to just get an answer for the question but I expect there may be some conversation. As with the previous topics, please leave a note if I won’t be able to attend.
- Name/IRC nick: jojo
- Topic: New demo apps
- Some details about the topic:
Currently the only demo app we have from jolla is the component gallery app. IMO it would be nice to have additional demo apps showing how to use other components of the device such as the camera, sharing stuff by Bluetooth, uploading documents etc… Things that seem “simple” in the QML doc but that because of the differences isn’t. The doc on this topic is also very thin, and I wasn’t able to find any for the camera or the bluetooth. Could Jolla provide such doc ? To avoid having to dig into the, often not documented, git repos of other apps to try guessing how it works. - Approx. time needed: 1 minute
Component gallery app - more functionalities to the demo
- Name/IRC nick: nephros
- Topic: Handling of X10iii hardware button (Assistant Button)
- Some details about the topic:
This is related to this feature request.
Please advise on a way forward with supporting the unhandled button present on X10iii devices.
Question 1: Making the key accessible to the OS components:
AFAICS there are several options of handling the key event:
- Re-use the existant functionality of MCE and lipstick-jolla-home and map the button to a HOME key. This has been done in this PR I propose.
- Replicate the handling of the HOME key in MCE (like 1, above), but send a separate signal to lipstick. This approach I am exploring in this branch.
- Similar to 1. and 2., but handle it in the
evdev
codepath of MCE rather than thepowerkey
one. - Not caring about MCE at all, make the key code known to Qt, so one can use Qt.Key_xxx, and implement handling similar to
Qt.Key_HomePage
, seelipstick-jolla-home-qt5/compositor.qml
Line 1800, andlipstick-jolla-home-qt5/compositor/HardwareKeyHandler.qml
- other?
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. (The Feature Request thread contains a selection of ideas users might use this for.)
I see the following variants:
a) in Lipstick/compositor, hardcode a certain set of UI actions, similar to what is today done with the Home key, and the keys handled in HardwareKeyHandler
.
b) in MCE/mce-tool, implement something similar to power key handling, where a set of dbus calls (actions) can be defined, and selected to be executed on press
c) in Lipstick/compositor, support a single dconf key containing the name of an application .desktop file, which shall be launched when the button is pressed.
d) in Lipstick/compositor, support a set of dconf keys, which can contain the parameters of a dbus call (i.e. some or all of the parameters of invokeDBusMethod()
from lipstick-jolla-home-qt5/compositor.qml
Line 566)
e) hardcode a Jolla-conceived very sexy killer feature which makes everyone go “wow you can do that??”
D would be the most flexible, but has potential for abuse, security concerns, and might impact stability.
If there is interest, I have a working PoC of variant 2 plus C I can share.
- Approx. time needed: 10-15 min, further clarification could also happen on the PR mentioned.
- Substitute (optional):
- Name/IRC nick: lolek
- Topic: current policy for support of new devices
- Some details about the topic:
Ok so it seems somehow an interesting discussion came out from this thread. I suggest that current way of handling new devices should be probably changed and somehow as you can see some people agreed with me. Tbh this goes in line with this thread also. I think we are all aware that Jolla can’t make miracles with such number of peoples on board. But actually we do need some fixes and improvements of the system to get it to some maturity level which has been mentioned even by me in other topics for this meeting. There are also other feature request and of course there are these which will drown in the black sea of foreverness and there are some which should be picked and implemented. Personally I saw a huge boost when Aurora was backporting fixes. It was visible the system was moving further - finally. But now situation is a little different again. Hence maybe it’s time again to rethink the support of new device and skip every second one? Or get back to some conversation with Indian gov? Or maybe even add option to get subscription based support? Either way is fine to get more human power to move on. And give us really viable alternative to iOS and Android cause, SFOS is good alternative but it’s still not there yet. Small details here and there are really holding it back. - Approx. time needed: 10min
- Substitute (optional): so this will probably require more brainstorming. Not sure what’s Jolla attitude to community right now but probably regarding licensing changes and so if these are possible a poll on the forum would be needed to at least get some feedback.
As previously, I’ll do my best to be on the meeting but do not hesitate to just leave a message if I will not make or will need to go.
- Name/IRC nick: Cryx
- Topic: Behaviour of location services
- Some details about the topic: See detailed below, also here: Q: How can I change behavior of Location in Upper Menu - Turn on GPS immediately after enabling Location? - Design - Sailfish OS Forum
- Approx. time needed: 5min
- Substitute (optional): none; I can’t say if I’ll be able to make in into the meeting, but I want to point out this imho problematic/confusing thing and hope for an answer.
Location service always just starts to get a gps fix when an app activly requests it. This way geotagging of photo is not possible cause the time for a gps fix is still much to long (even on Xperia 10 III) - one can take several photos until the location data is there an added.
It’s unclear if that is a bug or feature (for saving battery) - but if it’s the last then there should be a toggle implemented in location settings to choose between the actual behaviour or an general fix after startup (including a regular update, maybe even with a time cycle setting).
- Name/IRC nick: Cryx
- Topic: “Find my Phone”-Feature
- Some details about the topic: Add a find my phone feature to the settings, details below
- Approx. time needed: 5 min
- Substitute (optional): none, I’ll hope I can make it into; but general discussion would also be nice if I’d be absent
(This topic is partially related to the one above…)
Would it be possible to implement a feature to locate the phone? I mainly think about support for the Nextcloud phonetrack feature, especially as Nextcloud is already implemented into the system. Especially with the demanded feature from the topic above the phone would have location data that just would have to be synced to the Nextcloud (and would need to declare the session where the data should be imported in the Nextcloud account settings).
A second option independend from Nextcloud (and other services) would be writing the last location data in regular cirlces to a definded cloud service (maybe even one where the account is already set up in the phone settings)…
I’ve got an idea for ‘Find my phone’ that works without any Nextcloud stuff:
On receiving an SMS from any other phone number, containing a predefined text or code, e.g. a private password or other code like ‘xbjdjdfcgknvcabv’, The phone should ring at full volume, switch network and location on if it isn’t yet, send position data to a predefined mail address, and send a confirmation SMS to the phone from what the initial SMS came from.
That’s exactly what the Nextcloud Phonetrack App on Android can do as second feature besides protocolling to nextcloud. Nevertheless this feature doesn’t work on SFOS cause Android has no SMS access. An it would be just useable proactive - phone off or battery empty will bring no results this way. But it would be a nice addition for sure!
So feature request should include that a ‘last’ SMS and/or e-mail is sent before devide shuts down on low battery.
At least the tracking part of PhoneTrack is possible via the LiveTrack app.
Yes, but without a chance of setting a sync intervall, no autostart… That’s why I think a system implemented feature would be better.
(I really hope of more nextcloud integration - why not adding Talk feature to messages like xxmp already is? But sure, that’s another topic…)
Yes, I was working on an app to simply reply to a text with position.
Sadly it died on the hill of the GPS not working inside or anywhere with weak signal.
Future question:
Talk about bootloader locking.
Thaodan said:
lolek: if the bootloader supports user signatures you can relock it with your own key to accept only kernels e.g. from Jolla but Sony phones don’t support that so far.
So the question is: What Jolla can do to change this, and how community can help achieve this?
I followed the irc discussion, if we can find some examples of others implementing this it would give consistence to the suggestion to Sony.
This could also be a suggestion sent by the association.
Meeting ended Thu Feb 2 11:01:10 2023 UTC.
Minutes: #sailfishos-meeting: Sailfish OS, open source, collaboration -- 2nd February 2023
Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2023/sailfishos-meeting.2023-02-02-08.01.txt
Log: #sailfishos-meeting log
Thanks once again to everyone who submitted questions and attended the meeting today, and especially if you made it through to the end Great discussion as always!
A little follow-up from the repo : [systemsettings] Support another ringtone for SIM2. JB#33820 by pvuorela · Pull Request #34 · sailfishos/nemo-qml-plugin-systemsettings · GitHub (thanks to @pvuorela).
Ye, didn’t end up too complicated so just implemented that thing out of the way
@flypig Thanks very much for the hint! Here is my feedback to the GPS issue, I added it to a GPS related thread.