Provide way for Flatpak to retrieve credentials

[marbetschar]

Problem

Flatpacked apps using EDS are not able to retrieve credentials from the host system. Thats why we did not Flatpack Mail till now (elementary/mail#591) and also ran into problems with Tasks for certain operations (elementary/tasks#263).

Proposal

Ideally we should re-use an existing way to retrieve the credentials from the host system.

Prior Art

@Marukesu found a way to escape the sandbox and retrieve the credentials from the host system: elementary/tasks#263 (comment)

[marbetschar]

@Marukesu I created a topic over at the GNOME forum just to double check if we miss something here: https://discourse.gnome.org/t/flatpack-retrieve-credentials-from-host-eds/7359

Meanwhile: Any chance you can add such a DBus service to this Online Accounts plug as custom branch? We'll most likely need to put it elsewhere before shipping - but this way we can do a quick proof of concept and try to access it from the Tasks app.

If this works, we should ultimately be able to package Mail as Flatpack as well 🥳

[Marukesu]

I created the dbus-daemon branch implementing the password lookup part on the host.

[marbetschar]

@Marukesu I created the online-accounts-dbus companion branch in Tasks - but I keep getting a GDBus.Error:org.freedekstop.DBus.Error.ServiceUnknown error. Any idea why?

I compiled and ran your dbus-daemon manually in Terminal with /usr/libexec/online-accounts-daemon and it claims 'io.elementary.switchboard.online-accounts' aquired.

[marbetschar]

I also came across the --talk-name=org.gnome.OnlineAccounts DBus interface which seems to already exist and serve a similar purpose - and there is the goa-1.0 package on valadoc.org

Wondering if we really need to roll our own DBus service for this - or if we can simply configure the accounts through the goa lib, grant access to the goa DBus for our Flatpacked, EDS using apps (Calendar, Tasks & Mail) and they pick up the accounts and credentials configured in goa automagically... @tintou?

[Marukesu]

I created the online-accounts-dbus companion branch in Tasks - but I keep getting a GDBus.Error:org.freedekstop.DBus.Error.ServiceUnknown error. Any idea why?

You need to add --talk-name=io.elementary.switchboard.online-accounts to the manifest.

I compiled and ran your dbus-daemon manually in Terminal with /usr/libexec/online-accounts-daemon and it claims 'io.elementary.switchboard.online-accounts' aquired.

That happens when the daemon successfully register itself to the session bus.

[marbetschar]

Ok; retrieving the credentials works now and I'm again able to modify the task lists color for example. So this is definitely an improvement.

However, do we really roll our own DBus service to handle this? If so, we will probably need to handle OAuth2 tokens with it as well further down the road (e.g. for Google) - and I feel like this stuff was probably already solved somehow/somewhere. Maybe goa-1.0 is really worth a try as commented above..?

UPDATE: We don't want GNOME Online Accounts. We will need our own credential portal indeed but that requires a lot of thought.

[marbetschar]

What we really want for this is a Flatpak Portal. Here's the corresponding discussion from Slack:

You need an authorization flow that would be like this:

• Have an "Add account…" on the app (that sends some settings to the portal like supported auth type (ex: password), account types (ex: imap+smtp or pop3+smtp for password)
• Then the portal process the querry,
  • if you already have an account configured that is not yet allowed, show a dialog with a list of available accounts and a "Add new account…", clicking on an account would return it to the app, clicking on the "Add new account…" would go next case
  • if you don't have an account configured (or you clicked "Add new account…"), then the online account plug is opened at the "Add account" page

So basically, that's not just a credential portal, we don't want to mimic libsecret on D-Bus which isn't exposed for reasons - because we need a way to tell if the credentials requesting app is authorized. Otherwise a malicious app could request any credentials and/or spoof another app's id to do so. So a simple DBus handing over whatever credentials are requested is a serious security hole. That's why it's a portal, you always know the origin of the request that way.

We should be able to start out with a minimal proof of concept: A portal supporting the full flow for CalDAV accounts only (since this is essentially only three properties uri, username and password) - and then build from there for IMAP/SMTP, OAuth, ... Also remember that for OAuth, each app will need to provide a different Client Secret, only elementary official apps can use the elementary one.