App security (new KeepassRX app)

[RandomUser]

@arubislander Thanks for the information, something like this is what I was looking for.

[Vlad Nirky]

@RandomUser
The guy is super motivated and the app is evolving very quickly. It has already caught up with Focal and promises to evolve even further.
Really great!

[kugiigi]

To be fair, this is a valid concern. I wonder if it's a good idea to notify users when an app update changes or adds new apparmor policy in the new version.

[arubislander]

@kugiigi Was not saying the concern is not valid. Was saying it can be assuaged, and showing how. The permissions requested are also listed in the Open Store itself.

But you do raise a good point. Maybe like a dialog box listing the new permissions that are requested since the last update, which gives the option to proceed or cancel.

[klh]

@t12392n said in App security (new KeepassRX app):

A local Keepass should not talk to the internet.

Where did you get the idea that it does?

@arubislander said in App security (new KeepassRX app):

If the app is confined (as this one is) you don't need to blindly trust that the package in the open store was compiled by the code that is linked, to be sure it doesn't phone home. If you know what to look for, you can download the .click package and examine the contents.

All versions of OpenStore also show the permissions list and that should be the first thing people check, can't expect non-technical users to unpack clicks before installation.

Kind of related, we should probably update the popup when you install from a local .click file to show more info and definitely show permissions.

[arubislander]

@klh said in App security (new KeepassRX app):

All versions of OpenStore also show the permissions list and that should be the first thing people check, can't expect non-technical users to unpack clicks before installation.

Fully agreed. But RandomUser did not strike me as someone who would necessarily trust second hand information. So I showed a way they could check for themselves.

[RandomUser]

@Vlad-Nirky said in App security (new KeepassRX app):

@RandomUser
The guy is super motivated and the app is evolving very quickly. It has already caught up with Focal and promises to evolve even further.
Really great!

I'm not denying that, I can see the progress and appreciate all the work he's doing, genuinely. But you give the app access to all your passwords, I don't think it's unreasonable to be a bit cautious.

[Vlad Nirky]

@RandomUser
Yes, of course.
That's already what I do with KeepassXC on my PC.
My choice is to do it locally and not on the Bitwarden or Dashlane web servers.
Most of them have MFA.
I understand your concern about having a clear view of what the application can use.
And Maciek's idea of blocking installation until we accept a change in the permissions granted seems excellent to me.

[t12392n]

@arubislander said in App security (new KeepassRX app):

@t12392n said in App security (new KeepassRX app):

I wish there was an strict firewall native in Ubuntu Touch so that we would see and control what is allowed to talk. A local Keepass should not talk to the internet.

If the app is confined (as this one is) you don't need to blindly trust that the package in the open store was compiled by the code that is linked, to be sure it doesn't phone home. If you know what to look for, you can download the .click package and examine the contents. The most important is the .apparmor file, which describes what permissions the packages requests from the system.

Admittingly, I am lacking full understanding of how this .click system works nor having deep understanding of how App Armor so I am at an disadvantage.

But thanks for the note, I will need to re up on both .click packages!

@klh said in App security (new KeepassRX app):

@t12392n said in App security (new KeepassRX app):

A local Keepass should not talk to the internet.

Where did you get the idea that it does?

My mistake, I should have been more clear that it was an example case that a password app should never need to talk with the internet, which believe it or not, is common with apps on Google Play store.

[pparent]

@arubislander @RandomUser
It could be a nice idea to allow the openstore to build itself to build the app:

-The developer provides the repository with clickable app (github, gitlab, ect...)
-The openstore builds the app, when the developer wants to publish a new version, and publishes it alongside the source tarball.

It would increase the level of trust.

[arubislander]

@pparent That would mean that only open source projects would be allowed into the Open Store. While I am not opposed to that per se, that has never been the premise of the Open Store.

[pparent]

@arubislander

No this would be an optional option to get the badge "Built by openstore" (Or whatever it is called)

[arubislander]

@pparent O I see.. I didn't get the optional part initially.

[poVoq]

@pparent an alternative app store more akin to f-droid that only allows open-source apps and builds them itself would be also good.

[gpatel-fr]

@poVoq

how about ...f-droid ? following the actuality, they seem to not be entirely happy with Google just now. Technically it remains to be seen how complex it would be for them to build native UT apps and how complex it would be for UT to allow native apps installation from a waydroid app of course, something about which I have no idea

[pparent]

@poVoq

There is already, waydroid, libertine, snap, I think maybe we don't need an alternative store to make things even more complicated!

[poVoq]

@pparent Waydroid and libertine aren't app distribution channels and snaps are just terrible (and centralized with a proprietary backend).

Maybe if there was proper Flatpak support in UT, but that still wouldn't give us click-packages.