4 ms·

Looks like pretty reasonable decision to me - network features and browser integrations are huge potential holes / exploit entry points. And without network-rel

• Arnavion 2y ago
  There's one way in which browser integration improves security vs not using it, which is that the browser extension checks the page URL before filling in the credentials, while the approach of manually copy-pasting credentials is vulnerable to typo- and homoglyph-phishing.
  • JeremyNT 2y ago
    This is essential to my own usage of KeepassXC. I never copy/paste from it into a browser and appreciate having this first line defense against phishing.
  • tuetuopay 2y ago
    This. So much this. I don't even understand how browser integrations are not universally thought as a core part of a password manager. With all the phishing that's going along, it's really the last line of defense. Oh and I'm not only talking about elderly relatives and such. Modern phishings are very very well made, and there's one going on to steal Steam accounts that I would have likely fell for (and I consider myself pretty good on the matter).
    • nulld3v 2y ago
      I'm replying just to +1 this as well. This has saved me multiple times not from phishing attacks but from simple mistakes such as entering a password into a HTTP page when the website supports HTTPS. Often I'm just browsing along and try to get KeepassXC to autofill a password only to be frustrated when it refuses to work. Then the frustration turns to relief when I go into KeepassXC and see that I've entered "https://website.com https://website.com" into KeepassXC's URL box causing KeepassXC to only autofill the password on the HTTPS variant of the website and I was on the HTTP variant of the page. Obviously it's best for the website to just setup HSTS, but I can't fix that for them. I previously used auto-type and always thought browser extensions were insecure until I realized this.
      • accoil 2y ago
        It's not like the clipboard is secure either. Any arbitrary app can listen to the clipboard in X11, and while it seems harder in Wayland, I'm not sure if I've ever seen a clipboard permission dialog (my Wayland experience is limited though). Turning off the browser intergation means that the user may accidentally auto-type into the wrong website. Turning off auto-type means that external applications can see the password.
        • Arnavion 2y ago
          With Wayland, the compositor gets to decide which clients to send the "clipboard data available to paste from this file descriptor" event to (wl_data_offer). For example the compositor might only send it to the client whose window is currently focused. So clients that don't receive this event would not have the fd to be able to read from it. Clients that do receive the event can read that data without any restrictions. That said, this ends up also making this like clipboard managers or wl-paste not work, so there is a wlroots protocol (wlr_data_control) that lets the client know about all data offers. How is a malicious process prevented from being a client of this interface (or even should a process be prevented...) depends on the compositor.
          • deleted 2y ago
• pitaj 2y ago
  Using the term crappy made me immediately lose respect for julian-klode.
  • jdbernard 2y ago
    Particularly of features that users depend on. It really leaves the impression that he thinks very little of debian users.
    • kiwijamo 2y ago
      Features that according to your GP was disabled by default. And according to others in this discussion thread, disabled by default in the upstream also.
      • jdbernard 2y ago
        If you read the GitHub discussion these features are usually compiled in but not actually exercised until the user enabled then in the UI. The debian packager has changed the compile-time configuration to disable them at compile-time, making them unavailable to the user in the UI. Regardless of the makefile defaults this be a breaking change. There is a some confusion because the flags that control these features at compile-time do default to OFF if not provided, but the installation instructions in the same documentation also tell you to compile with XC_ALL set to ON. The maintainers themselves talk about all features being enabled at compile-time in the discussion thread and even consider removing these compile-time flags altogether to prevent compiling keepassxc without these features. So "disabled by default" is not really an accurate understanding. It is clear that the intended configuration from the authors is for all features to be compiled in and available. See: https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104508951 https://github.com/keepassxreboot/keepassxc/issues/10725#iss... https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104750715 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
• charles_f 2y ago
  He removed not only networking but support for yubikey, and autotype. These are all features that are turned off by default.
  • Dah00n 2y ago
    They are not "features that are turned off by default" but plugins that are now actually plugins and not built-in features that are turned off. Why on earth would they include plugins that aren't plugged in as a default? How anyone could see a smaller attack surface as a bad thing on HN baffles the mind. Could he have made a -minimal version? Sure, but the default version should be the clean, secure, without plugins version so he did the right thing.
    • fallingsquirrel 2y ago
      Why does everyone keep using this word "plugins"? Quoting the developer: > You fundamentally misunderstand our program when you use the word plugin. These are built in features, not plugins. The features can be enabled as desired by the user and they come disabled by default. This change to not compile and ship these features in the base keepassxc package does nothing besides create angry (or confused) users.
      • deleted 2y ago
        [deleted]
    • zer00eyz 2y ago
      Your conflating PLUG IN technical term with PLUG IN from a users perspective. No one was really friends with tom on myspace.
    • ziddoap 2y ago
      >How anyone could see a smaller attack surface as a bad thing on HN baffles the mind. Because in the real world, with real users, you must balance security and friction. If you have too much friction, users look for workarounds and your theoretical security increase becomes a real world security decrease. For a real world example of this phenomenon, see forced arbitrary password changes (which are now universally discouraged). They are theoretically more secure, but study after study has proven that, in the real world, forced arbitrary password changes reduce organization-wide security. Security requires a holistic approach. Users and their behaviors are part of that. Looking only at attack surface is a sure-fire way to make your users work against your security policies rather than with.
• n3storm 2y ago
  Whouldn't be less surprising to publish full app as keepassxc and the other packages be named as -localonly or -partial or -secured or -local-and-secured ?
• redserk 2y ago
  I'm not sure I really agree here. If there's fundamental concern for the security of a software package, why package the software? What's stopping a malicious actor from including malicious network code outside of the compile flags?
  • josephcsible 2y ago
    The concern here is accidentally vulnerable code, not malicious code.
    • redserk 2y ago
      Intentionally malicious or accidentally vulnerable, vulnerable code is vulnerable code. Disabling compile flags on functionality doesn't necessarily guarantee you're any more secure, especially if the software isn't regularly tested without those flags.
      • theamk 2y ago
        Sure it does. If the software (1) only ever used on trusted data (2) never makes network requests, then even with most vulnerable libraries, it simply cannot be exploited. But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries. (note that in case of local compromise, it does not matter if keepass is secure or not - the attacker can install keylogger, inject code into process or replace it altogether)
        • redserk 2y ago
          > If the software (1) only ever used on trusted data (2) never makes network requests, then even with most vulnerable libraries, it simply cannot be exploited. You're assuming the flags remove all of the whats-deemed-as-risky behavior. Trusting the flags from the lens of wanting to trim down a package size? Reasonable. Trusting the flags from the lens of wanting to boost security? Eh... Crafting a security policy based on compile flags requires a lot of trust towards the developer of the code or spending a lot of time auditing these compile flags. I just don't see the logic in wanting to simultaneously avoid trusting the code while also placing an enormous amount of new trust in the code's post-compile behavior. > But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries. Image support is still built in, though. You're still susceptible to the vulnerable image library. Just because you're now pulling the images by hand doesn't make it any more secure. With these concerns users should be considering some form of sandboxing. Whether it's tossing the package in a network-restricted container, VM, or separate device. This is very close to dogmatic security theater.
• arp242 2y ago
  Lots of things are a huge potential hole and/or exploit entry point. Lots of these things are also useful. And "being useful" can increase security because if password managers are hard to use then people stop using them. And looking at this a bit more, it's not clear to me that using the clipboard is necessarily more secure than the browser integration. Copy/paste accidents alone would offset quite a bit of the security footprint of a browser integration. Many years ago I did some contracting for a fairly large company.[1] The laptops of their account managers had a disk encryption passwords, Windows login password, and AD login password. They all had to be different. They all had to be changed every few months. They all had "must contain at least two capitals, at least 4 non-letter/digits, and at least one 11 digit prime number"-type requirements. Every single laptop I ever saw had a post-it note with all three passwords. Without exception. My point here is: hypothetical security nerd security does not equal actual real-world security. Or at least not always. There are real trade-offs to be made here. [1]: We did some maintenance of the laptops as an external contractor for some of the guys. They weren't really supposed to, but it was tons faster and easier because less bureaucracy, as doing it by their own IT system took forever. It was that type of company. This, on its own, was of course also a "security risk" because random tech guys from a computer store shouldn't really be on their laptops with super-secret company data (I don't think there wasn't that much to protect, other than sales/customer numbers which is only useful for a very select group of people).
  • acters 2y ago
    I fully agree with you. I wish people would stop focusing heavily on how removing features can potentially decrease attacks. Especially when those exact features are used to prevent the WORST possible attack vector, a mishandled or exploited Clipboard. I do not see how else would a user be able to gain access to the passwords without either using the keyboard, or opening the edit dialogue to select "show password" which would just make them plain-text and MUCH easier to attack. These features were introduced to not only offer ease of use, but to facilitate a more secure method of transferring the password to the desired location. These maintainers clearly did NOT think these things through and potentially created a much less secure package than intended.
• worble 2y ago
  > calling your upstream "crappy"[0] is probably not the most productive way for package maintainer to act This is so incredibly rude to post on the github it'd make me reconsider using Debian at all if I did. If the package is so full of "crappy" features why is he even bothering to maintain it? Just get rid of it and let users figure out how to install it properly themselves. I feel bad for KeepassXC devs, maintaining an open source project is hard enough without having to deal with crap like this.
  • NikkiA 2y ago
    TBF he's a canonical employee, not a debian employee, he's paid to maintain Ubuntu packages, but volunteers for the debian ones, so I'd be more side-eyeing Ubuntu first. But then I gave up on debian a while ago because of some of their more questionable decisions.
    • pquki4 2y ago
      Interesting, what are some examples of questionable decisions?
• strken 2y ago
  I agree that network features and browser integrations are huge potential holes, but the contributors on the GitHub issue make a very good point when they say that there's minimal testing of the stripped-down build in comparison with the full build, and no testing at all of random combinations of build flags. As noted elsewhere, one of the "optional" flags that got disabled is yubikey support, without which users are getting locked out of their password manager when they upgrade to the new, broken package. Enabling just that flag puts the project in a state which nobody is actually testing. I agree that calling the package keepassxc-lite would have prevented this issue, assuming existing users were moved to keepassxc-full, but that's the entire problem here! It's a reasonable choice to default to the most secure solution (not that hypothetical attack surface is a real vulnerability), but as a maintainer you shouldn't break existing functionality unless either upstream or your users want you to, and you particularly shouldn't lock users out of their password manager.
  • kasabali 2y ago
    > make a very good point when they say that there's minimal testing of the stripped-down build in comparison with the full build, So they should be thankful their software will have better test coverage thanks to Debian users
• mikl 2y ago
  Whether his changes are good or not, it’s still pretty crazy to essentially fork an open source project, but publish your very different version under the same name.
  • iso8859-1 2y ago
    Why does setting build flags constitute a fork?
• bdd8f1df777b 2y ago
  I see this kind of mindset often--if we remove the features useful but not perfectly secure from users, we can protect them from such insecurity. But this mindset is wrong. What happens instead is that users will fulfill their needs in even more insecure ways.
  • kasabali 2y ago
    Which more insecure ways? At worst they can install the keepassxc-full package and back to exactly where they were. This isn't tyranny, maintainer has provided a choice.
• globular-toast 2y ago
  Indeed. I use Gentoo and one of the best things is being able to easily switch off features in individual packages like this (or across the whole system, like systemd or X11, for example). But what can a Debian user do? If they're going to build one binary and make it the default it should be the most secure version, not the most featureful. The keepassxc account is being ridiculously sensationalist. Removing ALL features? Lol