kdePackages: add signon-plugin-oauth2, signon-ui, signond wrapper, nixos/signond module

[StarGate01]

This PR adds the missing pieces of the KDE Online Accounts / accounts-sso stack for Qt6. Once services.signond.enable = true is set, Google Drive becomes accessible via Dolphin and kio-gdrive on NixOS.

What is added

• kdePackages.signon-plugin-oauth2 - OAuth 1.0/2.0 plugin for signond, pinned to the Qt6-support MR (!28) tip
• kdePackages.signon-ui - D-Bus daemon that opens the OAuth browser window during account login
• kdePackages.signond - wraps the bare signond with a composable plugin list via symlinkJoin, sets SSO_PLUGINS_DIR/SSO_EXTENSIONS_DIR, and patches the D-Bus .service file to point at the wrapper so D-Bus activation picks up the plugins
• nixos/services/desktops/signond - new NixOS module (services.signond) with enable, package, and plugins options; defaults to signon-plugin-oauth2 + signon-kwallet-extension; also registers signon-ui in environment.systemPackages so D-Bus can activate it when signond requests an auth UI
• kdePackages.kaccounts-providers - gains googleClientId, googleClientSecret, withGoogleDriveScope, and withYoutubeScope override arguments for build-time credential and scope substitution

Usage

Enable the daemon and add the relevant packages to your system:

services.signond.enable = true;

environment.systemPackages = with pkgs.kdePackages; [
  kaccounts-integration
  kaccounts-providers
  kio-gdrive
];

Then open System Settings → Online Accounts, add a Google account, and Google Drive will appear in Dolphin.

The packages are not added automatically because not every user wants kio-gdrive - the module's responsibility is only to run the daemon correctly.

Google Drive scope and custom OAuth credentials

The default KDE OAuth client is not approved by Google for Drive access. kaccounts-providers exposes override arguments to substitute credentials and control which scopes are requested:

• googleClientId / googleClientSecret - replace the KDE OAuth app credentials with your own
• withGoogleDriveScope - add the drive scope (default false)
• withYoutubeScope - keep the youtube.upload scope (default true)

These are build-time substitutions into google.provider, so they are package override arguments, not NixOS module options. Apply them via an overlay:

nixpkgs.overlays = [
  (final: prev: {
    kdePackages = prev.kdePackages.overrideScope (kfinal: kprev: {
      kaccounts-providers = kprev.kaccounts-providers.override {
        googleClientId = "YOUR_CLIENT_ID";
        googleClientSecret = "YOUR_CLIENT_SECRET";
        withGoogleDriveScope = true;
        withYoutubeScope = false;
      };
    });
  })
];

The KDE credentials are left untouched by default. Users who want Drive access must supply credentials that are approved for the drive scope - either their own registered OAuth app or another client that has Google's approval for that scope.

What is deliberately not done

Auto-enabling signond in plasma6.nix is omitted. The accounts-sso upstream is effectively unmaintained (Qt6 support lives in a fork and an open MR), and KDE is actively building a replacement (KOnlineAccounts). Making it opt-in keeps the default Plasma6 configuration clean until the situation upstream stabilises.

Relation to previous PR

This is a rebase and refinement of #343023 ("nixos/plasma6: wrap signond", Sep 2024, closed Oct 2024) by @NyCodeGHG. The core packaging approach (symlinkJoin wrapper, SSO_PLUGINS_DIR) is taken directly from that PR. Differences from #343023:

• Auto-enabling in plasma6.nix removed (see above)
• services.signond module has sensible defaults (package defaults to kdePackages.signond, plugins defaults to [signon-plugin-oauth2, signon-kwallet-extension]) so a minimal services.signond.enable = true; is sufficient
• Version dates corrected to match actual upstream commit timestamps
• License fields added to both new packages

---

Background and prior art

Previous packaging attempts in nixpkgs

• nixos/plasma6: wrap signond #343023 (Sep 2024, closed Oct 2024): comprehensive PR by @NyCodeGHG adding signon-plugin-oauth2, signon-ui, a NixOS signond module, and enabling kaccounts/kio-gdrive by default. Closed after @K900 noted "accounts-sso upstream is effectively already dead, and KDE stuff is moving away from it." NyCodeGHG closed it pending a KDE replacement. Note: as of 2026 no production replacement has materialised and kio-gdrive remains the only working Google Drive solution for KDE.
• libsForQt5.signond: 8.60 -> 8.61 #164233 (merged Apr 2022): last upstream version bump of signond in nixpkgs, showing it was maintained at the Qt5 level but never ported to Qt6.

User reports: signon-plugin-oauth2 / signon-ui missing from NixOS

• Package request: signon-plugin-oauth2 #263299 - package request that confirmed both were missing
• https://discourse.nixos.org/t/unable-to-configure-google-account-in-kde-plasma-6/49297
• https://discourse.nixos.org/t/add-google-account-in-kde/24631
• https://discourse.nixos.org/t/how-can-i-enable-online-accounts-like-google-in-kde/31721
• https://discourse.nixos.org/t/how-to-use-kaccounts/14533

Root cause: userActionFinished error: 2 = missing signon-ui

The OAuth browser window is opened by signon-ui. Without it, the D-Bus call from signond returns CommunicationError (error code 2).

• https://discuss.kde.org/t/cannot-add-gdrive-online-account-fails-with-useractionfinished-error-2-after-user-name/34739
• https://gitlab.com/accounts-sso/signon-ui/-/issues/1
• https://bugs.kde.org/show_bug.cgi?id=506700

Why kio-gdrive stopped working: KDE's OAuth client lost Drive access

In June 2024 Google formally demanded that KDE either remove restricted Drive scopes from its OAuth registration or submit for re-verification within 90 days (or face a 100-user cap and an "unverified app" warning). KDE chose to remove the scope, breaking kio-gdrive for all users.

• https://bugs.kde.org/show_bug.cgi?id=480779 - primary tracking bug; covers the June 2024 Google block and the January 2025 decision to remove the Drive scope
• https://invent.kde.org/network/kio-gdrive/-/issues/1 - opened by Nate Graham (Feb 15, 2024), tracking the Google API Data Safety Team email and the choice between removing restricted Drive scopes or applying for re-verification
• https://invent.kde.org/-/project/2380/uploads/5df1df971aba566ba3d743661fe4438b/_Action_Required__Changes_to_Google_Drive_API_Access.eml - the formal demand from the Google API Data Safety Team to kde-ev-board@kde.org
• https://invent.kde.org/network/kaccounts-providers/-/commits/master/providers/google.provider.in - commit 1652091b by Nate Graham, "Google: stop requesting gdrive permission"
• https://discuss.kde.org/t/google-blocks-access-from-dolphin-kio-gdrive/26007
• https://discuss.kde.org/t/kio-gdrive-not-working/36637
• https://discourse.nixos.org/t/kde-dolphin-without-online-accounts-setting-kde-package-kio-gdrive-googledrive/22085
• https://discourse.nixos.org/t/virtually-mounting-google-drive/46338

Future: KOnlineAccounts - the planned replacement

The accounts-sso stack (signond, signon-plugin-oauth2, signon-ui) is effectively unmaintained and KDE is actively working on a replacement. This PR is a stopgap until KOnlineAccounts matures and kio-gdrive or its successor adopts it.

• https://nicolasfella.de/posts/a-new-online-accounts-system/ - blog post by Nicolas Fella proposing a new daemon-based system with D-Bus, per-application access control, and minimal dependencies; working prototype supports Nextcloud, Mastodon, and Google
• https://invent.kde.org/system/konlineaccounts - the implementation; early-stage (v0.1.0, ~42 commits) but actively developed; latest commits focus on security hardening (access control, secret passing via fd exchange). Not yet viable for kio-gdrive: no token refresh logic.
• https://bugs.kde.org/show_bug.cgi?id=378814#c8 - KDE bug thread where the replacement effort was announced

---

cc @NyCodeGHG @K900 @OPNA2608 @Scrumplex @NickCao

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[K900]

Is this AI generated?

[StarGate01]

I did use Claude to help write the PR description (Is there a policy on AI use in nixpkgs?), because I wanted to document the issues leading up to this for the future - esp. The KDE gdrive blocking was worth linking to imho. The code largely came from #343023, which I rebased and trimmed down, and then made sure everything worked on my system.

[K900]

Honestly, I don't want to be responsible for maintaining this going forward, especially given upstream's extremely-dead state. Is there a reason you can't use something like rclone instead?

[StarGate01]

Okay. I will move it into a out-of-tree overlay then, so it does not have to be maintained in nixpkgs. Thank you for confirming! The reson I did not want to use rclone (or other syncing tools), is that I like to use the "virtualized" lazy-loaded folder view in Dolphin, which allows me to browse my (huge) drive, without syncing everything down.

Anyway, closing this in favor of having it out of tree.

[K900]

rclone mount can achieve the same thing as a FUSE filesystem.

[OPNA2608]

(iunno why I was pinged, but I might as well chime in)

Lomiri and SailfishOS also use accounts-sso stuff. Given that the Lomiri Qt6 porting board includes tickets for porting accounts-sso software to Qt6 / CMake upstream, I doubt that porting off of that stack is currently being considered / worked on.

I have really low time & desire to get this stuff actually working properly though, as it doesn't really come up in my desktop usage (#340391), so I wouldn't be able to review & test this (or even know if it would affect the Lomiri desktop)…

---

I did use Claude to help write the PR description (Is there a policy on AI use in nixpkgs?)

An initial one is currently being worked out: #514587