Merging signond and gsignond

[Alberto Mardegan]

Hi all,
Corentin filed a bug [1] asking about the possibility of merging
signond and gsignond. I think this is a good topic for a mailing list
discussion, also to count how many we effectively are.

The premise: we are talking about two half-dead projects: as far as I
know, Intel is no longer involved in Tizen, so the gsignond project is
effectively maintained by Elementary OS only.
The recent changes announced by Canonical have seen me being laid off
so, despite me caring a lot of this project, if -- as I expect -- I'm
getting another job, I won't have much time to contribute to this
project beside core reviews and bug fixing. Other contributors to this
projects are KDE and Sailfish OS, but AFAIK both are investing very
limited resources on it.

So I think it makes a lot of sense to try to eliminate the differences,
and hopefully converge on a single code-base.

The first goal, IMHO, should be to eliminate the differences on the
D-Bus API, because that will make it trivial to unify at list
libsignon-glib with libgsignon-glib: if at least we can offer an unified
API to Elementary, KDE and Sailfish client developers, we can hope that
projects won't be as shy in using it.

To this goal, the only realistic way forward is for gsignond to revert
the incompatible changes it introduced on the D-Bus API: not only
because historically it's gsignond which diverged, but because we should
strive to have minimal changes as possible to the platforms using
[g]signond. Also, keep in mind there are Qt and QML APIs talking to the
signond D-Bus API.
Of course, if the changes to the D-Bus signatures which made gsignond
diverge from signond are still needed (I doubt so, given that Elementary
doesn't use them), feel free to keep them, but these should anyway be
moved as separate methods (or possibly, on a separate interface).

Then every platform interested in using the project will be able to
freely choose which signond implementation to use, and hopefully we'll
see them converge into a single choice.

Ciao,
Alberto


[1]: https://gitlab.com/accounts-sso/signond/issues/5

[Jussi Laako]

On 21.04.2017 09:57, Alberto Mardegan wrote:
> To this goal, the only realistic way forward is for gsignond to revert
> the incompatible changes it introduced on the D-Bus API: not only
> because historically it's gsignond which diverged, but because we should
> strive to have minimal changes as possible to the platforms using
> [g]signond. Also, keep in mind there are Qt and QML APIs talking to the
> signond D-Bus API.

At least I'm not willing to revert those, as lot of changes have gone to
those parts in order to support runtimes like node.js. I would rather
propose that signond would implement the security context tuple support.

gsignond was also included in our Ostro project:
https://ostroproject.org/

In that scope I also implemented TPM 1.2 support for storing encryption
keys for eCryptFS. I am planning to extend that to TPM 2.0 in somewhat
near future. For that purpose, there's also the Ostro platform plugin.

> Of course, if the changes to the D-Bus signatures which made gsignond
> diverge from signond are still needed (I doubt so, given that Elementary
> doesn't use them), feel free to keep them, but these should anyway be
> moved as separate methods (or possibly, on a separate interface).

It doesn't really need much "use", because large part of the Unix access
control system I implemented is automatic.

This is needed in IoT systems where different daemons want to access
cloud services. And node.js and Python engines are typical for this kind
of use. The dual security context system is now more important than
ever, to differentiate between runtime (node.js, JRE, .NET, etc) and the
application running within the runtime. System context grants trust to
the process while application context grants trust to the application
running within the runtime. This same can also be applied to virtual
machines and such. System context would cover the virtual machine scope
and application context the things running within the virtual machine.

> Then every platform interested in using the project will be able to
> freely choose which signond implementation to use, and hopefully we'll
> see them converge into a single choice.

I don't mind a bit of divergence. I believe the Qt-based signond is more
geared towards desktop-type environments, while gsignond is more geared
towards IVI and IoT systems.

[Corentin Noël]

To me there are only two possibilities :

 * We merge the DBus API and the two daemons remains

 * Only one daemon remains

The application context is indeed a good idea and shouldn't be removed, I wonder if Signon handles it ?

KDE stated that they want to keep the Signon daemon so I hope that they also want to maintain it…

I'll try to submit changes to Signond and gSignond in order to resync the two API if that's what people want.

Once it's done, it might be a good idea to remove one of the client GLib library as they will both use the same DBus API.

[Martin Klapetek]

First of all, thanks Mardy for starting this thread!

I think this discussion is important to have.

On Wed, Apr 26, 2017 at 3:19 AM, Corentin Noël <core...@elementaryos.org> wrote:

To me there are only two possibilities :

 * We merge the DBus API and the two daemons remains

 * Only one daemon remains

The application context is indeed a good idea and shouldn't be removed, I wonder if Signon handles it ?

I believe there is some support for that, I do not know

how extensive it is however.

 

KDE stated that they want to keep the Signon daemon so I hope that they also want to maintain it…

To give more context - I said that it's much easier for us

to maintain a Qt daemon where we'd be able to fix bugs

ourselves and much quicker, compared to GLib which

we have minimum to zero experience with. It also makes

more sense for our platform context, just like it does for

Elementary to prefer the GLib daemon.

 

I'll try to submit changes to Signond and gSignond in order to resync the two API if that's what people want.

I think that'd be nice and I think I'd support that effort.

I also think it'd be nice to propose it here first and then

do the actual work, planning is important.

 

Once it's done, it might be a good idea to remove one of the client GLib library as they will both use the same DBus API.

If I'm not mistaken, one of the Qt libs is using the GLib

library, which means the Qt library would have to be

ported if the "wrong" one is removed, which is fine and

I may try and help with that, it's just something that we

should keep in mind. 

Cheers

--

Martin Klapetek

[Alberto Mardegan]

On 04/27/2017 05:14 PM, Martin Klapetek wrote:

> I'll try to submit changes to Signond and gSignond in order to
> resync the two API if that's what people want.
>
> I think that'd be nice and I think I'd support that effort.
> I also think it'd be nice to propose it here first and then
> do the actual work, planning is important.

I see that gsignond uses a different interface than signond
("com.google.code.AccountsSSO.gSingleSignOn") and that's good, because
it allows us to implement the same interface in signond without breaking
our existing D-Bus API.

So, I'm all for adding the "com.google.code.AccountsSSO.gSingleSignOn"
interface to signond, while keeping the existing one available.

> Once it's done, it might be a good idea to remove one of the client
> GLib library as they will both use the same DBus API.
>
> If I'm not mistaken, one of the Qt libs is using the GLib
> library, which means the Qt library would have to be
> ported if the "wrong" one is removed, which is fine and
> I may try and help with that, it's just something that we
> should keep in mind.

No, you are probably thinking of libaccounts-qt, which is a wrapper
around libaccounts-glib, but this library has not been forked so there's
no problem there. libsignon-qt uses QtDBus to talk directly to signond,
and it lives in the same source tree.
On the other hand, until we get some request from people to add the
application security context to libsignon-qt, it may be that we don't
have to touch this library at all (and that's also why it's important
that the existing signond D-Bus interface remains available).

We'll eventually also need to make the authentication plugins use the
same parameter names, but let's keep it as a second step (and it's not
going to be hard).

Ciao,
Alberto

--
http://blog.mardy.it <- geek in un lingua international!

[Corentin Noël]

Le jeu. 27 avril 2017 à 16:31, Alberto Mardegan <ma...@users.sourceforge.net> a écrit :

On 04/27/2017 05:14 PM, Martin Klapetek wrote:

I'll try to submit changes to Signond and gSignond in order to resync the two API if that's what people want. I think that'd be nice and I think I'd support that effort. I also think it'd be nice to propose it here first and then do the actual work, planning is important.

I see that gsignond uses a different interface than signond ("com.google.code.AccountsSSO.gSingleSignOn") and that's good, because it allows us to implement the same interface in signond without breaking our existing D-Bus API. So, I'm all for adding the "com.google.code.AccountsSSO.gSingleSignOn" interface to signond, while keeping the existing one available.

Once it's done, it might be a good idea to remove one of the client GLib library as they will both use the same DBus API. If I'm not mistaken, one of the Qt libs is using the GLib library, which means the Qt library would have to be ported if the "wrong" one is removed, which is fine and I may try and help with that, it's just something that we should keep in mind.

No, you are probably thinking of libaccounts-qt, which is a wrapper around libaccounts-glib, but this library has not been forked so there's no problem there. libsignon-qt uses QtDBus to talk directly to signond, and it lives in the same source tree.

I've opened https://gitlab.com/accounts-sso/signond/issues/6 because I would find it better to have them living on a different source tree showing that they are really independant.

On the other hand, until we get some request from people to add the application security context to libsignon-qt, it may be that we don't have to touch this library at all (and that's also why it's important that the existing signond D-Bus interface remains available). We'll eventually also need to make the authentication plugins use the same parameter names, but let's keep it as a second step (and it's not going to be hard). Ciao, Alberto

--

http://blog.mardy.it <- geek in un lingua international!

To be honest, I would have preferred to break the D-Bus API, it's clearly written that it might change with the time. What I don't want to break is the lib{g}signon API because that's what developer should be using right now.

Here is a proposal of the united API, you can notice that I removed some D-Bus methods because I sometimes just don't find them useful, be free to comment on this.

Here is a link to the Google Document of the D-Bus API, you can put your comments:

https://docs.google.com/document/d/1gGMRHNjmHgL6m4KzaRMzBCpbAqTAlkeJwyb-oyaVm24/edit?usp=sharing

Once we all agree on the API, the work to port libsignon-{glib,qt}, signond and gsignond can work.

I changed the D-Bus interface name to clearly be incompatible with older D-Bus API. When the work will be done, all the components should be released at the same time to be packaged together.

[Alberto Mardegan]

On 04/28/2017 06:54 PM, Corentin Noël wrote:
>
> I've opened https://gitlab.com/accounts-sso/signond/issues/6 because I
> would find it better to have them living on a different source tree
> showing that they are really independant.

They are kind of dependent in many ways, but let's leave this aside for
now :-)

> To be honest, I would have preferred to break the D-Bus API, it's
> clearly written that it might change with the time. What I don't want to
> break is the lib{g}signon API because that's what developer should be
> using right now.

100% agree on not breaking the glib client API. As far as the D-Bus API
is concerned, if we move it to a new interface then nothing prevents us
from keeping the old API alive for some time.

> Here is a proposal of the united API, you can notice that I removed some
> D-Bus methods because I sometimes just don't find them useful, be free
> to comment on this.

I haven't had a thorough look, but it seems OK. I notice you removed the
backup-related methods, and that's also fine for at least KDE. I'm not
sure if Sailfish OS is using them, but if we keep the old API available
in the old interface, it's fine to remove them from the new one.

> Here is a link to the Google Document of the D-Bus API, you can put your
> comments:
> https://docs.google.com/document/d/1gGMRHNjmHgL6m4KzaRMzBCpbAqTAlkeJwyb-oyaVm24/edit?usp=sharing

Added a comment there.

> I changed the D-Bus interface name to clearly be incompatible with older
> D-Bus API. When the work will be done, all the components should be
> released at the same time to be packaged together.

This is usually difficult for distributions, and as I wrote before, I
think we can give a migration grace time: given that you are suggesting
a new interface name (and I fully agree with your proposal), there's no
need to get rid of the existing interfaces now. We'll just migrate the
client libraries to use the new interface, and we'll clean up the
daemons later.

Anyway, thanks a lot for your work! :-)

[Jussi Laako]

On 28.04.2017 18:54, Corentin Noël wrote:
> Here is a link to the Google Document of the D-Bus API, you can put your
> comments:
> https://docs.google.com/document/d/1gGMRHNjmHgL6m4KzaRMzBCpbAqTAlkeJwyb-oyaVm24/edit?usp=sharing

At least so far I have not spotted particularly problematic changes.

The unregistered signal seems to have been removed from AuthSession
object, which has never been properly supported. The intention was to
gracefully handle case when identity has been removed (by the user
through GUI) while being in use by some application. So essentially it
is linked to the Identity::Removed signal which still exists, but since
application should have also Identity handle, this can be pushed to be
responsibility of application to handle through that one.

...

For the message entries it could be good to just document how the
message translation/localization is supposed to be handled! There have
been number of discussions about this over time. It could be done at the
plugin side, assuming the plugin knows about language setting. In that
case it would be easier to handle dynamic strings that convey more
contextual information. While doing localization at the GUI side would
require passing static "engineering English" strings... This is now our
chance to get this one right. ;)

...

A note about the backup part, the old methods were not that great but
necessary especially when backup of the encrypted LUKS container was
made. We don't use those at the moment and I'm fine removing it.
gsignond uses eCryptFS (and hopefully later on ext4 encryption) with
keys stored in TPM. TPM can be found in many PCs and even more now with
TPM 2.0. Many motherboards have a socket for TPM 1.2 module. Making
backup of the TPM key is not possible, on purpose. So any backup would
need to be made with the eCryptFS filesystem mounted, which in turn
involves a bit of setup sequence with the TPM chip. This TPM part is
especially important for cases where there's no user entering passphrase
at bootup case, such as IoT devices. I am planning to make a generic
"extension" or what we nowadays call "platform plugin" that is generic
for normal PCs. It is essentially same as the current Ostro plugin, but
without SMACK support and using Unix DAC instead, while keeping TPM support.

So at some point in future, there would need to be added some specific
backup method that asks gsignond to perform a backup...