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
-
On Manjaro Linux with KDE, install/enable the normal wallet/keychain components:
qt6-keychain
kwalletmanager
libsecret
- default
kdewallet enabled and open
-
Download/run the official Linux AppImage:
./AetherSDR-v26.6.3-x86_64.AppImage
-
Open SmartLink / Remote login.
-
Enter SmartLink email and password.
-
Complete login successfully.
-
Quit AetherSDR.
-
Re-launch the same AppImage.
-
Open SmartLink / Remote login again.
-
Observe that the email address is remembered, but the password / saved login state is not restored.
-
Check KDE Wallet Manager.
-
Observe that there is no visible AetherSDR credential or wallet application connection.
-
Build AetherSDR v26.6.3 from source on the same machine.
-
Run the locally built binary.
-
Repeat SmartLink login.
-
Observe that the source-built binary successfully stores and retrieves the SmartLink credential through KDE Wallet.
-
Re-run the AppImage.
-
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
-
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:
-
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
-
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.
-
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.
-
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:
-
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
-
Confirm whether the AppImage binary was compiled with HAVE_KEYCHAIN defined.
-
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*'
-
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'
-
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
-
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
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-keychainis installedkwalletmanageris installedlibsecretis installedkdewalletis enabled and openHowever, 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:
The only output was unrelated ALSA / AppImage runtime noise:
I also checked the user journal:
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: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:
Steps to reproduce
On Manjaro Linux with KDE, install/enable the normal wallet/keychain components:
qt6-keychainkwalletmanagerlibsecretkdewalletenabled and openDownload/run the official Linux AppImage:
Open SmartLink / Remote login.
Enter SmartLink email and password.
Complete login successfully.
Quit AetherSDR.
Re-launch the same AppImage.
Open SmartLink / Remote login again.
Observe that the email address is remembered, but the password / saved login state is not restored.
Check KDE Wallet Manager.
Observe that there is no visible AetherSDR credential or wallet application connection.
Build AetherSDR v26.6.3 from source on the same machine.
Run the locally built binary.
Repeat SmartLink login.
Observe that the source-built binary successfully stores and retrieves the SmartLink credential through KDE Wallet.
Re-run the AppImage.
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.3Package: official
AetherSDR-v26.6.3-x86_64.AppImageQt version:
6.8.3Wallet/keychain packages installed:
qt6-keychainkwalletmanagerlibsecretKDE Wallet:
kdewalletenabledDeveloper 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.mdpoints toAGENTS.mdas the canonical project guide.AGENTS.mdsays AetherSDR is a Qt6/C++20 SmartSDR client, usesAppSettingsfor client settings, and exposes runtime diagnostic categories through Help → Support.AGENTS.mdalso 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.cppSmartLinkClient::login(...)AppSettingsasSmartLinkEmail.refresh_token.saveCredentials()after successful login.SmartLinkClient::saveCredentials()Uses
QKeychain::WritePasswordJob("AetherSDR").Uses key
smartlink_refresh_token.Calls
job->setTextData(m_refreshToken).Logs either:
SmartLinkClient: keychain save failed: ...SmartLinkClient: refresh token saved to keychainThe 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 credentialsSmartLinkClient: found stored refresh token, attempting auto-loginThis is also guarded by
#ifdef HAVE_KEYCHAIN.SmartLinkClient::clearCredentials()QKeychain::DeletePasswordJob("AetherSDR").SmartLinkEmailfromAppSettings.#ifdef HAVE_KEYCHAIN.src/core/SmartLinkClient.hDeclares:
tryAutoLogin()saveCredentials()clearCredentials()loginWithRefreshToken(...)CMakeLists.txtAround the Qt dependency discovery section, AetherSDR does:
If
Qt6Keychainis not found at AppImage build time,HAVE_KEYCHAINappears 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.cppDefines the relevant logging category:
aether.smartlinkSmartLinkAuth0 login, TLS tunnel, WAN streamingIt also defines diagnostic logging categories visible in Help → Support.
src/gui/SupportDialog.cppLogManager::categories().Recommended logging categories to enable in Help → Support before reproducing:
SmartLink
HAVE_KEYCHAINis enabled.GUI
Connection / Commands
Protocol / Status
Potential root causes:
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_KEYCHAINwould be undefined andsaveCredentials()/tryAutoLogin()would compile to no-ops.That would exactly match the observed behavior:
AppSettingsQtKeychain 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:
libqt6keychainIf this is the case,
QKeychain::WritePasswordJobshould ideally emit a logged failure underaether.smartlink.The AppImage bundles libraries that interfere with host desktop integration
The captured stderr shows an AppImage library mismatch involving bundled
libsystemd.so.0: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.
Credential persistence failure is silent when compiled out
Related existing work / possible overlap:
HAVE_KEYCHAIN, but packaged builds did not include/build QtKeychain, causing credential persistence to become a silent no-op in release artifacts.Suggested checks for maintainers:
Inspect the Linux AppImage CI/build log for v26.6.3 and confirm whether it printed:
or:
Confirm whether the AppImage binary was compiled with
HAVE_KEYCHAINdefined.Confirm whether the AppImage contains the required QtKeychain library and runtime dependencies, for example:
Compare the locally built binary and AppImage with:
Consider adding an unconditional startup/support-log line that reports whether SmartLink credential persistence is compiled in, for example:
or:
Consider adding an AppImage packaging test that fails release builds if SmartLink credential persistence is expected but
Qt6Keychainis not found.Expected fix direction:
find_package(Qt6Keychain QUIET)succeeds.support-bundle-20260617-162758.zip