Connecting the internet and a password database together is one of those fundamentally bad ideas. This might well be an excellent technical decision. Although I agree with the thread root that this is a level of intervention that might justify some rebranding.
> Package maintainers aren't self-sacrificial saints or all that unique as volunteers go.
If you want keepassx, you can go install it. If you want the Debian archive's version, install that. All the options are open to critique, but the average Debian maintainer is doing so much more good than the occasional bad decision that they get a lot of benefit-of-doubt on this sort of choice. And some reasonable expectations of respect.
Is it a _fundamentally_ bad idea? The connected syncing feature of Bitwarden is one of my favorite things. I can save a password on one device, and its automagically available on others all while staying encrypted (and audited).
Agreed but it is worth keeping in mind that Bitwarden's implementation of sync is probably a lot more sophisticated than KeepassXC; and is probably the main reason why one would use Bitwarden. I am a former user of Keepass and I never knew it had network functionality so I think it makes sense to provide two packages -- one containing the main keepass functions which which 99% of users will use and the othrer for the 1% using the exotic functions. This is in line with how Debian handles many other packages such as vim, exim, etc so it is not at all surprising for the typical Debian user.
- getting the favicon for a specific entry (needs to be ran manually with an option to download via a DuckDuckGo proxy)
- checking entries against HIBP (needs to be done manually in a submenu with a giant notice)
Also this is about KeePassXC not KeePass which is a completely different project.
There is also KeePassX, KeePassDX, KeeWeb, KeePass-electron and so on and so forth.
> Connecting the internet and a password database together is one of those fundamentally bad ideas.
Disagree. I use KeePassXC because I would prefer to have my passwords on my computer, instead of somebody else's computer (and I am willing to accept responsibility for managing my own password file).
That is a delineation that is parallel to, but not the same as, "don't connect to the internet". Browser integration is a required feature for a modern password manager; without it, you don't have a password manager, you have an encrypted notepad. HIBP integration is, likewise, net-good for users.
Also, as the KeePassXC devs have repeatedly pointed out in multiple places, these features are compiled in, but not enabled by default. Users who do not wish to use them can simply ignore them. Julian's argument at best seems to be some kind of concern about software supply chain; he is compiling the package without these features so that they are no longer available to the users who do want them.
The people making the arguments in favor of this change "for security reasons" aren't even making strong arguments for it.
> If you want keepassx, you can go install it...
Okay. And if you want a super-paranoid version of KeePassXC without these features compiled in, you can... go compile it that way.
Like everyone else, I already have thousands of little time sinks to contend with simultaneous to other increasing pressures in life. I am investing some time now to try to prevent another bad decision from adding to those faffs.
> some reasonable expectations of respect.
First, from my reading here and on the Mastodon thread and on the GitHub thread, most people have expressed dissatisfaction with this decision without crossing the line into disrespect towards the maintainer. The KeePassXC devs have maybe gotten a little heated, but they deserve all the same allowances you'd give to a package maintainer. They are getting bug reports due to downstream's decision, which they strongly disagree with. That sucks. There is a little bit of the usual internet noise, but otherwise, this is about the best discourse that could be expected for something like this.
Second, Julian himself kinda invited a strong negative response when he replied early on with, "This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there's little that can be done about that. ... All of these features are superfluous and do not really belong in a local password database manager, these developments are all utterly misguided. Users who need this crap can install the crappy version..."
---
Getting back to some substantive discussion, it seems unlikely Julian is going to change his mind on this. This seems like a clear failure of package stewardship to me; KeePassXC's best move IMO is to set up their own repository and provide instructions for adding their repo and key to apt and then pin their keepassxc package. It's a bit of a nuisance for them, but probably less headache than ongoing bug reports and noise from the internet. There's already a lot of other software that gets installed this way, so I think it's fair to expect the average Debian user to be able to handle this process -- it's copy-and-pasting about four lines into your terminal. Then, Julian will no longer need to bear the burden of maintaining the package.
> Browser integration is a required feature for a modern password manager; without it, you don't have a password manager, you have an encrypted notepad.
Not really? I've been using KeePassXC without a browser extension for a while, probably not years but certainly many months. That doesn't make it any less of a password manager - it lets me generate random strings to use for each account, keeps them safe and encrypted, and also lets me enable TOTP for an unlimited number of accounts. That's pretty much a password manager to me (TOTP is extra but much appreciated).
It makes you vulnerable to phishing (or rather, it provides zero protection against phishing), which is one of the biggest threats to the average user by a wide margin.
It's absolutely reasonable to say "Browser integration is a required feature for a modern password manager".
Volunteers by definition do not (or at least should not) expect anything in return for their time. If you want respect as a so-called volunteer, you're not a volunteer.
I've seen both good and bad package maintainers, too.
> Volunteers by definition do not (or at least should not) expect anything in return for their time
That isn't really true. For starters, paid volunteers are actually a thing that happens from time to time. Secondly; there would be no volunteers if they didn't get something for their time. It is just generally that something isn't money. Volunteers aren't expected to be selfless.
If you’re getting paid you’re by definition not a volunteer. You may be getting some perks like volunteering at a convention giving you an entry pass for that convention, but as soon as you’re getting some other gains, be it monetary or not, you’re no longer a volunteer.
each year, my employer allows me to take a (paid) day off to do volunteering projects, e.g. going to soup kitchens. I get paid for that day regularly by my employer. The soup kitchen doesn't have to pay a dime.
> If you’re getting paid you’re by definition not a volunteer.
You are technically incorrect. The US army, for example, is manned more or less entirely with paid volunteers.
And while many volunteers may not get formal compensation, they have to expect to get something out of the experience. Otherwise they would not do it. The subset of volunteers who are in it purely for a biblically pure sense of charity is tiny. And there is no expectation that Debian developers are motivated by some cultish wish to do good for the sake of free software. They're allowed to be motivated by whatever motivates them to do good with free software. Even if it is money.
> Package maintainers aren't self-sacrificial saints or all that unique as volunteers go.
If you want keepassx, you can go install it. If you want the Debian archive's version, install that. All the options are open to critique, but the average Debian maintainer is doing so much more good than the occasional bad decision that they get a lot of benefit-of-doubt on this sort of choice. And some reasonable expectations of respect.