They didn’t “strip” anything, they’ve split it into 2 variants, a package without networking features (-DWITH_XC_NETWORKING=OFF) and a package with them, because it’s considered a privacy issue to have your password manager phone home and fetch favicons and so on. The packages will be called keepassxc and keepassxc-full going forward.

Storm in a teacup, as tends to be the norm on the internet.

Not only this is nothing new and nothing unexpected to happen in Sid of all places, but it’s also something that helps bring keepassxc more in line with packaging guidelines on Debian. They already have lots of packages, both of the mutually-exclusive kind and of the complementary kind, with “foo-full”, “foo-minimal”, “foo-data” etc naming. p7zip and nginx of all things are quite interesting examples.

Plus, the author of the post sensationalizes the title to brigade the issue.

All that said:

• If the maintainer wishes to do this, “only” having two packages is a half-assed measure and that causes more issues in the long term. I’d expect three packages: keepassxc-minimal, keepassxc-full and the retained name keepassxc as a virtual package name.
• Furthermore, a direct upgrade path should go from (previous) keepassxc to (proposed) keepassxc-full.
• I don’t know enough of KeePassXC to know if something like keepassxc-data would be needed. Are there potential cases where one would want to switch between “-full” and “-minimal” or viceversa without the system seeing a software uninstallation in the meantime?
• The “crap” rationale is definitively something we all can do without, but given how people tend to brigade developers who try to do things, I can completely understand and support raising shields and looking defensive because some damage is already going to be done.
• Most responses are right in that the right place to discuss this is in the opened Debian bug report. The entire point is to see Debian (not KeepassXC) handle this before things get to Next Stable.

Debian sid user here, and long time keepassxc user

Debian maintainer didnt communicate this well, but i agree that i dont want my password manager having any access to networking or interacting with anything other than the clipboard.

I’m not a developer or a security expert. This is just my gut feeling talking

The Debian maintainer is probably a volunteer. Can we not troll people who make Debian and Foss possible?

The response by the debian maintainer responsible for this change to the keepassxc developer is an actual disgrace

Request to revert change:

@julian-klode this needs to be reverted asap. This is now our fourth bug report because of the decision to neuter the base KeePassXC package in Debian. Put the base package back where it was and create a keepassxc-minimal.

Response by debian maintainer:

julian-klode commented 9 hours ago: I’m afraid that’s not going to happen. It was a mistake to ship with all plugins built by default. 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. It is our responsibility to our users to provide them the most secure option possible as the default. 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 but obviously this increases the risk of drive-by contributor attacks.

The whole github issue is worth a read, as it actually explains the issue with the change.

Edit: as i gave the debian maintainers view visibility i wanted to give a quick summary of the keepassxc point of view as well:

• julian-klode specifically mentions attacks by contributors of keepassxc. If you don’t trust the developers, why would you trust the minimal package which is developed by the same people?

• If the Debian packagers have good reason to believe the keepassxc-full version presents a broader attack surface, then they ought to present what they’ve seen that makes them feel that way, not promote baseless innuendo.

• the features are disabled by default. If you do not opt in, the code never gets executed.

• the safest version of keepassxc is the one thats tested, meaning full featured

• removing all those features doesn’t make it more secure, it dumbs it down to an encrypted spreadsheet and makes it less secure. Users should be automatically notified when one of their accounts has been breached and their password for that account has been found floating in a db dump. Users should rely on their password manager to handle logins for them, so they’re less likely to get tricked into a phishing page.

• if you disagree with features in someones app you fork it. You do not change it and distribute it under the same name. A -minimal version would have been ok

• Debians own policy is to communicate with upstream beforehand before introducing changes. This was not the case, nor was there a chance to collaborate on an effective solution for both parties.

• Debian could have chosen to give users an informed choice between -full and -minimal. Instead they broke existing users installs.

• People saying it was released in Debian sid, which is meant for changes. It is also meant for Feedback, which julian-klode refuses to listen to.

deleted by creator

This is the kind of crap that makes me glad flatpak and such exist. I don’t want a maintainer making arbitrary decisions like this, it adds unpredictability and platform inconsistency.

A similar issue I face is that on Debian the python stdlib well… isn’t all standard. In particular they split off the venv package, and it’s an extra step that adds unnecessary complication. No other Linux distros or other OS do this, it’s so frustrating. I guess someone is super happy they saved a few hundreds kilobytes of disk space though.

Ι don’t agree with what they did. They removed browser integration, not just the “favicon” thing. If this was a problem for normal users, well, normal users would just use Firefox’s built-in password manager, not keepassxc. That change made the app useless to me, and going forward it will be a headache for NEW users who won’t know of the -full package. It was a bad decision.

Aren’t the networking features just toggles in the settings already? I remember seeing several of the mentioned features in there.

Ah, I was wondering why I couldn’t get it to detect my yubikey. I saw keepassxc-full in the repo but that also didn’t seem to work. I’ll have to revisit it.

remove ALL features from it

A password manager which only manages passwords? Scandal!

I’m sorry for the dev who obviously isn’t happy with this decision, but it feels a bit blown out of proportion IMO

debian/rules:

dh_auto_configure --  -DWITH_TESTS=$(WITH_TESTS) \
	                      -DWITH_GUI_TESTS=$(WITH_TESTS) \
	                      -DWITH_XC_UPDATECHECK=OFF \
	                      -DWITH_XC_ALL=OFF

CMakeLists.txt:

set(WITH_XC_ALL OFF CACHE BOOL "Build in all available plugins")

option(WITH_XC_AUTOTYPE "Include Auto-Type." ON)
option(WITH_XC_NETWORKING "Include networking code (e.g. for downloading website icons)." OFF)
option(WITH_XC_BROWSER "Include browser integration with keepassxc-browser." OFF)
option(WITH_XC_BROWSER_PASSKEYS "Passkeys support for browser integration." OFF)
option(WITH_XC_YUBIKEY "Include YubiKey support." OFF)
option(WITH_XC_SSHAGENT "Include SSH agent support." OFF)
option(WITH_XC_KEESHARE "Sharing integration with KeeShare" OFF)
option(WITH_XC_UPDATECHECK "Include automatic update checks; disable for controlled distributions" ON)
if(UNIX AND NOT APPLE)
    option(WITH_XC_FDOSECRETS "Implement freedesktop.org Secret Storage Spec server side API." OFF)
endif()
option(WITH_XC_DOCS "Enable building of documentation" ON)

set(WITH_XC_X11 ON CACHE BOOL "Enable building with X11 deps")

# stuff inbetween cut out

if(WITH_XC_ALL)
    # Enable all options (except update check and docs)
    set(WITH_XC_AUTOTYPE ON)
    set(WITH_XC_NETWORKING ON)
    set(WITH_XC_BROWSER ON)
    set(WITH_XC_BROWSER_PASSKEYS ON)
    set(WITH_XC_YUBIKEY ON)
    set(WITH_XC_SSHAGENT ON)
    set(WITH_XC_KEESHARE ON)
    if(UNIX AND NOT APPLE)
        set(WITH_XC_FDOSECRETS ON)
    endif()
endif()

I’m no CMake expert, but it looks like to me, from the first line of the above snippet, that the default in the upstream build script is WITH_XC_ALL=OFF.

Rip keep ass xc emacs style defaults.

Keepassxc systemd integration when?

Don’t debian packages have use flags like gentoo does ? Surely it’s not hard to compile the binary with every possible combination of build flag in 2024 ?

well that’s annoying, thanks for letting me know, will make sure my flow is adjusted