Skip to content

Linux AppImage does not persist SmartLink credentials via KDE Wallet / QtKeychain #3639

Description

@milenjb

Title: Linux AppImage does not persist SmartLink credentials via KDE Wallet / QtKeychain

What happened?

On Manjaro Linux with KDE, SmartLink Remote login remembers my email address but does not remember or restore the SmartLink password / saved login state when using the official AetherSDR-v26.6.3-x86_64.AppImage.

This happens every time I launch AetherSDR from the AppImage. After entering my SmartLink credentials and logging in successfully, quitting and restarting the AppImage results in the email field being pre-filled, but the password/login state is not restored and I have to authenticate again.

KDE Wallet appears to be working on the system:

  • qt6-keychain is installed
  • kwalletmanager is installed
  • libsecret is installed
  • The default kdewallet is enabled and open

However, KDE Wallet Manager does not show any saved AetherSDR credentials or application connection, and I never see a KDE Wallet prompt asking whether AetherSDR may access the wallet. That makes it look like the AppImage either never attempts keychain access, or the attempt is failing silently before KDE Wallet is reached.

I tried launching the AppImage with stdout/stderr captured:

./AetherSDR-v26.6.3-x86_64.AppImage 2>&1 | tee ~/aethersdr-keychain.log
grep -iE 'keychain|wallet|secret|dbus|smartlink|auth|token|credential|error' ~/aethersdr-keychain.log

The only output was unrelated ALSA / AppImage runtime noise:

ALSA lib pcm_dsnoop.c:572:(snd_pcm_dsnoop_open) [error.pcm] unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) [error.pcm] unable to open slave
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) [error.pcm] Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) [error.pcm] Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) [error.pcm] Unknown PCM cards.pcm.side
ALSA lib pcm_oss.c:404:(_snd_pcm_oss_open) [error.] Cannot open device /dev/dsp
ALSA lib pcm_oss.c:404:(_snd_pcm_oss_open) [error.] Cannot open device /dev/dsp
ALSA lib dlmisc.c:339:(snd_dlobj_cache_get0) [error.core] Cannot open shared library libasound_module_pcm_a52.so (/tmp/.mount_AetherjPBMGF/usr/bin/../lib/libsystemd.so.0: version `LIBSYSTEMD_251' not found (required by /usr/lib/libmount.so.1))
ALSA lib dlmisc.c:339:(snd_dlobj_cache_get0) [error.core] Cannot open shared library libasound_module_pcm_a52.so (/tmp/.mount_AetherjPBMGF/usr/bin/../lib/libsystemd.so.0: version `LIBSYSTEMD_251' not found (required by /usr/lib/libmount.so.1))
ALSA lib confmisc.c:160:(snd_config_get_card) [error.core] Invalid field card
ALSA lib pcm_usb_stream.c:481:(_snd_pcm_usb_stream_open) [error.] Invalid card 'card'
ALSA lib confmisc.c:160:(snd_config_get_card) [error.core] Invalid field card
ALSA lib pcm_usb_stream.c:481:(_snd_pcm_usb_stream_open) [error.] Invalid card 'card'
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) [error.pcm] unable to open slave

I also checked the user journal:

journalctl --user -b | grep -iE 'aether|kwallet|wallet|keychain|secret|dbus'

That did not show any useful KDE Wallet, keychain, D-Bus, or AetherSDR errors.

In ~/.config/AetherSDR/logs/, the only SmartLink-related line I found was:

[14:54:53.465] WRN aether.smartlink: WanConnection: peer presented no certificate; skipping TOFU check

The important comparison is that I then built the same AetherSDR version from source on the same Manjaro/KDE system. The locally built binary does find the wallet, connect to it, store the SmartLink credential, and retrieve it successfully. The AppImage still does not use the saved credential, even after the source-built binary has already stored it in the wallet.

So this appears specific to the official Linux AppImage packaging/runtime environment, not to my KDE Wallet configuration.

What did you expect?

The Linux AppImage should behave the same as the locally built binary:

  • After a successful SmartLink login, AetherSDR should store the SmartLink refresh token / credential in the system credential store through QtKeychain.
  • On KDE, this should use KDE Wallet, likely through the QtKeychain KWallet backend.
  • KDE Wallet Manager should show an AetherSDR-related saved credential or application access entry.
  • On the next AppImage launch, AetherSDR should retrieve the saved SmartLink credential and either auto-login or avoid requiring the SmartLink password again.
  • If keychain support is unavailable in the AppImage, AetherSDR should log a clear warning such as “SmartLink credential persistence disabled: Qt6Keychain not available” rather than failing silently.
  • If keychain support is compiled in but the KWallet/libsecret/D-Bus backend fails at runtime, that failure should be visible in the AetherSDR support log under SmartLink diagnostics.

Steps to reproduce

  1. On Manjaro Linux with KDE, install/enable the normal wallet/keychain components:

    • qt6-keychain
    • kwalletmanager
    • libsecret
    • default kdewallet enabled and open
  2. Download/run the official Linux AppImage:

    ./AetherSDR-v26.6.3-x86_64.AppImage
  3. Open SmartLink / Remote login.

  4. Enter SmartLink email and password.

  5. Complete login successfully.

  6. Quit AetherSDR.

  7. Re-launch the same AppImage.

  8. Open SmartLink / Remote login again.

  9. Observe that the email address is remembered, but the password / saved login state is not restored.

  10. Check KDE Wallet Manager.

  11. Observe that there is no visible AetherSDR credential or wallet application connection.

  12. Build AetherSDR v26.6.3 from source on the same machine.

  13. Run the locally built binary.

  14. Repeat SmartLink login.

  15. Observe that the source-built binary successfully stores and retrieves the SmartLink credential through KDE Wallet.

  16. Re-run the AppImage.

  17. Observe that the AppImage still does not retrieve the credential saved by the source-built binary.

Radio model & firmware

Radio: not connected / N/A

This was reproduced at the SmartLink login stage without a radio connection.

OS & version

  • OS: Linux

  • Distribution / desktop: Manjaro Linux with KDE

  • AetherSDR version: 26.6.3

  • Package: official AetherSDR-v26.6.3-x86_64.AppImage

  • Qt version: 6.8.3

  • Wallet/keychain packages installed:

    • qt6-keychain
    • kwalletmanager
    • libsecret
  • KDE Wallet:

    • default kdewallet enabled
    • wallet open during test

Developer Notes

This looks most likely to be a Linux AppImage packaging/runtime issue around QtKeychain rather than a SmartLink authentication logic issue.

Relevant project context:

  • CLAUDE.md points to AGENTS.md as the canonical project guide.
  • AGENTS.md says AetherSDR is a Qt6/C++20 SmartSDR client, uses AppSettings for client settings, and exposes runtime diagnostic categories through Help → Support.
  • AGENTS.md also notes that user-facing support instructions should refer to the Help → Support logging labels, not only backend category names.

Most likely source areas:

  • src/core/SmartLinkClient.cpp

    • SmartLinkClient::login(...)

      • Stores the email address in AppSettings as SmartLinkEmail.
      • Receives the Auth0 refresh_token.
      • Calls saveCredentials() after successful login.
      • This explains why the email is remembered even when the password/login state is not.
    • SmartLinkClient::saveCredentials()

      • Uses QKeychain::WritePasswordJob("AetherSDR").

      • Uses key smartlink_refresh_token.

      • Calls job->setTextData(m_refreshToken).

      • Logs either:

        • SmartLinkClient: keychain save failed: ...
        • or SmartLinkClient: refresh token saved to keychain
      • The whole body is guarded by #ifdef HAVE_KEYCHAIN.

    • SmartLinkClient::tryAutoLogin()

      • Uses QKeychain::ReadPasswordJob("AetherSDR").

      • Reads key smartlink_refresh_token.

      • Calls loginWithRefreshToken(...) if a token is found.

      • Logs either:

        • SmartLinkClient: no stored credentials
        • or SmartLinkClient: found stored refresh token, attempting auto-login
      • This is also guarded by #ifdef HAVE_KEYCHAIN.

    • SmartLinkClient::clearCredentials()

      • Uses QKeychain::DeletePasswordJob("AetherSDR").
      • Removes SmartLinkEmail from AppSettings.
      • Also guarded by #ifdef HAVE_KEYCHAIN.
  • src/core/SmartLinkClient.h

    • Declares:

      • tryAutoLogin()
      • saveCredentials()
      • clearCredentials()
      • loginWithRefreshToken(...)
  • CMakeLists.txt

    • Around the Qt dependency discovery section, AetherSDR does:

      find_package(Qt6Keychain QUIET)
      
      if(Qt6Keychain_FOUND)
          message(STATUS "Qt6Keychain found — SmartLink credential persistence enabled")
      else()
          message(STATUS "Qt6Keychain not found — SmartLink credential persistence disabled")
      endif()
    • If Qt6Keychain is not found at AppImage build time, HAVE_KEYCHAIN appears to be left undefined and all SmartLink credential persistence code compiles out.

    • Because the credential methods are behind #ifdef HAVE_KEYCHAIN, there may be no runtime warning at all in the AppImage when credential persistence is compiled out.

  • src/core/LogManager.cpp

    • Defines the relevant logging category:

      • backend category: aether.smartlink
      • Help → Support label: SmartLink
      • description: Auth0 login, TLS tunnel, WAN streaming
    • It also defines diagnostic logging categories visible in Help → Support.

  • src/gui/SupportDialog.cpp

    • Builds the Help → Support diagnostic logging UI from LogManager::categories().
    • The support workflow says logging changes take effect on next launch.

Recommended logging categories to enable in Help → Support before reproducing:

  • SmartLink

    • Most important category.
    • Should capture Auth0 login, refresh-token login, SmartLink TLS connection, and keychain save/read success/failure if HAVE_KEYCHAIN is enabled.
  • GUI

    • May help confirm SmartLink dialog behavior and whether auto-login is attempted from the UI path.
  • Connection / Commands

    • Useful if the login proceeds to SmartLink server connection.
  • Protocol / Status

    • Probably less directly relevant because no radio is connected, but useful if the issue is reproduced with a radio later.

Potential root causes:

  1. Linux AppImage was built without Qt6Keychain support

    • This is the strongest hypothesis.

    • The local source build on the same machine works with the wallet, which proves the system wallet setup is functional.

    • The AppImage does not show any KWallet prompt, wallet entry, or keychain log messages.

    • If find_package(Qt6Keychain QUIET) failed during the AppImage build, HAVE_KEYCHAIN would be undefined and saveCredentials() / tryAutoLogin() would compile to no-ops.

    • That would exactly match the observed behavior:

      • email persists through AppSettings
      • refresh token does not persist
      • no KDE Wallet prompt
      • no AetherSDR wallet entry
      • no keychain error log
  2. QtKeychain is compiled in but its Linux backend is not usable inside the AppImage runtime

    • The AppImage may be missing or failing to resolve a runtime dependency needed by QtKeychain/KWallet/libsecret/D-Bus.

    • Possible areas to check:

      • bundled libqt6keychain
      • Qt DBus availability inside the AppImage
      • KWallet backend plugin/runtime linkage
      • libsecret backend linkage
      • D-Bus session bus access from the AppImage
    • If this is the case, QKeychain::WritePasswordJob should ideally emit a logged failure under aether.smartlink.

  3. The AppImage bundles libraries that interfere with host desktop integration

    • The captured stderr shows an AppImage library mismatch involving bundled libsystemd.so.0:

      /tmp/.mount_Aether.../usr/bin/../lib/libsystemd.so.0: version `LIBSYSTEMD_251' not found (required by /usr/lib/libmount.so.1)
      
    • This appears in ALSA plugin loading, so it may be unrelated.

    • However, because KWallet/libsecret/D-Bus integration may also touch system libraries, it may be worth checking whether the AppImage’s bundled libraries interfere with host D-Bus / KWallet / libsecret integration on Manjaro.

  4. Credential persistence failure is silent when compiled out

    • Even if the AppImage intentionally lacks QtKeychain, the current user-visible behavior is confusing because the UI appears to support remembering SmartLink login, but the password/refresh token is never stored.
    • A runtime log line or disabled/annotated “remember login” UI state would make this easier to diagnose.

Related existing work / possible overlap:

  • There is an existing SmartLink credential persistence issue/PR for Windows packaging where the application code was already implemented behind HAVE_KEYCHAIN, but packaged builds did not include/build QtKeychain, causing credential persistence to become a silent no-op in release artifacts.
  • That PR notes that Linux AppImage is a separate gap.
  • This report appears to be the Linux AppImage version of the same packaging class of problem.

Suggested checks for maintainers:

  1. Inspect the Linux AppImage CI/build log for v26.6.3 and confirm whether it printed:

    Qt6Keychain found — SmartLink credential persistence enabled
    

    or:

    Qt6Keychain not found — SmartLink credential persistence disabled
    
  2. Confirm whether the AppImage binary was compiled with HAVE_KEYCHAIN defined.

  3. Confirm whether the AppImage contains the required QtKeychain library and runtime dependencies, for example:

    ./AetherSDR-v26.6.3-x86_64.AppImage --appimage-extract
    find squashfs-root -iname '*keychain*' -o -iname '*kwallet*' -o -iname '*secret*'
  4. Compare the locally built binary and AppImage with:

    ldd ./build/AetherSDR | grep -iE 'keychain|secret|kwallet|dbus'
    ldd squashfs-root/usr/bin/AetherSDR | grep -iE 'keychain|secret|kwallet|dbus'
  5. Consider adding an unconditional startup/support-log line that reports whether SmartLink credential persistence is compiled in, for example:

    SmartLink credential persistence: enabled via QtKeychain
    

    or:

    SmartLink credential persistence: disabled; Qt6Keychain not available at build time
    
  6. Consider adding an AppImage packaging test that fails release builds if SmartLink credential persistence is expected but Qt6Keychain is not found.

Expected fix direction:

  • Ensure the Linux AppImage build installs/builds Qt6Keychain before CMake configure so find_package(Qt6Keychain QUIET) succeeds.
  • Ensure the AppImage bundles or correctly uses the necessary QtKeychain runtime components for KDE Wallet/libsecret on Linux.
  • Ensure SmartLink keychain failures are visible in the support log, especially when credential persistence is compiled out or unavailable at runtime.

support-bundle-20260617-162758.zip

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions