If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages.
Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725
To be honest I don't really read insults either in this e-mail or in the thread you linked. If I'm seeing it right, there's only one comment by the guy in that thread, right? That comment is direct and uses language that may be considered unprofessional ("crap"/"crappy"), but it's not insulting the users (they are not referred to as crappy). Same for the e-mail.
Unnecessary drama as usual...
Browser integration is a completely basic feature I expect from any password manager. It is absolutely useless for most people without it.
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.
FWIW, I've used KeePass for years and have never used its browser integration...
I don’t think the language is unprofessional, it’s direct and it states his opinion.
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.
mainly people have issues with clear, precise and concise language about intend of action instead of idk. a request of discussion
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
The HN post doesn't seem very confrontational to me, but some folks see it so, weird.
The level of knee-jerk reaction to anything Rust into traditionally C projects borders on the pathological. That email is about as polite as it gets without being coddling.
Do keep in mind that a lot of the people involved in these sorts of things are neurodiverse in some ways, and may have significant trouble dealing with change.
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.
All these changes requires work. Because of this, other priorities will get less attention. It would be ironic if bad security flaws are missed/introduced because of all the work switching to Rust. Its also very likely that all the new code written in Rust will be far less mature than the existing source bases. So the outcome might be (very probably actually) a lot of work to worsen security.
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.
It's not like I'm in a hurry to switch to Rust and will spend full steam on it. It's amongst the lowest priority items.
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.
*180, for other people confused by this.
/me hides in shame
You’re right this guy is a dick, as soon as I read this email I went to check who it was and laughed because I remembered that keepers thread.
What a horrible mindset. I'll never understand this "security" argument.
Removing features is not the most secure option possible. Go all the way then and remove everything. Only when your computer cannot do anything it will be 100% secure.> Removing features is not the most secure option possible.
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.
A password program that integrates with your browsers reduces a lot of attack surfaces. If you can't directly talk to the bower that implies the clipboard which in turns means other programs on your system can see the password.
Some people don't have actual understanding of the meaning of security.
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.
That doesn't sound right to me; its legitimate topic that a package where the core use-case is X, that package has obscure feature Y, and the mere existence of Y can cause security issues for a user even when the user never intended to use it.
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".
> That doesn't sound right to me; its legitimate topic that a package where the core use-case is X, that package has obscure feature Y, and the mere existence of Y can cause security issues for a user even when the user never intended to use it.
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.
But many users were relying on these features. Hence the bug report.
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.
It’s called openBSD :) (don’t get me wrong, openBSD is awesome, but the default install which is secure out of the box is a bit spartan heheh)
Just annoys me that he calls features "crap" just because he likely doesn't use them personally and ends that post with a random sentence claiming such a version "increases the risk of drive-by attacks" with zero evidence. The developer explains the features aren't plugins and aren't even enabled by default. Arrogance from maintainers like this from within Debian is what will hurt it far more than any external entity.
Exactly, this rude and insulting behavior is why many people shy away from open source. Not everybody has the time and mental capacity to engage in ideological battles about software architecture.
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.
> he calls features "crap" just because he likely doesn't use them personally
"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.
You misunderstand, see; these people are corporate saboteurs.
Unfortunately, this kind of culture where you joyfully screw over your real users to chase the approval and benefit of some spherical user in a vacuum that you would like to cater to has become endemic in the free software world. It probably started with GNOME 3 (deliberately strip-mined of functionality, actively hostile to customisability, wasteful of screen space, all for the sake of chasing some HCI-prophesied transition to mobile touch devices which never came for desktop Linux), but was perfected by Mozilla in the name of security.
GNOME highlights most of the worst possible characteristics open source has, especially their last 15 years. Narcissism, opaque decisions, politics, virtue signaling, 4chan obsession, and toxic behavior describe just the past few months of that project. It's high time to cancel GNOME.