The KeePassXC kerfuffle
KeePassXC is an open-source (GPLv3), cross-platform password manager with local-only data storage. The project comes with a number of build options that can be used to toggle optional features, such as browser integration and password database sharing. However, controversy ensued when Debian Developer Julian Klode decided to make use of these compile flags to disable these features to improve security in the keepassxc package uploaded to Debian unstable for the upcoming Debian 13 ("Trixie") release.
One of the selling points of KeePassXC, in the age of everything-as-a-service, is that it stores user passwords and secrets locally. It does have a few network features, such as downloading site favicons to display next to passwords for web services and for checking passwords against the "have I been pwned?" service. It also has interprocess communication (IPC) functionality to talk to browsers like Firefox, Chrome, and others that have KeePassXC browser extensions. The project provides build flags to turn these additional features off, if desired.
The idea of turning off optional features in KeePassXC's Debian package is not new, and Klode has gotten requests to do so as far back as 2020, though they had gone unanswered until now. A Debian user filed a bug report against KeePassXC in March 2020, asking for the program to be compiled without some of its optional features. Andreas Kloeckner disagreed, saying that he finds the features useful, and suggested creating a second package if users wanted a keepassxc package without those features. Another user, Tony Mancill, chimed in a year later saying he supported disabling networking. And then the bug sat for almost three years until April 2024, when the bug was closed after Klode uploaded the package with networking and IPC functionality turned off, along with a new keepassxc-full package with the original functionality. This meant that the new package no longer supported any features, like browser integration or password sharing, that depended on networking or communicating with processes like Firefox or USB input from hardware tokens.
XZ-inspired
Why did Klode decide to take action on this bug several years after the fact? In an email response to questions, Klode wrote that the XZ backdoor spurred on the change. It made him "more concerned about building optional code into the default package". He suggested that optional features were more likely to contain vulnerabilities than the core application, because those features may only be reviewed by a single maintainer. It is easier, he said, for vulnerabilities to creep in if features have fewer reviewers.
The minimal build, he said, was well-aligned with what typical Debian users would want. Debian is well-known for stripping out features to improve security and privacy, and these users had chosen a password manager that stores its data locally "because they don't trust sharing their files with other users". Klode said that he did not think there would be much overlap between "these paranoid users" and users who wanted network access and to allow other applications to interact with the password database. "Certainly I've only ever used the clipboard for it and none of these features."
Users hit snags
Klode may not use the disabled features, but others do. Michael Musenbrock filed
a bug report against the new package almost immediately after it was
uploaded to Debian unstable, and reported that
he was unable to open his password database without hardware-key
support. He endorsed the idea of splitting the package up so the default
package would be a "real network-less password
manager
", but suggested restoring the hardware-key
functionality.
On May 6, Hernán Cabañas commented
on the same bug report, after he had asked
the upstream about missing browser-integration functionality. Jonathan White, a member of the KeePassXC project team, said
that removing the functionality was a terrible decision, and
recommended complaining to Debian. "They should have made a keepassxc-min instead.
"
On May 10, Cedric Schmeits opened an issue
on the KeePassXC GitHub repository, complaining that browser integration had stopped working
with KeePassXC version 2.7.7, and most of the application's options
had disappeared from its settings. White tagged
Klode and said that the change "needs to be reverted asap
". He
later edited the comment to add that Schmeits's bug report was the
fourth that the project had received about the package change, and
demanded: "Put the base package back where it was and create a
keepassxc-minimal.
"
Klode replied
that was not going to happen. It was a mistake to ship with these
plugins enabled, and "our responsibility to our users to provide
them with the most secure option possible as the default
". He
acknowledged that it would be painful for a while, "as users annoyingly
do not read the NEWS files they should be reading
", and went on to
say that the disabled features didn't belong in a local password
manager anyway. But, if users needed them, they could "install the
crappy version but obviously this increases the risk of drive-by
contributor attacks
". To that, White responded:
"Good luck to you. Really bad decision. We will be sure to let
everyone know.
" That day, the KeePassXC project posted a notice on
Fosstodon that Debian users should "be aware
" that
"the maintainer of the KeePassXC package for Debian has
unilaterally decided to remove ALL features from it
". This
escalated things quickly, as the Fosstodon post made the front page of
Lobste.rs
and Hacker
News.
White made it clear that the intention was to put Klode's feet to the virtual fire:
Would have been nice to have [a discussion] about a month ago when this was unilaterally put into action. Alas, here we are. So yah flaming arrows will absolutely be thrown because there was no chance at proper discourse. This thread should be a lesson to downstream folks who think they know what's "best" for the user.
That seems to have succeeded in directing angry users at Klode. In
his email to LWN, he acknowledged that some of his wording
was unfortunate, but said that he was in a hurry and wanted to provide
a response before traveling. The hasty reply ended up sparking a
disproportionate backlash: "I don't think it's healthy for people being subjected to a hate mob
on multiple channels for several days like this.
"
Klode's comments did more to inflame upstream (and a number of users and onlookers) than inform, and they responded in kind. That is unfortunate: objectively speaking, a legitimate case can be made for adhering to the upstream's default configuration, or for the packager to exercise their best judgment in the configuration that is best suited to the distribution's users. Neither is correct, neither is wrong, it's a matter of perspective and opinion.
For example, former KeePassXC team member Davide Silvetti, initially agreed with the decision to offer a package with additional options turned off as the default. He said that the option to compile without plugins was added in 2016 to reduce the attack surface and potential vulnerabilities. He suggested that the project add a message in place of the usual browser integration feature tab that that suggests the user install the "full" version if they want that capability.
That did not appeal to Janek Bevendorff, a current member of the
project team. "If anything, we will reduce the number of such
compile-time flags in the future, so these things cannot be disabled
anymore.
" The safest version of the program, he said, "is not
the one with all flags disabled, but the one which is tested best by
us and by the majority of our users
".
Silvetti disagreed and asserted that disabling compile-time flags
for additional features "actually removes code and reduce[s] attack
surface
", making the final version more secure. He also noted that
package maintainers for the Linux distributions "(contrary to KeePassXC maintainers) have actual
telemetry data and crash
reports affecting the end users
". That said, he then wrote
that it would be better to continue with the keepassxc
package with all features enabled, and offer the minimal version as
keepassxc-minimal.
Much ado about...
For all the turmoil over the change, the only users who are actually at risk of a surprise change to the keepassxc package are those running testing or unstable releases. In response to a question about whether it is really reasonable to expect that users read NEWS files, Klode wrote that users of Debian unstable or testing are not average Linux users, but "people who have chosen to test the next Debian release in a rolling development state". Those users should have apt-listchanges installed "which will print these critical news items before the upgrades are installed".
The actual impact will be negligible for users of stable versions of Debian, Ubuntu, and other Debian-derived distributions. Klode said that when Debian Trixie is released, upgrades and new installs of the keepassxc package will receive a transitional package that prompts them to decide between "full" and "minimal" packages. Klode says that this will allow users upgrading from bookworm to preserve their current setup. Future releases will have a "virtual" keepassxc package that, again, requires the user to explicitly select one or the other.
Even if one takes the position that Klode is completely wrong in his rationale for and handling of this change, the real impact is minor. One of the things we should have learned from the XZ backdoor episode is that no one benefits from making participation in open-source development and distribution more unpleasant and stressful. Maintainers should be able to screw up in public without fear of an internet pile-on.
Posted May 22, 2024 16:46 UTC (Wed)
by epa (subscriber, #39769)
[Link] (28 responses)
Should Debian packages (and those in other distributions) follow a similar scheme? If a particular feature is dropped or the new version is for some other reason not a smooth replacement for the old, its package should increment a kind of major version number associated with the package (not the version of the software itself) and so upgrade tools can prompt the user that this is a backwards-incompatible change and to read the NEWS file or whatever.
I'm more familiar with RPM, and there you have a release number. So if upstream foo version 1.2.3 were packaged, it would be foo-1.2.3-1.rpm for the first packaging, and then a repackaging of the same release with different options might be foo-1.2.3-2.rpm. That final -1 or -2 can itself be a multipart identifier (that's used for important packages like glibc).
Posted May 22, 2024 16:57 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (22 responses)
Posted May 22, 2024 17:21 UTC (Wed)
by jzb (editor, #7867)
[Link]
"If the user has to parse semantic version information at all, you have already failed." I'd add that users rarely engage with version numbers of packages anyway. When I do an update I'm not examining each package version number - the only times that I would are when I'm specifically interested in a security update or a version update to get a new feature, etc.
Posted May 23, 2024 5:27 UTC (Thu)
by epa (subscriber, #39769)
[Link] (20 responses)
Posted May 23, 2024 6:24 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (18 responses)
We're talking users here, not sysadmins. An admin can be expected to read the update notes and, say, replace exim4-core with exim4-heavy when they need an uncommon feature that's been chopped off the standard package.
However, this case is different. There's nothing uncommon in KeepassXC's browser integration. I'd use some other password manager if that didn't exist. Again: we're talking "normal" users here. Somebody who is security-hyper-conscious can be expected to manually replace keepassxc with keepassxc-minimal, along with all the other stuff that needs replacing or restricting for these use cases.
Posted May 30, 2024 13:05 UTC (Thu)
by mrugiero (guest, #153040)
[Link] (12 responses)
I get your point, but we're not talking about normal users here. We're talking users who are in the tiny subset that opted for the rolling release version of Debian (which means breakage is not just possible, it's what you should expect) and then the tinier subset that chooses an old school local password store over a service.
Posted May 30, 2024 14:28 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (11 responses)
If I want to upload something to Debian with a breaking change that I'm going to rework before unleashing it to the masses, I should upload to Experimental instead. Alternately I can add an RC bug (Release Critical) which would prevent the package to get get promoted to Testing, but that's sort of frowned upon because one can block transitions that way.
To be sure, Upstream isn't entirely blameless either. I don't know what the correct way to disable optional features people depend on might be in this context – but silently hiding them appears not to be The Way.
Posted May 30, 2024 14:59 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
No, today's users of Testing are tomorrow's users of Testing -- Once you explcitly opt in to using it, you remain on it. When a new stable release is cut, users of Testing don't automatically get switched over to it. [1]
As for assumptions, let me quote the Debian wiki ( https://wiki.debian.org/DebianTesting )
> How Debian Testing Works
Note the word "automatically". In other words, "Debian unstable as of about a week ago minus anything with release critical bugs" -- and in order for there to not be any "release critical bugs" someone has to first *report* said bug against the package while it's still in the Unstable repository.
Once again, this kerfuffle stems from users expecting something "stable" while explicitly opting in to something that, by its very definition (and name!), is not.
[1] Strictly speaking it depends on how they've opted into testing -- if they use the "next stable" name (eg "trixie") instead of "testing", they'll eventually land and stay on that stable release indefinitely, but if they opt into "testing" they will stay on testing. This is also documented on the wiki page mentioned above.
Posted May 30, 2024 15:22 UTC (Thu)
by rschroev (subscriber, #4164)
[Link] (1 responses)
> No, today's users of Testing are tomorrow's users of Testing
But todays packages in testing are tomorrow's packages in stable. That's the important thing here. Were it not for the users of testing raising the alarm today, the removal of functionality would have gone in tomorrow's stable. The problem here is not so much that users of testing were impacted, but mainly that all users would be impacted sooner or later if things would have gone the way the maintainer intended.
> Once you explcitly opt in to using it, you remain on it. When a new stable release is cut, users of Testing don't automatically get switched over to it.
It depends: if you select 'testing' in your sources list, than you will indeed stay on testing. But if you select 'trixie' (which is at the moment the same as 'testing'), you will be on stable when trixie becomes stable.
Posted May 30, 2024 15:38 UTC (Thu)
by pizza (subscriber, #46)
[Link]
No, they are tomorrow's packages in *stable+1*. Nothing ever flows from testing into stable (or oldstable).
(And to use your analogy, today's packages in unstable are the day after tomorrow's packages in stable+1 too..)
> That's the important thing here. Were it not for the users of testing raising the alarm today, the removal of functionality would have gone in tomorrow's stable. The problem here is not so much that users of testing were impacted, but mainly that all users would be impacted sooner or later if things would have gone the way the maintainer intended.
Well, yes -- but you're just restating how Debian's staged development process is intended to work, including the user feedback loop.
Again, this sort of situation is the *entire point* of debian-testing.
Posted May 31, 2024 3:31 UTC (Fri)
by mrugiero (guest, #153040)
[Link] (7 responses)
https://wiki.debian.org/DebianUnstable
This happened in unstable, didn't it? It is a rolling release where breakage is expected and packages from unstable DO NOT flow into (current) stable under any conditions. These changes only make it to the NEXT stable release, which you do a manual, major, opt-in upgrade, only if you wish to. If you are NOW on unstable, you expect breakage, end of story.
Also, my comment was not so much about the size of the group, but about the demographics. The people affected made two choices that made them very much not normal users. It's not your tech oblivious auntie that is using keepassxc on unstable. You didn't mistakenly bought a laptop with Debian unstable preinstalled and didn't know any better. You chose it. The one with the big "unstable" label in the name. You can't expect the stability guarantees the name itself says it won't deliver on and then complain because it didn't, that's unreasonable.
Re: users reporting to upstream: same misfeature. You use a distro, you should check what your distro did first. Specially if you go ahead and use unstable. The maintainers have a right to be annoyed. I sympathize specially with their work being called "crap" by the packager. But really, the ones that are in the wrong are mostly the users IMO, sans unhealthy communication styles. They complain to the wrong people about broken promises that nobody made, all while having the solution to their issues in the NEWS file they didn't read.
Posted May 31, 2024 11:34 UTC (Fri)
by rschroev (subscriber, #4164)
[Link] (6 responses)
I don't see how it happening in unstable is an excuse. Of course it happens in unstable, that's where Debian development is done. Are users only allowed to file reports when an issue is noticed in stable? That makes no sense at all. Unstable and testing exist precisely to fix issues before shipping the next stable. We should praise people for reporting issues, not blame them because 'they should expect breakage'.
And of course this new keepassxc would not have gone in the current stable, but in the next one. That doesn't make it any better. People rightly expect upgrades from one stable to the next not to break things unless there's a good reason for it, and I agree with people who say that this loss of functionality does not have good reason.
Posted May 31, 2024 11:45 UTC (Fri)
by mb (subscriber, #50428)
[Link] (4 responses)
Sorry, but that expectation is completely wrong.
>unless there's a good reason for it, and I agree with people who say that this loss of functionality does not have good reason.
Ok. But other people think that a decrease in attack surface is a good reason.
Keep in mind that this is not just any random packet. It literally is the key to everything.
You can still install the full package. I really don't see what's so special here. Stuff like this happens all the time when upgrading the system. That's why people should read the upgrade news.
Posted May 31, 2024 14:44 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (1 responses)
Yeah. In between. As in, things might be somewhat broken while you're developing the Next Great Release, but when you're ready to burn another Stable (which in Debian is supposed to mean "when they migrate to Testing" but obviously doesn't always) they're back to being unbroken.
This stuff needs to be discoverable. Either you get a "do you want/need the full version" prompt on upgrade (which is what the maintainer seems to be planning), or a "hey you'll need the bells-and-whistles version for this" message when you try using a feature that's now only in -full (which requires support from upstream).
"Read the NEWS files" isn't that helpful when a distribution has a heap of packages with more-or-less-breaking changes, 90% of which don't apply to me and/or I could care less about. Keep in mind that the NEWS's audience is developers and sysadmins as well as "users" (who when they don't admin their own computers don't even get to read the NEWS files, and if they do the info/chaff ratio is even worse).
Posted May 31, 2024 14:50 UTC (Fri)
by pizza (subscriber, #46)
[Link]
Sorry, no. Again, let me quote the Debian wiki ( https://wiki.debian.org/DebianTesting )
> How Debian Testing Works
Again. *TESTING IS NOT STABLE* And that is the entire point of having it. To find issues *before* a new stable release is cut.
Posted May 31, 2024 14:53 UTC (Fri)
by rschroev (subscriber, #4164)
[Link] (1 responses)
The reason for stable releases is that they are stable, and that does indeed imply that there's a lot less stability from one stable release to the next. Breaking changes are sometimes unavoidable, and by having stable releases those breaking changes happen between stable releases. That doesn't mean we have to have breaking changes; I'll argue we should strive to keep that to the absolute minimum possible.
> Ok. But other people think that a decrease in attack surface is a good reason.
I have to admit, I do see a point there: in the scenario where keepassxc keeps it full functionality and a new package keepassxc-min is created, people who don't read the detailed release notes (i.e. when it comes to desktops most people, I assume) would never know about keepassxc-min. Whereas in the scenario where keepassxc loses its functionality and a new package keepassxc-full is created, people would quickly find out that their use case is not supported anymore, and will hopefully quickly find out that they can transition to keepassxc-full.
Posted May 31, 2024 20:25 UTC (Fri)
by mrugiero (guest, #153040)
[Link]
Breaking changes for the sake of it, right, undesirable. But they do happen and they are expected between stable releases, and they are expected in unstable. The whole point is that you have stability as long as you don't migrate to next stable, not that the whole distro is forever stagnant.
> I have to admit, I do see a point there: in the scenario where keepassxc keeps it full functionality and a new package keepassxc-min is created, people who don't read the detailed release notes (i.e. when it comes to desktops most people, I assume) would never know about keepassxc-min. Whereas in the scenario where keepassxc loses its functionality and a new package keepassxc-full is created, people would quickly find out that their use case is not supported anymore, and will hopefully quickly find out that they can transition to keepassxc-full.
And that's precisely the point. The package manager was designed precisely to allow this. You have transitional packages to force choices, software that informs you of manual intervention you may require, and a release model that doesn't push such changes to a given stable release. But at the moment you opt-in to upgrade, you are expected to give care to such possible breaking changes.
Posted May 31, 2024 20:25 UTC (Fri)
by mrugiero (guest, #153040)
[Link]
It's not just mistakes and incompatibilities. As you said, that's where development happen. That's where you have the chance to make breaking changes if you judge they are needed. The packager judged them needed and so he introduced them.
> Deliberately removing functionality without a very good reason, I'm not so sure that is what someone should expect. But OK, it can happen.
Your very good reasons may be my irrelevant excuses. The packager gave his reasons and it does sound like the original package had more things than Debian packages tend to bring by default. Most other packages have plenty of optional dependencies and what not.
> But when people report that e.g. they can't open their password database anymore because their is no support for hardware keys anymore and they're not taken seriously, that is not to be expected.
That may have been wrong, yeah.
> When people ask to "Put the base package back where it was and create a keepassxc-minimal" and get "that's not going to happen" as an answer, that's not to be expected. That's going to upset people.
Demands and asks are two different things. The packager offered a solution, which was a keepassxc-full. The users decided pointing to the other package was too much work, apparently.
> I don't see how it happening in unstable is an excuse. Of course it happens in unstable, that's where Debian development is done. Are users only allowed to file reports when an issue is noticed in stable?
Certainly not. You can and should file issues against unstable. But that's moving the goal post, we were arguing whether you should expect a flawless break-free experience on unstable and whether that's a fair expectation. Demanding the solution to be "keep my setup as it is" when running on unstable is what's out of place. It's the place where breakage is allowed and you opted in, you deal with some changes that require manual intervention, such as moving to keepassxc-full. If it still breaks because of bad packaging, then it's a different story.
> That makes no sense at all. Unstable and testing exist precisely to fix issues before shipping the next stable. We should praise people for reporting issues, not blame them because 'they should expect breakage'.
We should praise them for testing, reporting, etc. Not for demanding a change be reverted just because it breaks a stability promise that nobody made. Certainly not for bothering the wrong person.
Posted May 31, 2024 9:31 UTC (Fri)
by Duncan (guest, #6647)
[Link] (4 responses)
I beg to differ.
A user that does system package upgrades is by definition administrating the system when they do so, which by definition makes them a system administrator, if only of their own personal system(s), and users with the privileges to do system administration should absolutely take that role as seriously as the title suggests, thereby minimizing issues such as this as they /will/ have read those news items, /especially/ if in their system administrative role they've made the choice to run unstable/testing as opposed to stale^H^Hble.
> An admin can be expected to read the update notes and, say, replace exim4-core with exim4-heavy when they need an uncommon feature that's been chopped off the standard package.
There we agree! =:^)
> Again: we're talking "normal" users here.
There we disagree. It's in the basic definition of "user" vs. "system admin". Facts are facts, if you're installing system software, you're a sysadmin, and if you fail to take that responsibility seriously you're doing so at both your own peril and the community peril of potentially spreading any malware you may activate as a result of that failure.
> Somebody who is security-hyper-conscious can be expected to manually replace keepassxc with keepassxc-minimal, along with all the other stuff that needs replacing or restricting for these use cases.
Regardless of whether one thinks the default should be the full or the secure package, that said default was changed without the customary transitional package, etc, is "unfortunate", but that's exactly the sort of to-be-found/reported/fixed bugs that unstable/testing sysadmins have (in that role) opted into by choosing to be the guinea pigs that do just that so it can be fixed before it reaches stable. As such, it isn't, or at least shouldn't be, a major problem at all.
Posted May 31, 2024 11:18 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
And there you are living in a perfect world where everything is neatly laid out as it should be.
I live in the real world, where I am a *gentoo* *user*. Read into that what you will ...
Cheers,
Posted May 31, 2024 12:21 UTC (Fri)
by jem (subscriber, #24231)
[Link] (1 responses)
I once maintained Gentoo on my own computers, but switched to Arch Linux, not least because I realized Gentoo is not very ecological. Ok, maybe that doesn't matter so much with a market share of 0.08%, but "Gentoo World Domination" would be a disaster with everybody compiling the world once a day.
Posted May 31, 2024 15:56 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Because it helps me learn a little bit more about modern Linux. I date from the days before Windows - when there was a lot more to home computers than DOS - and it was possible to (at least superficially) understand everything there was to understand. The first computer I really worked with ran 20 users off 256KB of ram ... my next employer bought one of the very first HP LaserJets in the UK, and things are just getting toooo complex to understand. Gentoo, where I at least have *some* control of what's going on, gives me a deeper understanding. I like to know the detail, but my strength always lies in having an overview at a deeper depth than anyone else around me ... :-)
> not least because I realized Gentoo is not very ecological. Ok, maybe that doesn't matter so much with a market share of 0.08%, but "Gentoo World Domination" would be a disaster with everybody compiling the world once a day.
Given the obsession of humanity to have an "always on" archive of everything we've ever know (YouTube, the Wayback machine, BigQuery, Facebook, etc) and our habit of "let the computer do it rather than use our brains" - you know, AI, SQL databases, monte carlo predictions, I think a successful Gentoo World Domination would be but a drop in the ocean.
Oh - and did you know Gentoo (can be) a binary distribution now? Okay, when I had a farm of machines, I would upgrade them at random but they were configured to share the same download archive, and create and store binary packages to save compilation, but now the mirrors themselves carry binary packages for most common USE flag sets.
They've carried binaries for the hogs - Chrome, Firefox, LibreOffice, Rust, gcc et al - for ages, but now they carry binaries for most things.
Cheers,
Posted Jun 8, 2024 4:56 UTC (Sat)
by fest3er (guest, #60379)
[Link]
Posted May 23, 2024 8:49 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
However, the version number is not used for this purpose. Instead, you have to go the virtual package route. Unfortunately, because it requires manual intervention, it will cause anything running unattended-upgrades to silently* fail to upgrade, and just sit on the old version forever. It's acceptable in this case for two reasons:
1. They are delaying it until the next stable release, which means the current stable won't be broken. Nobody expects unattended-upgrades to successfully apply a full distro upgrade.
* Yes, you can set up various kinds of remote monitoring such as apt-listchanges. But by the time you go to the trouble of doing that, and configure an MTA, and get all of the DKIM/SPF/etc. nonsense to a place where random people are not putting your IP address on the naughty list, and so on, you're in full-blown cattle-not-pets territory, and unattended-upgrades is probably the wrong abstraction for that purpose anyway.
Posted May 22, 2024 17:28 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link] (4 responses)
Posted May 22, 2024 22:06 UTC (Wed)
by jafd (subscriber, #129642)
[Link] (1 responses)
Posted May 23, 2024 7:29 UTC (Thu)
by elboulangero (subscriber, #81193)
[Link]
Posted May 24, 2024 10:37 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
The problem is that they didn't read it.
https://salsa.debian.org/debian/keepassxc/-/blob/main/deb...
Posted May 24, 2024 10:40 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link]
Posted May 22, 2024 17:00 UTC (Wed)
by cen (subscriber, #170575)
[Link] (14 responses)
Posted May 22, 2024 17:20 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (11 responses)
No, the correct decision is the one that does not break users' workflows on upgrade.
There are many things that I dislike in Debian, but the one thing that I _have valued_ in Debian _very much_ is that it is a stable platform, the one that can be counted on to **not break** when upgraded or dist-upgraded. This is the single reason why I have used (and recommended) Debian at all.
What this incident has just told me, is that Debian **can no longer be trusted** not to break a workflow.
Posted May 22, 2024 17:29 UTC (Wed)
by cen (subscriber, #170575)
[Link]
Posted May 22, 2024 17:29 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link]
Posted May 22, 2024 17:32 UTC (Wed)
by pizza (subscriber, #46)
[Link] (7 responses)
Only if you're running Debian *stable*.
> What this incident has just told me, is that Debian **can no longer be trusted** not to break a workflow.
Um, if you deliberately choose to run Debian testing or unstable, by definition it can break on you.
Meanwhile, you apparently didn't actually *read* the article:
"The actual impact will be negligible for users of stable versions of Debian, Ubuntu, and other Debian-derived distributions. Klode said that when Debian Trixie is released, upgrades and new installs of the keepassxc package will receive a transitional package that prompts them to decide between "full" and "minimal" packages. Klode says that this will allow users upgrading from bookworm to preserve their current setup. Future releases will have a "virtual" keepassxc package that, again, requires the user to explicitly select one or the other."
Posted May 22, 2024 17:37 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (6 responses)
> Um, if you deliberately choose to run Debian testing or unstable, by definition it can break on you.
What's unstable today, will become stable tomorrow. This is a non-reply.
> Meanwhile, you apparently didn't actually *read* the article
I have read the article, thank you very much for patronizing me (not). It also tells me that the whole "choice" thing only happened because this issue was publicized and resulted in pressure, and the next time it might not happen.
Posted May 22, 2024 17:46 UTC (Wed)
by pizza (subscriber, #46)
[Link] (5 responses)
I'm alwasys glad when I can correct folks' unreasonable expectations.
> What's unstable today, will become stable tomorrow. This is a non-reply.
Uh. do you not understand the basic difference between the words "stable", "testing", and "unstable"?
Because you seem to be claiming that they are synonymous.
> It also tells me that the whole "choice" thing only happened because this issue was publicized and resulted in pressure
That does not appear to be supported by facts in evidence.
> and the next time it might not happen.
If that happens, you might be entitled to a full refund.
I wish you the best of luck in your quest to be perpetually supplied with perfect software, for free.
Posted May 22, 2024 18:15 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (4 responses)
There weren't and you didn't.
> Uh. do you not understand the basic difference between the words "stable", "testing", and "unstable"?
You apparently didn't **read** my comment. (See, this works both ways.)
> That does not appear to be supported by facts in evidence.
The reading of the article suggests that the transitional package only appeared after multiple rounds of heated discussion, and the original decision was simply to ship the stripped version as "keepassxc".
Posted May 22, 2024 21:50 UTC (Wed)
by pizza (subscriber, #46)
[Link] (3 responses)
Even if you are correct, all it shows is that Debian's development/packaging process (including the stated purpose of "Debian testing") is working as intended, and no "stability promises" [1] having been violated.
[1] Which only apply within a given stable release, not within testing or (especially) unstable. Even upgrades between major releases don't (and can't!) promise that everything that used to work will continue to work exactly as before. [2]
Posted May 23, 2024 1:47 UTC (Thu)
by sionescu (subscriber, #59410)
[Link] (2 responses)
Only because users opposed the changes vehemently. The change should not have occurred in the first place.
Posted May 23, 2024 9:08 UTC (Thu)
by bluca (subscriber, #118303)
[Link]
Posted May 23, 2024 9:37 UTC (Thu)
by mb (subscriber, #50428)
[Link]
So? It's called the development and testing process. That's why we have unstable and testing.
Posted May 24, 2024 10:39 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link]
https://salsa.debian.org/debian/keepassxc/-/blob/main/deb...
They pressed "q" without reading and then complained…
It is very normal to use a NEWS file if a package is introducing some changes that might require a manual action.
Posted May 22, 2024 21:55 UTC (Wed)
by WolfWings (subscriber, #56790)
[Link] (1 responses)
There's a difference between disabling networking that does things like favicon fetches, and disabling so much networking that it can't even communicate with a hardware USB encryption token.
Turning off the 'look pretty' network features in the default install is all well and good, but disabling things like hardware security token support because they ripped out the entire networking suite blindly is a dis-service to the users.
PGP broadly failed because it was so obtuse, there's a certain degree of lubricity you need with security features to make them well used. And this blind 'chop the whole forest down' approach I think overstepped.
Posted May 23, 2024 9:14 UTC (Thu)
by taladar (subscriber, #68407)
[Link]
Posted May 22, 2024 17:47 UTC (Wed)
by atnot (subscriber, #124910)
[Link] (2 responses)
The biggest reason 99% of people will have data compromised is not some advanced supply chain attack. It is phishing and password reuse.
The only good defense against the former is binding authentication credentials to domains. That is, security keys, which most people will not bother with, and password managers that look up the credentials based on the browser domain. The keepassxc browser extension is essential in defending against these very common attacks. It is almost guaranteed that people will, out of habit, copy and paste their password into places they should not have as a result of this.
The only good defense against the latter is passwordless auth, which nothing supports and, more importantly a password manager you actually use. Luckily, password managers are mostly actually a better experience than remembering passwords. You just hit "generate password" on the password field, hit "save login" and the next time you come back the credentials will just be there for you. But that compelling experience only exists with proper integration with the browser. Without it, the friction meant that I frequently just used my old bad passwords.
I do appreciate the thought of reducing the attack surface. But you really have to be careful that you don't end up exposing people to real, common, everyday risks by trying to protect them from hyothetical, rare and esoteric ones.
Posted May 22, 2024 20:35 UTC (Wed)
by Rigrig (subscriber, #105346)
[Link] (1 responses)
Actually, Passkey support is starting to grow. I've already got it set up for GitHub, Nextcloud and Albert Heijn (a Dutch supermarket, happily surprised how soon they implemented it)
And the only reason I'm using it, is that KeePassXC supports it: https://keepassxc.org/blog/2024-03-10-2.7.7-released/
Posted May 23, 2024 11:00 UTC (Thu)
by Lennie (subscriber, #49641)
[Link]
https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-sh...
Posted May 22, 2024 19:39 UTC (Wed)
by q3cpma (subscriber, #120859)
[Link] (1 responses)
That whole "issue" wouldn't even exist there.
Posted May 25, 2024 14:47 UTC (Sat)
by swilmet (subscriber, #98424)
[Link]
The USE flags permits to have more control over what is enabled, and KeePassXC in Gentoo is well packaged in that regard.
Debian only has a binary choice. (Pun intended).
Posted May 23, 2024 5:55 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (1 responses)
Well, no. When upgrading the installer takes the first option it sees (and can install without conflicts). There is no prompt.
Debian's Alternatives handling only kicks in when you install both alternates. For this to work on upgrades, the virtual package must depend on *both* alternates (or at least recommend both). That's not a super good idea either, and arguably a misuse of the packaging system.
That said I'm firmly in the "keep the full version and create a -min package for the purists" camp.
Posted May 23, 2024 12:56 UTC (Thu)
by juliank (guest, #45896)
[Link]
1. The first step is to make keepassxc real package Depend on keepassxc-full | keepassxc-minimal, then upgrades to trixie will get keepassxc-full installed. This is called a transitional package.
Package keepassxc is a virtual package provided by:
Error: Package 'keepassxc' has no installation candidate
Where you are correct is that if you pull in keepassxc by a dependency, it will pick the first one in its cache file; this would be keepassxc-full likely as it is earlier in the alphabet.
Posted May 23, 2024 6:45 UTC (Thu)
by pkolloch (subscriber, #21709)
[Link] (3 responses)
Posted May 23, 2024 14:04 UTC (Thu)
by Lionel_Debroux (subscriber, #30014)
[Link] (1 responses)
Agreed, the hate mob strategy is toxic and thoroughly despicable. That, and the fact that a current upstream maintainer wants to make it harder for downstreams to strip down their code base, and blurted out essentially that a larger code base with more attack surface is more secure than a stripped-down code base (seriously ? Fortunately, a former maintainer has corrected him), really does not make me confident about the KeePassXC project's security and its current direction...
Posted May 30, 2024 13:30 UTC (Thu)
by mrugiero (guest, #153040)
[Link]
Posted May 23, 2024 16:22 UTC (Thu)
by lunaryorn (subscriber, #111088)
[Link]
And besides, the downstream packager maintainer didn't really do their part to cool things down.
When asked to revert, they could've said "I'm sorry that complaints about this change ended up in your bug tracker. I still stand by my changes, tho, but let's talk and find out how we can settle things for good on both sides".
But instead they firmly and somewhat arrogantly dug in their heels and called parts of the upstream they themselves package "crap". I don't think that's a healthy or respectful attitude towardas upstream, especially one that delivers a product of such quality as the keepassxc team does.
Now, I'm not saying upstream wouldn't have been better off taking a deep breath, and wait a few days for the heat to cool off, instead of shooting out a rushed and aggressive reply.
But if this had been my upstream I'm not sure I'd have done better. I guess I'd probably have shot a lot more than just flaming arrows, because in this case personally I find the attitude and behaviour of the Debian packager deeply disrespectful, even insulting.
Posted May 23, 2024 16:33 UTC (Thu)
by lunaryorn (subscriber, #111088)
[Link] (6 responses)
But when you screw up (at least from an upstream standpoint), and then don't say sorry, but instead firmly and somewhat arrogantly assert your stance is right and proceed to call parts of the (at this point already quite angry) upstream "crap", you... kinda had it coming I guess.
Posted May 24, 2024 10:47 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (5 responses)
Posted May 24, 2024 12:37 UTC (Fri)
by lunaryorn (subscriber, #111088)
[Link] (4 responses)
I think we can agree that upstream believes that the downstream maintainer screwed up, at least to some degree, can't we? Upstream wouldn't have sternly asked for a revert otherwise, would they?
Now, my point isn't whether upstream is right or wrong here, or whether the changes downstream made are right or wrong. I for my part don't care much, and I'm not affected. I don't use Debian.
My point is only the peculiar response of the downstream maintainer after being asked to revert. Whether you're right or wrong factually, that's just not a particularly respectful way to interact with your upstream...
Posted May 24, 2024 14:45 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
The problem with upstream's request is that the downstream maintainer used an upstream-supplied-and-supported build configuration.
....If upstream had a problem with that configuration, they shouldn't have provided it to begin with.
Posted May 24, 2024 15:39 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
If you consciously use that configuration then you know what you're doing. In particular you know not to complain to Upstream when your browser integration button is missing.
A minimal config that'd make sense in this context would pop up a message that you need to install the full version instead.
Posted May 24, 2024 16:23 UTC (Fri)
by lunaryorn (subscriber, #111088)
[Link] (1 responses)
My point is that I find the response of the downstream maintainer pretty rude and disrespectful. Even if they were undoubtedly right and correct, it's still not okay to call upstream "crap", and being entirely unsympathetic to upstream's issues with their decision certainly didn't help.
See, if they had just said "I'm sorry that this change of mine ended up on your issue tracker. I still would like to change the default build configuration, but let's perhaps talk about how we can handle this transition together without causing issues to upstream?" we probably wouldn't have this article on LWN. But they didn't, so here we are...
Posted May 24, 2024 17:09 UTC (Fri)
by pizza (subscriber, #46)
[Link]
The disrespect went in both directions, and from each party's point of view, was justifiable.
And it's very easy to stand on the sidelines and say "you should do better" when you're not the one(s) under attack.
It seems to me the only ones "wrong" here are the actual end-users.
Posted May 23, 2024 18:11 UTC (Thu)
by e-rk (subscriber, #166547)
[Link]
Without the browser integration, the user has to copy the passwords over clipboard. Is clipboard (especially on X11 systems) more secure than KeePassXC IPC interface? The KeePassXC IPC clients are authenticated. Is it more secure to use the clipboard over the authenticated IPC channel?
Without the browser integration the user has to verify the domain manually. The browser plugin I use uses TOFU. Is having the user manually verify the domain more secure than having a browser plugin do it automatically?
Without the browser integration the user has to copy the password into the right field. If the user pastes the password into the wrong field, it might get read by javascript and sent who knows where. Is it more secure to have the user paste the password, or have the browser plugin enter the password in the right field automatically?
These scenarios are what I came up with in a few minutes and I'm sure I could find more. The scenarios only concern browser integration, because that's the only networked feature I use. I'm sure I could come up with scenarios involving other features, if I were using them.
It's a shame that no proper analysis was made and no findings were presented to the public before the change. Maybe it would have turned out that the risks of having networked features outweigh the benefits.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
I get that it's normal to expect browser integration, but you already left "normal" users out from preconditions. And yeah, your distro says in big letters "unstable", if you don't expect changes it's a layer 8 bug. If you want big warnings when things change, or not change at all, stable is there for you.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
>
>Packages from Debian Unstable enter the next-stable testing distribution automatically, when a list of requirements is fulfilled:
>
> The package has been in "unstable" at least for 2-10 days (depending on the urgency of the upload).
> The package has been built for all the architectures which the present version in testing was built for.
> Installing the package into testing will not make the distribution more uninstallable.
> The package does not introduce new release critical bugs.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
>
> As with all Debian release names, Sid takes its name from a ToyStory character. In the movie, Sid is the kid next door who breaks his toys and makes nasty creatures of them.
>
> While other release code names progress in time from being "testing" to being "stable", Sid is forever doomed to being unstable. Sid will always be the unstable branch. When the current "testing" repository becomes mature and is released, "testing" becomes the latest "stable" release. From there, a new "testing" repository will be created with the next planned code name, and packages will continue to trickle down from Sid into "testing" just as before.
>
> Sid is where packages go after they've been uploaded by their maintainer, and cleared for release by the FTP master. When packages have met certain criteria, they are automatically moved from Sid to the current "testing" repository. The "Unstable" repository is updated every 6 hours.
I don't think experimental is about breaking changes but rather potentially harmful software, due to an unfinished nature. This isn't the case from my POV, but rather a mere change on packaging. Does it need testing? Yeah. Does it break the existing workflow of some users? Yes, too. But is the software itself broken or dangerous to use? No. Then, unstable. It is the right repo.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
The only reason for having stable releases is to have breaking changes in between.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
>
>Packages from Debian Unstable enter the next-stable testing distribution automatically, when a list of requirements is fulfilled:
>
> The package has been in "unstable" at least for 2-10 days (depending on the urgency of the upload).
> The package has been built for all the architectures which the present version in testing was built for.
> Installing the package into testing will not make the distribution more uninstallable.
> The package does not introduce new release critical bugs.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Essentially, the difference is in the definition of bug for each case. For stable, if your current config no longer works, it is a bug. For unstable, that is simply a change that requires manual intervention, and only proper software flaws are bugs.
But in any case, when you use a distro package you check their issue tracker first, before bothering upstream. It's common sense, upstream doesn't have the same version.
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Wol
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Wol
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
2.keypassxc is an interactive app, so breaking unattended-upgrades is less of a catastrophe (the user is more likely to notice that an upgrade is pending but failing to apply).
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
Versioning packages for breaking upgrades
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
> Because you seem to be claiming that they are synonymous.
The KeePassXC kerfuffle
[2] While Debian works very hard to achieve this goal, there are always exceptions -- With every release global/system features are deprecated or dropped outright, and that doesn't even begin to touch on potentially incompatible changes to upstream software.
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
Everything works as expected.
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
2. The second step is to remove said transitional package. At this point, apt install keepassxc will say:
keepassxc-minimal <version>
keepassxc-full <version>
You should explicitly select one to install.
Thank you for the calmly written, reasonable assessment.
As you wrote, both positions can be argued for and there is way too much drama about a decision with relatively little impact and an easy workaround if you disagree with the maintainer.
Worst of all is this hate mob strategy: directing a bunch of people to express their anger at the maintainer.
The KeePassXC kerfuffle
The KeePassXC kerfuffle
I really hope that most other downstreams will follow suit by stripping down keepassxc by default, providing a keepassxc-full package, and providing an upgrade path between the two upon the next release :)
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle
The KeePassXC kerfuffle