Gregory's ServerDebian Users - Be aware the maintainer of the KeePassXC package for Debian has unilaterally decided to remove ALL features from it. You will need to switch to `keepassxc-full` to maintain capabilities once this lands outside of testing/sid.
|
175 comments
 Trying to reduce the size of an iso by fifteen kilobytes?? lol no idea. @RL_Dane @Ray_Of_Sunlight @keepassxc looks to be security related when reading https://packages.debian.org/sid/keepassxc: This package includes only the bare minimal functionality, and no security complications like networking, SSH agent, browser plugin, fdo secret storage. See keepassxc-full if you absolutely need those.  @lieven @RL_Dane @Ray_Of_Sunlight @keepassxc there is a bit more reasoning in the corresponding bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 @j_r @lieven @RL_Dane @Ray_Of_Sunlight that bug report is bunk. He removed ALL features, not just networking. That includes yubikey support, auto-type and browser integration.  @keepassxc @j_r @lieven @RL_Dane @Ray_Of_Sunlight tbf the changelog does say .. "and IPC" .. but that's certainly an 'interesting' choice. I think you could make a strong argument that the missing features reduce more vulnerabilities than they create, and most users will want them. The other-way-around approach of "keepassxc-minimal" v "keepassxc" would have made a lot more sense! @srtcd424 @keepassxc @j_r @lieven @RL_Dane I mean i'm not an expert, i know nothing about this functions, i just like my Offline Password manager 😄 @srtcd424 @keepassxc @j_r @lieven @RL_Dane @Ray_Of_Sunlight remove the features doesn't make much sense. @Ray_Of_Sunlight @srtcd424 @keepassxc @j_r @lieven @RL_Dane because the security argument is valid but not strong enough, and this action create a lot of noise, I'm thinking myself why someone knows whats is better for me ? I always prefer ship packages follow the upstream recommendations, but its just me :) @Ray_Of_Sunlight @r1w1s1 @srtcd424 @keepassxc @j_r @lieven I like flatpak, but prefer to use native packages when I can. Their choice sounds like a dubious one, but as long as there's still a native package with the feature I need, I'll be using that one. @RL_Dane @Ray_Of_Sunlight @r1w1s1 @keepassxc @j_r @lieven I've settled in on flatpaks for "key" or major apps - keepassxc isn't large, but I do consider it important. Allows to me keep on a stable distro and still track up-to-date versions of things. I'm not really a huge fan of the "bundle all dependencies" model, but I've grudgingly accepted that's the world we're in now, and disk is still cheap relative to app sizes even given modern toolkit bloat! @srtcd424 I do like the "bundle with all dependencies", although it makes the package a lil' heavier, it helos not having to download the dependencies on separated servers and who knows when one of them will shut down. Plus, it's cross-distro and it's not like Snaps. @j_r @lieven @RL_Dane @keepassxc That explains everything, Thanks funny-looking puppet guy(No offense intended) 😁 @Ray_Of_Sunlight Read the discussion here: @keepassxc I dont find it so problematic to offer two versions of your program: One minimal one that does the basic job (which is enough for me) and has less attack vectors, and the fully-blown "monster" with all those nifty features. @Zugschlus @keepassxc Keepassxc is not the only package that is split this way. Vim and Nginx are packaged like that too. @keepassxc Though I appreciate having a minimal package, I think naming the packages the other way round would be less confusing to existing users - keepassxc-minimal and keepassxc.   @joel @njoseph @keepassxc Especially since there are now many years of online how-tos, blog posts, Stack Overflow answers, etc. telling Debian users "you can install the complete KeePassXC via the keepassxc package," and none of that material is ever going to be updated to reflect the change. So a lot of people are going to be unwittingly steered into downloading a package that isn't what they think it is. @jalefkowit @joel @njoseph @keepassxc online how-tos for installing a single package? @steko @joel @njoseph @keepassxc You can't imagine someone writing an article along the lines of "How to get started using a password manager" that tells people to install a particular package? @jalefkowit @joel @njoseph @keepassxc there seem to be hundreds of such articles, half of which are AI generated, and none includes the installation instructions for a specific operating system, let alone a Linux distribution. But I have already done too much reply-guying here, apologies. @njoseph @keepassxc I think the safest-possible version should be the default version for a password manager. Maybe an mp3 player or picture editor has other priorities, but a password manager's central purpos of exiting is security, so it should be as safe as possible *by default*, and you have to go out of your way to add convenience and reduce security. The problem of changing an existing default is a thing, but it's not a big enough problem to justify not doing it.  @AlisonW All means no yubikey, auto-type, browser integration, ssh agent, fdo secrets, and networking (favicon download, HIBP).  @keepassxc is this specific to the debian distro or does it affect other distros that use apt?  @pootriarch, it affects Devuan because the package is pulled in directly from Debian without change.  @keepassxc An exceptionally bad decision to wreck a huge existing installation base, "because I can". The rude reply by @juliank is condescending, and far from what I am used to read. https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817  @tuxwise @keepassxc why do you think it's rude and condescending? The first thing Debian users should be looking at when something changes unexpectedly is the /usr/share/doc/<package>/NEWS.Debian.gz That is the way breaking changes are communicated. Users of testing/unstable are expected to have apt-listchanges installed to see them automatically. Stable release users should read the release notes. People annoying upstream isn't something I can solve. I will not repeat your extremely rude vocabulary here, but leave that for interested parties to look up, since it is documented at github. @tuxwise @juliank @keepassxc I don't think so, and many users in the discussion agree. If most users use only a small subset of the functionnality, then the smart secure move is to provide it and make it the default. Now it would be better if Keepassxc showed a message saying that that version is the minimal one, and that a full one is available, but that's not in the hands of the debian maintainer. I was not referring to providing a minimal and a full version, to which the original developer agreed to as well. As you can easily see from actually reading what I wrote, I criticized the rude tone, and the wrecking of the implied contract with those who have installed the existing package. And I stand by that. @tuxwise @RLetot @keepassxc I was just being courteous, signing in on my phone and giving a short reply while travelling. The concern is that somebody leaves or somebody new comes and picks up a subsystem and eventually maintains it on their own because the others don't actually use it and then believe the subsystem expert. That's somewhat normal. This opens the doors for malicious actors to appear and compromise less popular subsystems. 1/2 @tuxwise @RLetot @keepassxc Hence I did not want to expose new users to optional subsystem code by default. This seems a reasonable stance. It is what Debian users generally expect. Sadly I could not do that without breaking some users existing functionality. I can add a debconf dialog on upgrades to tell you more explicitly. I will have to think about how we can solve this better in the future for similar situations (upgraded get X, new gets Y), but this requires new apt features. @tuxwise @RLetot @keepassxc We can also rename the existing package to KeePassXC-minimal and then remove the keepassxc package. Then users will get a message from apt when doing install keepassxc that tells them it's provided by either. But anyway I hope this longer explanation seems less rude to you, I had to sit down in the middle of a city trying to get it out on my phone. There is no point in continuing to discuss with you if you now call your rude tone "courteous" and think that deflecting from that tone by adding more and more reply text will somehow cover up your foul language. You are muted now, don't bother to reply. @tuxwise @keepassxc I know that English is not my language, so maybe I missed something, but where is there foul language from @juliank ??? @tuxwise What in the ever loving F... are you talking about? Please quote @juliank being rude. @tuxwise sorry, but I find your tone a lot more rude and condescending than what I read from @juliank. You want more respect from people ? Maybe start by respecting them yourself. Bye. @keepassxc  @keepassxc Breaking change documented in the NEWS file: "Networking and all plugins have been moved into the keepassxc-full package. Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users." — https://salsa.debian.org/debian/keepassxc/-/blob/main/debian/NEWS?ref_type=heads Does the package create, store, encrypt, and retrieve passwords? Then it still has all the "features" I ever wanted anyway. The removed features should all be plugins anyway, for exactly the reasons implied in the updated package description. All of those extra "features" are also bug surface and attack surface, both of which you want as little as physically possible in a password manager. And that safest-possible version should be the default version. @keepassxc Oh wow! How about: "Debian will ship keepassxc differently starting ...". Your version sounds like you have some beef with that specific debian maintainer and deliberately dog whistling to generate external motivational pressure to reverse that decision. That was not your intention, wasn't it? Unilaterally here appears to actually mean: After notice and discussion, the core app requires attack surface reduction spurred by threat model change. Feature add version available for those with needs/tolerances for riskier surfaces. @tab2space @keepassxc @paul_ipv6 That keepassxc devs themselves don't agree, and think conveniences are more important than security *in a password manager* makes me question the wisdom of using keepassxc as ones keepass client. All the users I can forgive (well, not them either but it's at least expected if still not excusable) but the actual devs of a password manager? @bkw777 @tab2space @paul_ipv6 why would we develop and maintain and personally use a feature we don't trust. Use your noggin, we eat our own dogfood. @keepassxc @tab2space @paul_ipv6 Presenting a non-sequiter like that as an argument places you in a not-great position from which to try to talk about anyone else's failure to use any noggins.    @keepassxc @keepassxc KeePass Users - Be aware the maintainers of KeePassXC have confused KeePass users with LastPass users, and actually object to Debian shipping their PASSWORD MANAGER in safe-mode by default. @keepassxc@fosstodon.org This maintainer sounds like they have the same brain rot that the Suckless devs have. I wouldn't be surprised if they see Suckless software as the "gold standard" for software development.  @keepassxc Are the DEBs distributed via Launchpad PPA (phoerious) also affected by this? @keepassxc this is the funniest thing I saw today, lmao. How is that supposed to even look like?? @keepassxc  @keepassxc Threads lke this are a great resource for identifying people to mute or block.  @keepassxc This maintainer is forcing his preferences onto common users. That's something you should never do as a 3rd party package maintainer. Most common users will end up installing the full package anyway, so this is all just a pointless security theater on his part. Based on his responses to this post/other commenters, he handles criticism quite poorly. P.S. Since he meddled with the software, he should be responsible for fixing any issues that arise with his minimal version.  @keepassxc IMO that packager is clearly in the wrong on all accounts. And even if their argument was technically sound, they'd *still* handle this in the poorest way possible that breaks the most people's expectations. And even if that wasn't the case there would still be them talking shit about you and your users. In short: they are (IMO) not fit to package a piece of software.  @keepassxc ok, but their points are kinda reasonable except for how they are doing it  @keepassxc I think I don't/won't use features from the full variant. Will the smaller variant complain and abort gracefully if I were using now removed features? Or would it bust my KeePassXC database?  @keepassxc Who in the right mind does something that incredibly stupid without the malicious intention of harming the project?  @keepassxc I dislike the wording of your post. You provide a software with option toggles for some functionality and complain that a person decides to use these toggles? @keepassxc Debian is rightfully very proud about its democratic procedures. It should be possible to challenge this very subjective and highly exaggerated decision of a single person. Big question: Where to start the appealing? Maybe some other Maintainers? Maybe debian-policy@debian dot.org? @keepassxc Isn't the "tell if a new version has arrived" feature dependent on this compile flag being "ON" ? -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF) If so, wouldn't that be the worst security liability one can think of? Great e.g. by the way. Favicons would be the least interesting feature to lose at least in my book... |
@keepassxc Wuh- Why??