Debian No-Feature KeePassXC Package

[CedricSchmeits]

Overview

I'm using the Brave and Firefox browsers under Ubuntu testing using keepassxc version 2.7.7, suddenly the browser integration doesn't work anymore. So I went into the settings menu to enabled it again. But the "Browser Integration" from the listbox selection is gone. Not only that one but there are only two items left:

1. Algemeen (General)
2. Beveiliging (Security) See the picture in the attachment. All the other options are missing, so I can't enable the browser integration anymore.

Steps to Reproduce

1. Open keepassxc
2. Goto Tools -> Settings
3. Here the options are missing

Expected Behavior

Working browser options and working integration

Actual Behavior

Browser integration is not working and the options to enable them are not available anymore

Context

KeePassXC - Version 2.7.7 Revision: 68e2dd8

Qt 5.15.10 Debugging mode is disabled.

Operating system: Debian GNU/Linux trixie/sid CPU architecture: x86_64 Kernel: linux 6.7.12-amd64

Enabled extensions:

• Automatisch invullen 81db-edfbe67abc5f)

Cryptographic libraries:

• Botan 2.19.4 Desktop Env: Gnome Windowing System: X11

[hobbes]

Wow, @hobbes, you are either oblivious to how things really work or completely disillusioned by Debian's superiority complex. Either way, here's a hint. If the "people who should know what they are doing" don't read the NEWS or know not to file upstream report, then the casual user ABSOLUTELY WILL NOT. The hand waving here is infuriating at best.

no casual user can be exposed to the current package. Absolutely none.

[droidmonkey]

Ok I misunderstood you, will retract my comment

[Kwpolska]

no casual user can be exposed to the current package. Absolutely none.

This assumes that all casual users are on Debian stable. I do not think this is a valid assumption, some people who are not ultra-casual but also not Debian experts may have chosen testing or unstable due to more recent packages (and still reasonable stability).

[drawks]

I'm going to make another attempt to high-road this discussion a bit....

If you are here to contribute to suggesting a solution to the issue that hasn't yet been advocated before, by all means this is the place to have that discussion.

If you are here to "me too" or worse to degrade the the dialogue with various ad-hominems rest assured that such "contributions" are not actually likely to result in a positive or expedient resolution.

It is unfortunate that @julian-klode has taken the tactic of using demeaning language and and doubling down on their decision instead of engaging in a meaningful discussion.

It is also unfortunate that consumers of the unstable debian release seem to be getting so frothy over a change that is present in a release which is explicitly the place where breaking changes are meant to be floated /before/ they are adopted into testing or stable/release versions.

It is probably past time for this issue to have public comments disabled by the maintainers and for everyone to have a less heated and more promising discussion.

[jstorrs]

If keepassxc provides these compile-time flags it seems a bit off-base to complain when they are actually used?

The issue of upstream receiving bug reports related to packaging seems like it's the only thing that should be relevant to upstream. Which is why I will repeat that the best option here is just to increase visibility to end-users that optional features were disabled during compile. People who don't want network features should be able to quickly see that they're not present. People who want them should be able to quickly see that they're enabled. And when someone asks "hey why isn't this working" quick checks of compile options make triage fast and it never even bubbles into upstream.

[hobbes]

no casual user can be exposed to the current package. Absolutely none.

This assumes that all casual users are on Debian stable. I do not think this is a valid assumption, some people who are not ultra-casual but also not Debian experts may have chosen testing or unstable due to more recent packages (and still reasonable stability).

agreed, but if they are on unstable or testing, they have to know a bit about the processes, docs, and tools of debian. Even more so if they are capable of finding KeepassXC's github project and report an issue. I'm dead serious when I say « just point them to bugs.debian.org ».

The only issue for keepassxc could be that it doesn't show anything when a feature has been « compile time » disabled. It could show something. (could, not should or must).

[droidmonkey]

Gonna lock this up, thank you for the healthy discourse.

[phoerious]

Perhaps to add some final remarks on the "less code means fewer bugs" stance:

Disabling those compile time flags actually removes code and reduce attack surface so yes, the safest KeePassXC is the one with less "enabled flags".

I think this is a fundamental misunderstanding of the relationship between lines and code and attack surface. Bugs are not directly CAUSED by more code, though there is a strong correlation between more code and more bugs. So far I do agree. However, this is not something that can be rectified by more ifdef guards. Bugs are correlated with lines of source code, not with binary size. More ifdef guards mean MORE source code, therefore MORE bugs. Ifdefs in particular (due to the abysmal nature of how the preprocessor works) also add more (basically untestable) compilation unit configurations, hence I think the following proposal is the absolute worst thing we could do:

In the absence of that, the next best thing would be to provide several versions of the package with different « most used » subsets.