Why are you worried about the keychain on your OS losing passwords in the event of a hard disk failure?
I donât use my OS keychain to remember or manage passwords. Itâs there so that applications like the Nextcloud Desktop Client can log in automatically, so to speak, purely as a convenience feature. If my laptop dies or my SSD goes bad, I buy a new one, reinstall my OS, log back into my apps with the passwords that I have stored, in my case in Vaultwarden, and life goes on 
This thread is fascinating. Can you imagine if a Windows apologist came screaming âbut why canât it stay logged in when I disabled Windows Credential Manager?!, what if it broke and my cached credentials were lost so I had to log in again? The horror! 
"
The only one screaming here is you. I do not expect you to understand my arguments, but please think about them one more time â and maybe a third time â and a fourth timeâŠ
And please do so in silence. No screaming!
Well, under Linux there are certainly cases, where it may simply not be possible to use the OS keychain, for example, if it doesnât work with a particular login manager or a more minimalist desktop environment.
@weka But beyond that, I donât really see a good reason not to use it. If youâre running a fully fledged desktop environment like GNOME or KDE Plasma, the only reasons left are principled stubbornness or half-truths, similar to the arguments you hear from systemd opponents or from people who want to strip down their OS to âsaveâ a few hundred MB at best, or because they feel that fewer services equals better security. In practice, though, they may even end up making their systems less secure by assuming they know better than the developers. But hey, to each their own.
And again, the keychain doesnât need to be backed up unless itâs the only place you store your credentials. Sure, after a reinstall (e.g., following a hard drive crash) youâll need to log in to everything again, but thatâs all.
Arguments?
My response: if you deliberately disable or otherwise alter your configuration from a well-supported normal baseline (i.e. Has a standard secrets manager), expect things that rely or potentially rely on those disabled feature to be degraded or nonfunctional.
My response: likely as a result of using Qtâs support for keychain technologies, nobody. You can read a blame here if you want.
NextCloud is simply inheriting what was apparently a sane default.
Regardless, what use would this knowledge be? Planning on sending strongly-worded messages at them?
My response: false equivalency, and irrelevant besides. NextCloud needed a standardized method to cache sensitive data, and decided not to roll their own. End of.
My response: feel free to fork and implement the functionality. Surely PR requests will be considered.
My response: having done so, if you want it done right, upwards of 241 assuming presence of standard libraries and dependencies. Oh wait, NextCloud already did that and here is the complaintâŠ
If anything, a feature request to bubble a notification that the session token isnât confirmed saved in a keystore would be nice. That way we could we least let the user know theyâll be logged out as soon as the userâs session is closed (reboot, logoff, quit app, etc)
Edit: and now have done a small needful as the idea has merit.
I am not blaming anyone. I was simply asking who decided to rely on an external password manager, because bb77 told me to complain to the Linux developers, and especially to the KDE developers. But I am pretty sure it wasnât the KDE developersâ idea that Nextcloud should use kwallet. That idea must have come from Nextcloudâs side, and thatâs what I was trying to point out.
When I installed my first KDE desktop, kwallet was far, far from being reliable, and I am very pleased that it is still not mandatory for running a KDE desktop. Everyone who wants to use it, is free to do so.
But you are saying it yourself: there should be a notice to users, that NC client will need access to its password, either by retrieving it from a password manager or by entering it manually at each start. Such a note would make tons of discussion and help tickets unnecessary.
Thatâs not what I said. What I said was: âIf you have legitimate concerns that KWallet itself, or its implementation in KDE Plasma, is flawed,â then it would be better to report those flaws to the respective projects, rather than rejecting it, which, in my opinion, seems to be based purely on a gut feeling.
Anyway, I still donât see any compelling reason why using KWallet would actually be an issue, especially in your case, since youâre already using KDE Plasma. And you havenât really addressed or disproved any of my points about why I think itâs not an issue.
I mean⊠what does âwas far, far from being reliableâ even mean in this context? Unreliable with what, exactly? The Nextcloud client? In general? Is it still unreliable? If not, thatâs good, isnât it? And if it is, then please report any remaining issues.
And btw, you donât have to use it for anything else! 
If people sometimes could just let it go once theyâve received a solution to their issue, thereâd be no need to keep discussing it forever.
I mean I have my documents folder synced to a backup drive on Nextcloud lol. I also have any other folders I want backed up syncâs to it. I mean you can turn it on with the Linux client I would think. I use the windows client and it syncs everything to that drive. Then I have that drive backed up on my server with rclone.
Itâs not hard or time consuming to setup a backup and you already have Nextcloud, what are you waiting on to create a backup plan?
Where there is a will there is a way. A good backup plan runs without manual intervention.
I think you a missing the main point. Itâs up to your Linux distribution to update their package for the Linux client. They took Nextcloud as source and made their own package from it. Itâs broken at the distribution level, not the source. Hope that makes sense
You are basically saying, you want to blame Nextcloud for something your Linux distribution probably implemented badly which doesnât make much sense as others have pointed out
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.