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.
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
KeepassXC replied on that thread that it wasn't just the privacy problematic networking that was removed:
that bug report is bunk. He removed ALL features, not just networking. That includes yubikey support, auto-type and browser integration.
I expect the KeepassXC people are mostly bothered by the naming of the package because the version called "keepassxc" is now the basic one. Anyway, the maintainer has offered to call them -minimal
and -full
and to make "keepassxc" a metapackage that pops up a debconf dialog telling users that install it to choose one. There is precedent with other complex packages that are split into basic and full. This should solve things nicely for everyone.
That sounds reasonable. I use the package on LMDE6, the one currently in stable though. Having a minimal keepassxc and a full one makes sense to me.
Afaiu it, he added a second package with (quote) "all the crap" later, after the storm.
And no, it wasn't just the favicons feature that was removed (which like ... is that really such a big privacy issue that you need to remove it from the binary?). Support for Yubikey was removed as well — which is not a privacy issue. The reasoning mentioned by the Debian maintainer is that all of these features might turn out to be security issues in the long run. Thus, in his view, a password manager application must do nothing but provide access to the database within the app.
I find it an interesting example of diverging upstream, maintainer, and user interests in any case.
I find it a lot of unnecessary fuss over unstable. Sid is supposed to make breaking changes, you offer feedback and you follow it through politely. The next Debian stable is one year away, this is not an urgent matter
There are so many people who think sid is a distro when really, as far as the Debian project is concerned, it is a staging ground.
Its also in testing.
And no, it wasn’t just the favicons feature that was removed (which like … is that really such a big privacy issue that you need to remove it from the binary?)
Fetching a favicon means raising a network connection with a predictable endpoint. That's already three concerns (four on the modern internet) to handle security-wise, and it's absolutely an unneeded feature. Favicons could just be shipped on something like keepassxc-data
or keepassxc-contrib
to handle locally, no need to raise a network call.
I highly recommend reading the Github thread as this is not at all an accurate representation. These features you're talking about are off by default. Removing them from the existing package is just breaking existing users. There's already a report from a user who can't access their passwords because yubikey support was suddenly removed. You don't do that to users just because you suddenly develop an opinion as a package maintainer that you feel is important. There was no dialogue, no consideration and a very rude, dismissive attitude of Julian.
There's already a report from a user who can't access their passwords because yubikey support was suddenly removed.
Yeah, well, this is Sid. It's called unstable for a reason. You have to read the changelogs or bad things will happen.
By the time it lands in stable it will most likely have a debconf dialog warning users and letting them transition smoothly to the version they want.
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 namekeepassxc
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
Exactly. And if you want those features, you install the full version. Packages can break in sid, that is the whole point of it.
I am also running sid and keepassxc and I see no problem with this change. In fact it seems like a very sane thing to do, and something I wished more packages did.
Sane move by maintainer, but he should not go around calling other people's code crap unless there is proof that the code was actually crap with gaping security hole
He could have handled it better. But he didn't call the code crap directly, just the bundle of everything.
Having a meta package and let users choose seems like the best way. But this is a Debian issue, and not a keepassxc issue. It is up to Debian to package it anyway they want.
If you look deeper at the recorded PR commit, comments, and package description it's clearly straight up mean-spirited.
The Debian maintainer is probably a volunteer. Can we not troll people who make Debian and Foss possible?
The KeePassXC people are also volunteers and dealing with the fallout of this decision.
True, but let them settle it without turning a few thousand people against one person.
well it is that one person causing issues
If by issues you mean looking out for people's privacy sure, someone has to.
To be fair, it looks like the debian maintainer started the unfriendly discourse by calling the work of other FOSS devs "crap"
Everyone needs to chill out, otherwise we have another potential XZ social engineering attack
It would be catastrophic for something like keepass to have a malicious maintainer take over
You have a point to some degree, yet I still think it is defensible to make this post. He majorly altered software
- downstream
- against user expectations
- for somewhat spurious reasons
- seemingly quite ad-hoc
He then went on to defend that decision in a less-than-graceful way before announcing there will be a second, new package.
But, to make it clear: I certainly don't approve of hate directed toward him and I don't have a personal issue with him.
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.
He's not wrong but he sounds like a jackass. A minimal version sounds better than removing features that are present and used by people.
At first i thought some reasons sounded reasonable too, but after reading the github issue i changed my mind. See my edit for reasons.
If I were maintaining a package and got a "request" worded like that I would tell the person to go fuck themselves. It's extremely rude to order people around like that.
Of anything the maintainer was extremely courteous. I will be extremely wary of KeepassXC in the future given that its developers behave like this. As far as I'm concerned this is a clear cut case of maintainer bullying and I hope Debian sends a signal by kicking their -full package out completely.
There's this assumption that these features in some way create some exploitable security issue.
I get the theory behind it: more code and more interoperability and more features &etc. generally leads to more bugs than the alternative, sure.
But there's also a line beyond which that principle stops making sense from a practical standpoint. Like, I could put my laptop into a furnace and melt it into slag. Now it will have no features, and that will make it very secure!
Lmao
Aren't the networking features just toggles in the settings already? I remember seeing several of the mentioned features in there.
Yes, these are off-by-default features.
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.
Ι 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.
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.
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.
I guess someone is super happy they saved a few hundreds kilobytes of disk space though.
Yes. All the people basing docker images off if debian, and trying to get them as small as possible. The splitting up of packages, allows people to only pull in what they need.
Sorry I was way off in my assumption that the venv package is a few hundreds kilobytes. apt is reporting 6144 bytes. 6 kilobytes. Installing python on the base bookworm image is 38.3MB. If you’re already installing python, it’s a rounding error. Also they have a separate python3-minimal package (which saves a laughable 200kb), why are they de-featuring the regular python version when they also have a separate minimal version? It makes zero sense. The python3 package should contain the entire python standard library. If it were supposed to be an addon, it wouldn’t be part of the standard library.
The python3 package should contain the entire python standard library
You are free to use a distro which does not split packages, favorite distro, Arch Linux (btw).
Or, you can install the recommended dependencies of python3. Testing in a container, the python3
package pulls:
root@a72bd55a3c1a:/# apt install python3
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
ca-certificates krb5-locales libexpat1 libgpm2 libgssapi-krb5-2 libk5crypto3
libkeyutils1 libkrb5-3 libkrb5support0 libncursesw6 libnsl2
libpython3-stdlib libpython3.11-minimal libpython3.11-stdlib libreadline8
libsqlite3-0 libssl3 libtirpc-common libtirpc3 media-types openssl
python3-minimal python3.11 python3.11-minimal readline-common
Suggested packages:
gpm krb5-doc krb5-user python3-doc python3-tk python3-venv python3.11-venv
python3.11-doc binutils binfmt-support readline-doc
The following NEW packages will be installed:
ca-certificates krb5-locales libexpat1 libgpm2 libgssapi-krb5-2 libk5crypto3
libkeyutils1 libkrb5-3 libkrb5support0 libncursesw6 libnsl2
libpython3-stdlib libpython3.11-minimal libpython3.11-stdlib libreadline8
libsqlite3-0 libssl3 libtirpc-common libtirpc3 media-types openssl python3
python3-minimal python3.11 python3.11-minimal readline-common
0 upgraded, 26 newly installed, 0 to remove and 18 not upgraded.
python3-venv python3.11-venv
I find it odd, because debian does this by default, actually. They account for usecases like yours, and instead you have to edit a config file or use a command line flag to get it to not install recommended dependencies.
I find it odd, because venv is a "Suggested package", actually. It isn't in the list of new packages that will be installed with python3 by default.
I think the next major release of apt is supposed to be easier to read. Unless Debian neuter it.
I do this stuff for work, unfortunately I don’t have the flexibility to choose here.
I don't think many docker images out there will have keepassxc installed though.
If you base your Docker images on a full distribution then that is entirely your fault. People usually use specialized distributions for that.
You could even bootstrap your needed tooling from Busybox.
Debian or Ubuntu are usually the best choice if you depend on glibc. Alpine is definitely more compact but musl isn’t always an option.
Specialized distributions like minideb still use the Debian packages, they just use fewer by default.
This is the kind of crap that makes me …
… not use Debian.
It’s work, I don’t get much of a choice here. I do get paid for the hassle though.
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
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 ?
There's a keepassxc-full package that comes with all the functionality. Anyhow, Debian does not have the concept of USE flags, these don't make sense in a binary-based distribution.
well that's annoying, thanks for letting me know, will make sure my flow is adjusted