LWN: Comments on "The KeePassXC kerfuffle"

Versioning packages for breaking upgrades

fest3er — Sat, 08 Jun 2024 04:56:11 +0000

Instead of 'users' and 'sysadmins', perhaps it would be better to write about 'experts' and 'non-experts'.

Versioning packages for breaking upgrades

mrugiero — Fri, 31 May 2024 20:25:03 +0000

> 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.

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.

Versioning packages for breaking upgrades

mrugiero — Fri, 31 May 2024 20:25:01 +0000

> Yes, if you are on unstable or testing, you should expect breakage: mistakes can happen, incompatibilities can arise, and so on.

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.
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.

> 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.

Versioning packages for breaking upgrades

Wol — Fri, 31 May 2024 15:56:28 +0000

> May I ask *why* you are a Gentoo user,

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,
Wol

Versioning packages for breaking upgrades

rschroev — Fri, 31 May 2024 14:53:37 +0000

> The only reason for having stable releases is to have breaking changes in between.

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.

Versioning packages for breaking upgrades

pizza — Fri, 31 May 2024 14:50:52 +0000

> But when you're ready to burn another Stable (which in Debian is supposed to mean "when they migrate to Testing"

Sorry, no. Again, let me quote the Debian wiki ( https://wiki.debian.org/DebianTesting )

> How Debian Testing Works
>
>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.

Again. *TESTING IS NOT STABLE* And that is the entire point of having it. To find issues *before* a new stable release is cut.

Versioning packages for breaking upgrades

smurf — Fri, 31 May 2024 14:44:35 +0000

> The only reason for having stable releases is to have breaking changes in between.

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).

Versioning packages for breaking upgrades

jem — Fri, 31 May 2024 12:21:02 +0000

May I ask *why* you are a Gentoo user, if not because Gentoo enables you to be more of a system admin than on any other distro? Gentoo advertises itself as being "extremely configurable", which equates to "extremely brittle".

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.

Versioning packages for breaking upgrades

mb — Fri, 31 May 2024 11:45:21 +0000

>People rightly expect upgrades from one stable to the next not to break things

Sorry, but that expectation is completely wrong.
The only reason for having stable releases is to have breaking changes in between.

>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.

Versioning packages for breaking upgrades

rschroev — Fri, 31 May 2024 11:34:21 +0000

Yes, if you are on unstable or testing, you should expect breakage: mistakes can happen, incompatibilities can arise, and so on. Deliberately removing functionality without a very good reason, I'm not so sure that is what someone should expect. But OK, it can happen. 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. 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.

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.

Versioning packages for breaking upgrades

Wol — Fri, 31 May 2024 11:18:11 +0000

> 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.

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,
Wol

Versioning packages for breaking upgrades

Duncan — Fri, 31 May 2024 09:31:05 +0000

> We're talking users here, not sysadmins.

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.

Versioning packages for breaking upgrades

mrugiero — Fri, 31 May 2024 03:31:31 +0000

> Debian Unstable (also known by its codename "Sid") is not strictly a release, but rather a rolling development version of the Debian distribution containing the latest packages that have been introduced into Debian.
>
> 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.

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.
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.

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.

Versioning packages for breaking upgrades

pizza — Thu, 30 May 2024 15:38:36 +0000

> But todays packages in testing are tomorrow's packages in stable.

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.

Versioning packages for breaking upgrades

rschroev — Thu, 30 May 2024 15:22:07 +0000

> > Well, yeah, except that Debian Testing is assumed not to contain stuff that shouldn't get into Stable. In other words, today's users of Testing are tomorrow's users of Stable.

> 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.

Versioning packages for breaking upgrades

pizza — Thu, 30 May 2024 14:59:45 +0000

> Well, yeah, except that Debian Testing is assumed not to contain stuff that shouldn't get into Stable. In other words, today's users of Testing are tomorrow's users of Stable.

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 )

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.

Versioning packages for breaking upgrades

smurf — Thu, 30 May 2024 14:28:02 +0000

Well, yeah, except that Debian Testing is assumed not to contain stuff that shouldn't get into Stable. In other words, today's users of Testing are tomorrow's users of Stable. Thus the fact that this only affects a few people (at the moment) is kindof irrelevant. The fact that it's "only" in Testing and people are *already* complaining to upstream about a change they didn't author doesn't help. Yes users of Testing should know better but it appears that so should the package's maintainer.

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.

The KeePassXC kerfuffle

mrugiero — Thu, 30 May 2024 13:30:48 +0000

Exactly what I would do if I was hiding a backdoor in the optional features *hides the tinfoil hat*

Versioning packages for breaking upgrades

mrugiero — Thu, 30 May 2024 13:05:00 +0000

> Again: we're talking "normal" users here.

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.
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.

The KeePassXC kerfuffle

swilmet — Sat, 25 May 2024 14:47:32 +0000

Indeed: https://packages.gentoo.org/packages/app-admin/keepassxc

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).

The KeePassXC kerfuffle

pizza — Fri, 24 May 2024 17:09:06 +0000

> My point is that I find the response of the downstream maintainer pretty rude and disrespectful.

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.

The KeePassXC kerfuffle

lunaryorn — Fri, 24 May 2024 16:23:27 +0000

As I said, my point's not about who's right or wrong here, or whether upstream's request to revert was justified or not.

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...

The KeePassXC kerfuffle

smurf — Fri, 24 May 2024 15:39:06 +0000

Yeah, a config that's provided for special uses.

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.

The KeePassXC kerfuffle

pizza — Fri, 24 May 2024 14:45:23 +0000

> 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...

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.

The KeePassXC kerfuffle

lunaryorn — Fri, 24 May 2024 12:37:35 +0000

I wasn't talking about everybody, but specifically about upstream's standpoint ;)

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...

The KeePassXC kerfuffle

LtWorf — Fri, 24 May 2024 10:47:41 +0000

The problem here is that not everybody thinks he "screwed up" at all.

Versioning packages for breaking upgrades

LtWorf — Fri, 24 May 2024 10:40:46 +0000

I replied to the wrong comment :)

The KeePassXC kerfuffle

LtWorf — Fri, 24 May 2024 10:39:44 +0000

The change of functionality was shown to the users of the package.

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.

Versioning packages for breaking upgrades

LtWorf — Fri, 24 May 2024 10:37:47 +0000

And there was a NEWS file, so users have been notified of the change and the manual action needed to keep going as before (install keepassxc-full instead).

The problem is that they didn't read it.

https://salsa.debian.org/debian/keepassxc/-/blob/main/deb...

The KeePassXC kerfuffle

e-rk — Thu, 23 May 2024 18:11:59 +0000

The maintainer made the package offline, but is the overall effect net positive or negative for user's security?

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.

The KeePassXC kerfuffle

lunaryorn — Thu, 23 May 2024 16:33:17 +0000

No maintainer should be thrown to the fire for screwing up in public.

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.

The KeePassXC kerfuffle

lunaryorn — Thu, 23 May 2024 16:22:49 +0000

Whom else should users direct their anger to in this case, if not the downstream packager maintainer? Upstream can do nothing about the change, yet still gets the heat on their issue tracker.

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.

The KeePassXC kerfuffle

Lionel_Debroux — Thu, 23 May 2024 14:04:17 +0000

Likewise, thanks for this article.

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...
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

juliank — Thu, 23 May 2024 12:56:42 +0000

I can explain this to you a bit more in detail:

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.
2. The second step is to remove said transitional package. At this point, apt install keepassxc will say:

Package keepassxc is a virtual package provided by:
keepassxc-minimal <version>
keepassxc-full <version>
You should explicitly select one to install.

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.

The KeePassXC kerfuffle

Lennie — Thu, 23 May 2024 11:00:47 +0000

And supposedly also a thing of the past again:

https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-sh...

The KeePassXC kerfuffle

mb — Thu, 23 May 2024 09:37:21 +0000

>Only because users opposed the changes vehemently.

So? It's called the development and testing process. That's why we have unstable and testing.
Everything works as expected.

The KeePassXC kerfuffle

taladar — Thu, 23 May 2024 09:14:48 +0000

It is not as if the Debian maintainer changed the codebase, they just disabled existing upstream compile time options.

The KeePassXC kerfuffle

bluca — Thu, 23 May 2024 09:08:47 +0000

Nice crystal ball you got there, pass it around, want to divinate a few things myself

Versioning packages for breaking upgrades

NYKevin — Thu, 23 May 2024 08:49:44 +0000

This can be done, and the article describes one way of doing it.

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.
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).

* 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.

Versioning packages for breaking upgrades

elboulangero — Thu, 23 May 2024 07:29:55 +0000

apt-listchanges is installed by default by the Debian installer, it's a package with "Priority: standard".