It is our responsibility to our users to provide them the most secure option possible as the default.
Security is there to keep the features usable without interruptions or risks.
E.g. plugging the computer off the network is not about security if the service needs to be accessible.
Very concrete example, the whole Log4j vulnerability issue was basically just a direct implication of a feature that allowed for arbitrary code execution. Nearly no user of Log4j intentionally used that feature, they were all vulnerable because Log4j had that feature.
The fix to the CVE was effectively to remove the feature. If someone had the foresight to try to reduce Log4j to only the features that ~everyone actually used, and publish a separate Log4j-maximal for the fringe users that intentionally use that feature, it would have prevented what was arguably the worst vulnerability that has ever happened.
In the case this thread is about, no one seems to be deny that there should be a 'minimal' and 'full' versions and that the 'minimal' version is going to be more secure. The entire flame war seems to be over whether its better to take a preexisting package name and have it be a minimal one or the full one.
That is simply a tradeoff between "make preexisting users who don't use ancillary features be as secure as possible by default going forward" or "make preexisting users who do use ancillary features not broken by upgrades".
In this case it is not clear at all whether the feature is obscure. For most people it could be actually essential and the primary requirement for the whole software.
This is literally the same as helping a relative to make their computer more secure by turning it off. Problem solved I guess?
If you made a mistake by shipping insecure defaults you could fix it e.g. by including a banner to use the minimal version to users that don't use the extra features. But simply rug-pulling everybody for "security" and doubling down by insulting the affected users? I really do not understand people that act like this.
If I have a program that encrypts and decrypts passwords, then the surface area is way smaller than if it also has browser integrations and a bunch of other features. Every feature has the potential to make this list longer: https://keepass.info/help/kb/sec_issues.html which applies to any other piece of software.
At the same time, people can make the argument that software that's secure but has no useful features also isn't very worthwhile. From that whole discussion, the idea of having a minimal package and a full package makes a lot of sense - I'd use the minimal version because I don't use that additional functionality, but someone else might benefit a bunch from the full version.
We should really hold more value to keeping existing user setups working. Breakages are incredibly damaging and might very well have a bigger impact than insecure defaults.
"All of these features are superfluous and do not really belong in a local password database manager" seems to me like a pretty clear explanation of what is "crap" about them, and it seems pretty clearly not to be about personal taste.
Some people care about modularity.
As teh64 helpfully pointed out in https://news.ycombinator.com/item?id=45784445 some hours ago, 4ish years ago my position on this was a total 360 and I'd have had the same reaction to now-me's proposal.
Most of the academic research into these sorts of typesafe languages usually returns the null result (if you don't agree, it means you haven't read the research on this topic). That's researcher for it didn't work and you shouldn't be using these techniques. Security is a process, not a silver bullet and 'just switch to Rust' is very silvery bullet.
A lot of the Rust rewrites suffer a crucial issue: they want a different license than what they are rewriting and hence rewrite from scratch because they can't look at the code.
But here we're saying: Hey we have this crucial code, there may be bugs hidden in it (segfaults in it are a recurring source of joy), and we'll copy that code over from .cc to .rs and whack it as little as possible so it compiles there.
The problem is much more there on the configuration parser for example which does in a sense desparately need a clean rewrite, as it's way too sloppy, and it's making it hard to integrate.
In an optimal world I'd add annotations to my C++ code and have a tool that does the transliteration to Rust at the end; like when the Go compiler got translated from C to Go. It was glorious.
Unnecessary drama as usual...
The one demanding it is the maintainer of keepassxc it would’ve been better to just close the issue that this is a Debian only problem and he should install it like that and just close it.
now this is separate from being open for discussion if someone has some good arguments (which aren't "you break something which isn't supported and only nich used") and some claim he isn't open for arguments
and tbh. if someone exposes users to actual relevant security risk(1) because the change adds a bit of in depth security(2) and then implicitly denounces them for "wanting crap" this raises a lot of red flags IMHO.
(1): Copy pasting passwords is a very bad idea, the problem is phsishing attacks with "look alike" domains. You password manager won't fill them out, your copy past is prone to falling for it. In addition there are other smaller issues related to clip board safety and similar (hence why KC clears the clipboard after a short time).
(2): Removing unneeded functionality which could have vulnerabilities. Except we speak about code from the same source which if not enabled/setup does pretty much nothing (It might still pull in some dependencies, tho.)
but yes very unnecessary drama
In fact not having it encourages copy and paste which reduces security.
Whats next? Strip javascript support from browsers to reduce the attack surface?
I don't get how this is even a discussion. Either he is paid by canonical to be a corporate saboteur or he is completely insane.
Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725