Debian Users - Be aware the maintainer of the KeePassXC package for Debian has unilaterally decided to remove ALL features from it. You will need to switch to keepassxc-full to maintain capabilities once this lands outside of testing/sid.
@keepassxc Though I appreciate having a minimal package, I think naming the packages the other way round would be less confusing to existing users - keepassxc-minimal and keepassxc.
@keepassxc
This is exactly why I stopped using KeePass. How many forks have we had now? A password repository needs to be secure and reliable. If you can’t trust the developers it isn’t reliable.
Unilaterally here appears to actually mean: After notice and discussion, the core app requires attack surface reduction spurred by threat model change. Feature add version available for those with needs/tolerances for riskier surfaces.
That keepassxc devs themselves don't agree, and think conveniences are more important than security in a password manager makes me question the wisdom of using keepassxc as ones keepass client.
All the users I can forgive (well, not them either but it's at least expected if still not excusable) but the actual devs of a password manager?
@tuxwise I took my time to reach the decision it went back and forth for a year, and the xz-utils thing eventually tilted things in favour of shipping as little code builtin as possible by default.
I do not believe however that there is a significant overlap between people who use Debian, keepaasxc, and people looking for a featureful password manager.
It just makes no sense to go with a local only password manager and then put gaping holes in it. @keepassxc
@juliank@tuxwise@keepassxc I fall into this category, though I would obviously like to think I'm unique. Either way, you mentioned taking the time to make a desicion, and yet the upstream devs seemed to have been caught completely by surprise. That really shouldn't happen for what I hope are obvious reasons. What went wrong here? Did they just ignore all your communications and deliberations about this decision?
@mvgorcum It's a question for the Debian project I polled other Debian developers on IRC. We already knew upstream's position on this.
Could I have communicated it to them? Sure. Did they abandon IRC years ago? Yes. Well there's some weird Heisenbridge thing but it's WEIRD and nobody has talked to me for years. 🤷♂️
I barely have the energy to package new versions, seeking out and engaging with upstream on these grounds on downstream decisions is a tad much.
@juliank@mvgorcum@tuxwise we have multiple, MULTIPLE, means to get in touch with us. We moved to matrix years ago, but still bridge to IRC. Easily found through our Readme. Sorry this went down this way but it does end up having a huge negative impact on us when downstream shit breaks unexpectedly.
@juliank@tuxwise@keepassxc
This was my first thought when reading the headline.
I get that some people would prefer to have all the features by default, but given the nature of the package, I totally understand and agree that we should lean on the safe side by default.
“Stable release users should read the release notes.”
No they shouldn't. That's exactly why they use stable: so things don't break unexpectedly and they can work on problems that they want/need to work on.
@juliank@stardust@tuxwise I disagree with this statement on a fundamental level. If you see Debian as an expert tool for a very specific expert target group, then fine, whatever. But Debian is the base for a general-purpose operating system for millions of users with no technical background or simply no nerve and time to deal with things like this. You cannot and should not expect these users to know about any obscure text files, let alone read and understand the tech babble that's in them.
@juliank@stardust@tuxwise I certainly don't fire up a text editor and check the NOTES files first before I run apt upgrade or click the "Install now" button on the update reminder popup and I am probably much more of an expert user. We can only implore you to revert your decision. Your concerns about supply chain attacks in particular are certainly not unfounded, but you cannot export the complexity of this decision to your users in a way they will not and cannot understand.
@keepassxc I think renaming the package to keepassxc-minimal will make it much clearer, and I'll try to do that and I hope it gets accepted.
I'm very torn on the upgrade path with a transitional keepassxc package, we can depend on keepassxc-minimal|keepassxc-full or the other way around.
Once we drop the transitional package is when things become nice: apt install keepassxc will tell you that there's a minimal and a full, and you can select it.
@juliank@stardust@tuxwise That would certainly be much appreciated. Keep in mind that "keepassxc" refers to the full package in all other Linux distros and it's how we ship it ourselves for all platforms (including the PPA).
You cannot and should not expect these users to know about any obscure text files, let alone read and understand the tech babble that's in them.
Debian NEWS files are nothing like full changelog. They only document major changes that happen when upgrading from a Debian stable release to the next one.
The users do not have to hunt for this information, the content of the NEWS files is shown automatically during the upgrade.
Since these are targeting end users, they usually do not include "tech babble".
The only alternative to NEWS files that I can think of would be to never change anything from one Debian stable release to the next. Of course if Debian were to do that they would quickly lose all relevance as an operating system.
@tuxwise@juliank@keepassxc I don't think so, and many users in the discussion agree. If most users use only a small subset of the functionnality, then the smart secure move is to provide it and make it the default. Now it would be better if Keepassxc showed a message saying that that version is the minimal one, and that a full one is available, but that's not in the hands of the debian maintainer.
I was not referring to providing a minimal and a full version, to which the original developer agreed to as well.
As you can easily see from actually reading what I wrote, I criticized the rude tone, and the wrecking of the implied contract with those who have installed the existing package. And I stand by that.
@tuxwise@RLetot@keepassxc I was just being courteous, signing in on my phone and giving a short reply while travelling.
The concern is that somebody leaves or somebody new comes and picks up a subsystem and eventually maintains it on their own because the others don't actually use it and then believe the subsystem expert. That's somewhat normal.
This opens the doors for malicious actors to appear and compromise less popular subsystems.
@tuxwise@RLetot@keepassxc Hence I did not want to expose new users to optional subsystem code by default. This seems a reasonable stance. It is what Debian users generally expect.
Sadly I could not do that without breaking some users existing functionality. I can add a debconf dialog on upgrades to tell you more explicitly.
I will have to think about how we can solve this better in the future for similar situations (upgraded get X, new gets Y), but this requires new apt features.
@RL_Dane@Ray_Of_Sunlight@keepassxc looks to be security related when reading https://packages.debian.org/sid/keepassxc: This package includes only the bare minimal functionality, and no security complications like networking, SSH agent, browser plugin, fdo secret storage. See keepassxc-full if you absolutely need those.
Add comment