moonshot-ui needs to support libsecret1
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Moonshot ID Selector |
New
|
High
|
Unassigned | ||
moonshot-ui (Debian) |
Fix Released
|
Unknown
|
Bug Description
Debian and Ubuntu are removing libgnome-keyring in favor of the freedesktop.org secret service.
For most OSes, libgnome-keyring has actually been proxying to the secret service for a while now (although Centos6 may be old enough that is not the case).
The APIs are similar, but significantly different.
I've written a patch which I've checked in on the libsecret branch of the moonshot-ui repository to add this support.
I'd appreciate review of that patch before releasing in Debian.
The patch significantly refactors the keyring store code.
* All the code that is independent of how we get to the linux keyring is factored into an abstract base class KeyringStoreBase (src/moonshot-
* The serialization and deserialization code was inline with the load and store functions. Those functions were overly complex and would be hard to reuse in a future-proof manner. Refactored the deserialization and serialization code into the abstract base class. Seting with both libsecret and gnome-keyring suggests that I seem to have not accidentally changed the serialization format.
* Create moonshot-
* Enable keyring if either LIBSECRET_KEYRING or GNOME_KEYRING are defined.
Again, this is available on the libsecret gitlab branch for review. I'd like to check this into Debian within a week or so to get in time for the buster freeze starting in January.
Changed in moonshot-ui (Debian): | |
status: | Unknown → New |
Changed in moonshot-ui (Debian): | |
status: | New → Fix Released |
> Debian and Ubuntu are removing libgnome-keyring in favor of the freedesktop.org secret service.
> For most OSes, libgnome-keyring has actually been proxying to the secret service for a while now (although Centos6 may be old enough that is not the case).
Indeed, in CentOS6 there is not libsecret available.
>
> The APIs are similar, but significantly different.
Yes.
> store-base. vala). In any given build we'll only have one keyring- store-secret| gnome.vala that both implement
> I've written a patch which I've checked in on the libsecret branch of the moonshot-ui repository to add this support.
> I'd appreciate review of that patch before releasing in Debian.
>
> The patch significantly refactors the keyring store code.
>
> * All the code that is independent of how we get to the linux keyring is
> factored into an abstract base class KeyringStoreBase (src/moonshot-
> keyring-
> implementation of this class, but separation of concerns made it
> significantly easier to design the code and factor out common elements.
>
> * The serialization and deserialization code was inline with the load
> and store functions. Those functions were overly complex and would be
> hard to reuse in a future-proof manner. Refactored the deserialization
> and serialization code into the abstract base class. Seting with both
> libsecret and gnome-keyring suggests that I seem to have not
> accidentally changed the serialization format.
>
> * Create moonshot-
> KeyringStore. At most one of these will be selected by configure.ac
> logic.
>
> * Enable keyring if either LIBSECRET_KEYRING or GNOME_KEYRING are
> defined.
>
> Again, this is available on the libsecret gitlab branch for review. I'd
> like to check this into Debian within a week or so to get in time for
> the buster freeze starting in January.
I agree with the proposed changes. I'm actually reviewing the code right
now and passing it through the CI.
I will provide feedback and additional commits to fix support for
CentOS6, Ubuntu 14.04 and Alpine that seem to not work out of the box.
Centos 7, Debian 8 and 9 and Ubuntu 16.04 and 18.04 seem ok.