hi i wrote a comment on jollastore perhaps somebody has the same issue:




I tested more, on my xperia which is also on 3.0.3.9 there is not the problem. There i had installed situations for upgrading the device to sailfish 3

Sorry for the long response time, there is a beta release available here that should fix the issue:

https://github.com/pastillilabs/pack...leases/tag/232

Br,
Heikki

Hi, is there any way to manually set up cell towers cids in settings?
I can manually add them into json settings file, but it has checksum in the end.

I think you should be able to edit situations.json manually. If there is a checksum, it might be a leftover from some past app version.

Br,
Heikki

Hello folks,

I implemented a quick (and dirty?) companion daemon "Sonar" for Situations app that makes it possible to run privileged actions on Sailfish without any other hacks. And it is now available for testing.

First implementation is just bringing back functionality that has previously been crippled by updates to Sailfish security policies. But with this daemon, new & improved functionality should be possible to implement in the future too.

This version just re-enables the following actions:
- Bluetooth state
- Wifi state
- Mobile network
- Airplane mode

In addition, the package implements autostart for Situations background service - so it might be incompatible with any other autostart tweaks available.

Obviously the package cannot be available in harbour, so users need to install it separately.

NOTE: Since the Sonar daemon runs as root and opens holes to the current Sailfish security model, the sources of it are open (and available for improvement suggestions). Beware that absolutely any app could use the same interface to access same functionality that is exposed to Situations.

Sonar sources are available here:
https://github.com/pastillilabs/sonar

A ready made rpm package can be fetched from here:
https://github.com/pastillilabs/sona...ases/tag/0.0.1

A compatible alpha version of Situations app is available here:
https://github.com/pastillilabs/pack...leases/tag/248

Briefly tested on Jolla 1 and nothing else. Feedback & improvement suggestions are welcome. Would be nice to know if anyone is actually willing to use this

Br,
Heikki

Hep,

An update to Sonar & Situations alpha versions:

Additions to Sonar:
- Basic check for acceptable clients. Only situations binary is allowed to connect, so this adds at least some sort of security to Sonar.
- Initial calendar support
- Due to changes in IPC, only compatible with updated Situations app

Available here:
https://github.com/pastillilabs/sona...ases/tag/0.0.2


Situations:
- Added basic calendar condition!

Available here:
https://github.com/pastillilabs/pack...leases/tag/248

Br,
Heikki

I haven't yet tried Sonar, but as you've pointed out the security being a bit of a concern, could there be some kind of a key mechanism to authenticate clients? Sonar would generate a key on installation and the connecting clients would be required to pass that key when they connect. Just like a regular API key. Of course it would mean the users would need to manually copy-paste the key from Sonar to the client app, but anyone paying the least amount of interest to security would probably be willing to do that anyway.

I really should try the new versions out, I've just grown used to going around with Wifi always enabled out of laziness (which isn't necessarily good for security, either).

Thanks for the feedback. I must say I currently have no idea how to implement such mechanism and not sure if it would really make things any safer / private. Any pointers to examples / concrete suggestions for implementation are welcome

Using some sort of public/private key signature is the best protection I can currently think of, but I think even that would be hackable and perhaps not worth the effort. In the end, without some sort of platform support for sandboxing apps / protecting IPC, it comes down to trusting all the software you have installed on the device not to be malicious.

Br,
Heikki

That's true, lack of sandboxing (and the fact that all apps run as nemo, if not as root) makes it hard (if not impossible, I'm not security expert) to prevent a malicious application from finding out the secrets - at least without having the user to provide a passphrase to allow Sonar to read it's security config, and even then they might be able to spy IPC.
My idea was, that having key-based authentication would add another layer of security. Then again, I don't really know if it is easy or hard to fake the process command line on SFOS (or Linux in general - probably easy with root privs but how about with normal user privs?).

But you might be right, in the current situation what you've implemented might be as good as it gets without.

Anyway, I installed Sonar and the matching version of Situations over the weekend and I'm soon to find out how things work with them.

@hhaveri,

Haven't used Situations in a while. Will install it this week with Sonar to start testing. Maybe you can put this apps on Openrepos so a greater audience becomes available for you. Also Sonar won't be a problem there like in harbour....