[HN Gopher] KeePassXC Debian maintainer has removed all network ...
___________________________________________________________________
KeePassXC Debian maintainer has removed all network features
Author : CuriousIndian
Score : 285 points
Date : 2024-05-10 15:29 UTC (1 days ago)
(HTM) web link (fosstodon.org)
(TXT) w3m dump (fosstodon.org)
| PlutoIsAPlanet wrote:
| IMHO is a downstream maintainer is going to change a package in a
| way that doesn't have the intent of the upstream project, it
| should be published under a different name and that maintainer
| deal with all bug reports caused by their modified version.
| bananapub wrote:
| not sure why you're commenting without even reading the linked
| 200 character post?
|
| the maintainer has enabled all plugins (including network
| stuff) in the _keepassxc-full_ package, the _keepassxc_ package
| will be just the basics with a much better security posture.
|
| that's obviously completely fine and completely within the
| remit of a maintainer, the entire complaint is about _this
| being a change_.
| milliams wrote:
| As stated in the GitHub thread [1]: 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.
|
| [1] https://github.com/keepassxreboot/keepassxc/issues/10725#
| iss...
| bananapub wrote:
| that seems completely irrelevant?
|
| plugin, compile time ./configure flag, whatever - package
| maintainers extremely routinely create multiple versions of
| a package for various reasons, from security (this case) to
| dependencies (Debian contains a _emacs-nox_ package that is
| emacs compiled without X libraries to avoid dragging them
| in on servers, for example) to license reasons.
|
| again, all of the complaints are literally about the
| change, which the maintainer has decided to do in a
| disruptive fashion.
| arp242 wrote:
| That Canonical guy is not coming off brilliantly there. I
| appreciate that reasonable people can disagree on the best
| way to package this, but these kind of strong absolute
| statements - together with calling useful features
| "misguided" and "crap" - is not great, to put it mildly.
|
| I'm pretty sure some compromise could theoretically be
| reached here. But not with that attitude. "It is our
| responsibility to our users to provide them the most secure
| option possible as the default"? You know what would be
| even more secure? To disable all networking in any program,
| and in fact, in Linux itself. Actually, it's even more
| secure to just not give people a computer at all. This is
| one of those stupid discussion-stoppers.
|
| These kind of _Highly Opinionated Maintainers(tm)_ has
| always been what put me off from Debian (and by extension,
| Ubuntu). I want to use KeePassXC, not "KeePassXC as some
| random guy thinks it should have been".
| trallnag wrote:
| What's the alternative to Debian / Ubuntu now that CentOS
| is gone?
| lawn wrote:
| Arch Linux and Void Linux are both worth a look I'd say.
| TheBicPen wrote:
| I believe the zoomer response to this is "bruh"
| yjftsjthsd-h wrote:
| Rolling-release distros are unlikely to fit into the same
| usecase as a slow-moving stable-release distro.
| arp242 wrote:
| AlmaLinux and Rocky Linux are continuations of CentOS; I
| have no experience with either but that would be the
| logical place to start.
| TheBicPen wrote:
| Fedora
| yjftsjthsd-h wrote:
| It really depends on your usecase; I'm personally fond of
| OpenSUSE and Alpine Linux. OpenSUSE is more
| "conventional" like Debian/RHEL, and Alpine is a touch
| idiosyncratic (mostly, musl as its libc means 3rd-party
| binaries often won't work) but is tiny ant fantastic when
| it does work for your usecase.
| jdbernard wrote:
| The problem is that this will break all existing users who
| use those features when they update. One of the comments in
| the GitHub thread has a better path, IMHO: ship two new
| packages, a -minimal and a -full, and the user to choose,
| rather than silently break functionality (NEWS is fine, but
| not really read by user as everyone admits).
| JohnTHaller wrote:
| The default package should be named keepassxc-debian-limited
| or similar and the proper package should be keepassxc
| bananapub wrote:
| OK? that has nothing to do with what I was correcting:
|
| > IMHO is a downstream maintainer is going to change a
| package in a way that doesn't have the intent of the
| upstream project, it should be published under a different
| name and that maintainer deal with all bug reports caused
| by their modified version.
|
| the downstream maintainer didn't "change a package in a way
| that doesn't have the intent of the upstream project", they
| altered the config flags in one package and made another
| with the previous flags. the maintainer is being a dick,
| but not in the way the OP suggested.
| Dylan16807 wrote:
| > the downstream maintainer didn't "change a package in a
| way that doesn't have the intent of the upstream
| project", they altered the config flags in one package
| and made another with the previous flags.
|
| They altered the config flags in a way that doesn't have
| the intent of the upstream project. And I would classify
| build config changes as a subset of "changing a package".
| Dah00n wrote:
| Use JohnTHallerNix and it can be. Debian is again taking
| care of their users. Unlike upstream, Which isn't new. Did
| he do it in the best way? No. Did he do the right thing?
| Absolutely.
| hi-v-rocknroll wrote:
| It's the tyranny inherent to dependency-hell monolithic
| package management. nix avoids this problem by permitting
| multiple versions and flexible configurations of the same
| package.
| nulld3v wrote:
| But that's not what they disagree with. They are saying you
| shouldn't have a package called "keepassxc" if it is missing
| a ton of features from upstream KeepassXC. You should name it
| something different instead.
|
| So you shouldn't have "keepassxc" and "keepassxc-full".
| Instead you should have "keepassxc" and "keepassxc-minimal".
| vlovich123 wrote:
| But it's a valid build configuration option provided by
| upstream. Not sure I follow this line of reasoning.
| nulld3v wrote:
| Sure, I think that's a reasonable stance. If upstream
| agrees that such a configuration is a valid distribution
| of KeepassXC and can be branded KeepassXC, then that's up
| to them. I would probably disagree with upstream in that
| scenario just from a UX perspective, but I would
| understand both sides.
|
| But in this case, upstream has responded and clearly
| indicated that they do not want the minimal distribution
| of KeepassXC to be branded as the main "keepassxc"
| package: https://github.com/keepassxreboot/keepassxc/issu
| es/10725#iss...
| WesolyKubeczek wrote:
| Because I run and upgrade and suddenly all my shit stops
| working without warning, that's why. It's not how things
| should be done.
| donio wrote:
| The WITH_XC_NETWORKING build option is off by default so the
| developers have obviously intended this to be a valid build
| configuration.
| fallingsquirrel wrote:
| Sure, but that doesn't change the fact that a point release
| suddenly broke everyone's workflows and is causing
| maintenance headaches. I don't think the technical minutia of
| how exactly things were broken is the issue.
|
| If Debian shipped a Linux kernel point release that disabled
| networking I think people would be similarly upset, even
| though it's also just a build option and intended to be a
| valid build configuration (and would even more secure!)
| Dah00n wrote:
| >If Debian shipped a Linux kernel point release that
| disabled networking
|
| That is not comparable. "If Debian shipped a Linux kernel
| point release that removed a risky networking plugin and
| some disabled-by-default plugins and made a -full version"
| that would be comparable.
| MatthiasPortzel wrote:
| It's exactly comparable. The browser-autofill
| functionality in KeyPassXC is not a plug-in and it's not
| risky. The person saying that is the Debian maintainer.
| nulld3v wrote:
| Hmm, excluding the comment about the missing "-full"
| version, I don't see how it is not comparable. There is
| nothing that makes the networking code in KeepassXC more
| "risky" compared to the networking code in Linux.
| kasabali wrote:
| > that doesn't change the fact that a point release
| suddenly broke everyone's workflows
|
| BS. This change was in Debian sid/testing. That's what it's
| for. Debian stable users' workflow hasn't been broken.
| JohnTHaller wrote:
| Either that or it should indicate to the end user that it's an
| unsupported package. Maybe showing up as KeePassXC-Debian or
| KeePassXC-Unsupported and have the developer's contact details
| (website etc) removed from About and replaced with the Debian
| details for support.
|
| A downstream maintainer making small changes to fit within the
| OS that doesn't meaningfully affect the app is fine. A
| downstream maintainer modifying an app and removing core
| functionality so the upstream dev gets a ton of grief is not.
| yencabulator wrote:
| The _default_ build is networking OFF. Same for Yubikey,
| browser integration, etc.
| -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support
| (e.g., favicon downloading) (default: OFF)
|
| https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
| yjftsjthsd-h wrote:
| > and that maintainer deal with all bug reports caused by their
| modified version.
|
| I appreciate that it often doesn't happen, but that's
| _supposed_ to be the default flow regardless: If you 're using
| a distro-provided package and hit a bug, you're supposed to
| open a bug report against the distro package, and then the
| maintainer looks at it, and _if_ the bug came from upstream
| then they file a bug with the upstream project. This is helpful
| because 1. the package maintainer is probably familiar with the
| package and can provide initial triage /analysis, possibly even
| being able to fix the bug outright before going upstream to
| share the fix, and 2. as you note, distro packages frequently
| carry some amount of patching and the maintainer should verify
| whether the bug is in their packaging or the upstream source
| code.
|
| Unfortunately, many users default to reporting upstream first:(
| So in practice this is a concern, but it's really not supposed
| to be.
| HieronymusBosch wrote:
| For folks interested this issue on GitHub seems to have the
| latest comments.
|
| https://github.com/keepassxreboot/keepassxc/issues/10725
| okl wrote:
| Debian maintainer, Julian Klode, has a "pointed" opinion:
|
| > I'm afraid that's not going to happen. It was a mistake to
| ship with all plugins built by default. This will be painful
| for a year as users annoyingly do not read the NEWS files they
| should be reading but there's little that can be done about
| that.
|
| > It is our responsibility to our users to provide them the
| most secure option possible as the default. All of these
| features are superfluous and do not really belong in a local
| password database manager, these developments are all utterly
| misguided.
|
| > Users who need this crap can install the crappy version but
| obviously this increases the risk of drive-by contributor
| attacks.
| lupusreal wrote:
| Quite based. I didn't realize KeePassXC had network features
| but now I want his build. Sounds like a good maintainer with
| (un)common sense.
| nulld3v wrote:
| They removed other non-networking features too. E.g. even
| autotype was removed. At that point why not just store your
| passwords in an encrypted notes app?
| zikduruqe wrote:
| Just use https://www.passwordstore.org
| lupusreal wrote:
| I use KeePassXC, but not any network features or
| autotyping, because I like the password generation and
| because the interface is nice. I previously used Vim's
| old encryption feature (since removed I think?) and I
| think KeePassXC as I use it is a good upgrade from that.
| jdbernard wrote:
| Or maybe just fork the project instead and let users who
| want these features use the package the way the authors
| intended.
|
| There are multiple KeePass implementations. The people
| using this one are doing so because they want its features.
| tetha wrote:
| > I'm afraid that's not going to happen. It was a mistake to
| ship with all plugins built by default. This will be painful
| for a year as users annoyingly do not read the NEWS files
| they should be reading but there's little that can be done
| about that.
|
| I deal with enough packages in my life that do massively
| breaking changes in point releases though, to be honest. This
| is reminding me of the good days that `apt upgrade` would
| uninstall the X-Server because nvidia fucked up their stuff.
|
| Debian is kinda one of the places I expected to be better,
| and usually it does. (EDIT - And I guess the fact that this
| is causing a ruckus in testing is an indication of that. lets
| see how it develops.)
| Arnavion wrote:
| You don't have to proactively read it. But when you notice
| your keepassxc doesn't work as it used to before, that
| should be a trigger for you to go back and read it, note
| that it tells you very clearly that the functionality
| you're missing is now in keepassxc-full, apt-install it,
| and go on with your life.
| paulryanrogers wrote:
| One doesn't expect such a drastic ... 'fix' in a point
| release though.
| kasabali wrote:
| You're talking as if it's a point release of Debian. It
| is not. It happened in sid/testing, that's what these
| releases are for.
|
| Whether it happened in a point or major release of
| Keepassxc is irrelevant, because ignorant users who
| upgrade their sid/testing installations blindly as if it
| was stable-security would have hit it eventually.
| paulryanrogers wrote:
| IMO insisting on a change like this would require
| retiring the original, un-suffixed name. And making
| separate -min and -full packages instead.
| ATMLOTTOBEER wrote:
| I laughed when I saw this. I once tried to be a hit and run
| contributor to a project he maintains and I found him to be
| rude. He is still at it it seems.
| Gerlo wrote:
| My favorite part is that this guy works at Canonical.
| kasabali wrote:
| Yes, had he been a Fedora maintainer working at Red Hat
| everyone would be applauding him for his bold decision.
| twic wrote:
| That is an absolutely mental stance - effective asserting
| that he knows better than both the developers and users of a
| piece of software what features it should have! Promote this
| man to the Debian technical committee immediately, he's
| perfect.
| derkades wrote:
| Good discussion here:
| https://github.com/keepassxreboot/keepassxc/issues/10725
| theamk wrote:
| Looks like pretty reasonable decision to me - network features
| and browser integrations are huge potential holes / exploit entry
| points. And without network-related features and only running the
| trusted databases, the tool should be impossible to exploit even
| if exploits are found, which is a very desirable trait for
| something as important as password manager. Even original
| maintainer agrees [1].
|
| Remember, the full network-enabled package is present in debian
| as well - so all the network features are "apt install keepassxc-
| full" away, for users that want it.
|
| Two minor comments: calling your upstream "crappy"[0] is probably
| not the most productive way for package maintainer to act. Also,
| I am not sure if the package names (keepassxc vs keepassxc-full)
| are best for Debian users - something like keepassxc-lite and
| keepassxc-full might be more informative.
|
| [0]
| https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
|
| [1]
| https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
| Arnavion wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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" 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 wrote:
| 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 wrote:
| 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.
| pitaj wrote:
| Using the term crappy made me immediately lose respect for
| julian-klode.
| jdbernard wrote:
| Particularly of features that users depend on. It really
| leaves the impression that he thinks very little of debian
| users.
| kiwijamo wrote:
| 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 wrote:
| 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/1
| 0725#iss... https://github.com/keepassxreboot/keepassxc/i
| ssues/10725#iss...
| charles_f wrote:
| He removed not only networking but support for yubikey, and
| autotype.
|
| These are all features that are _turned off_ by default.
| Dah00n wrote:
| 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 wrote:
| 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.
| zer00eyz wrote:
| Your conflating PLUG IN technical term with PLUG IN from a
| users perspective.
|
| No one was really friends with tom on myspace.
| ziddoap wrote:
| > _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.
| arp242 wrote:
| > How anyone could see a smaller attack surface as a bad
| thing on HN baffles the mind.
|
| Because if it removes features many (perhaps even most)
| people use then that makes it less useful. And potentially
| insecure as people will stop using KeePassXC and replace it
| with "passw0rd123", because "I really need to get this done
| now, and not fuck about with KeePassXC not working". Is
| there even a message? Or any indication in the UI what's
| going on? I don't think there is.
|
| Here's what should have happened if you really think that
| "keepassxc" package should install a minimal version:
| contact maintainers of KeePassXC, discuss best way to do
| this, maybe allow them some time to create better UX on
| this. Maybe create a PR or two. And _then_ change your
| package. That Debian bug was 4 years old - it could have
| waited a month or two more.
|
| You're also far too hung up on the word "plugin". That word
| has tons of meanings, and the original meaning of
| "something optional I can add (plug in) later on" doesn't
| really apply here.
| uriah wrote:
| Compile-time flags are by definition not plugins. All
| optional features were removed indiscriminately.
| abdullahkhalids wrote:
| Can someone make a security related case for disabling
| autotype?
| charles_f wrote:
| Yeah that makes no sense, if anything I'd keep autotype and
| prevent copy password
| NikkiA wrote:
| "If hit by mistake it might autotype in a window that is
| not at a login prompt, but maybe on a chat session and
| broadcast the user's password"
|
| It's horseshit, but it's an argument
|
| lets see what it does here...
|
| NikkiA
|
| edit: well, I guess it didn't broadcast the password, but
| it probably would have done on a real chat window that
| accepted multiple lines of input
| abdullahkhalids wrote:
| That's actually reasonable. I use keepassxc, and I have
| messed the autotype many times. But I mean, that is not
| an argument for disabling the feature.
| rendaw wrote:
| I'd assume it would only put the password in a
| type="password" input, not a random text box.
| charles_f wrote:
| No, autotype does what it says, it simulates typing keys
| without looking at the screen
| bananenpubs wrote:
| > and autotype
|
| I would go crazy w/o autotype. The way the IT dorks were
| forced by management to set up 'SSO' via an external provider
| at work, you have to enter the same information at least 3
| times a day. 'SSO' for management means 'sign into each of
| our tools each single day'. Muh, no work done equals better
| security!
| dabacaba wrote:
| Usually SSO means that you have to login just once to
| access all of your accounts. If it requires you to login
| multiple times a day then something is not configured
| correctly.
| VonGallifrey wrote:
| Well... at my current employer, we have 3 "SSO"
| providers.
|
| By that, I mean three different Okta logins, and logging
| in to any of them will log you out of the other two. If I
| want to do anything, it means I need to log in again
| because it is unlikely that I am logged in to the right
| account.
|
| Yes, I need all 3 multiple times daily. There is no logic
| about which one I need for which system.
|
| IT knows this is not how it is supposed to be, but they
| assure us that this is a temporary situation. I guess 1.5
| Years is still temporary.
| dabacaba wrote:
| If you can use Firefox, it allows you to create multiple
| "containers", each with its own set of cookies and other
| state. You can create a separate container for each Okta
| login, then you can be logged into all three accounts
| simultaneously.
|
| Also you can create a separate browser profile for each
| account. This works with all browsers but is less
| convenient, because it forces you to have a separate
| browser window for each profile, and also you need to
| enter all preferences for each profile separately.
| unethical_ban wrote:
| I'm in info sec and I agree with you. cyberArk weekly
| password rotation, no ability to save passwords in Edge, no
| ability to install a password manager.
|
| Guess who keeps their password saved in notepad, all but
| three characters?
| kiwijamo wrote:
| If it's turned off by default, then please explain the drama.
| This simple statement makes this drama look like a storm in
| the proverbial teacup.
| skjoldr wrote:
| If I have both enabled in my install, which I specifically
| chose to, then upgrading the package locks me out of my
| database, because those features are not compiled.
| kasabali wrote:
| Jeez, then you simply install the keepassxc-full package
| and move on. It's not like you store your sudo password
| in keepass database, too.
| Snetry wrote:
| but that is part of the problem: this isn't clearly
| communicated to the end user in the future or present.
|
| Current users will have their install broken and need to
| google to figure out what is going on.
|
| Future users will install `keepassxc` thinking it would
| be actually KeePassXC before potentially realizing its a
| minimal version.
|
| Personally I think splitting it into `keepassxc-full` and
| `keepassc-minimal` would be better since it moves the
| choice to the user instead of implying the contents.
| hoffs wrote:
| How would you know in the first place
| n3storm wrote:
| 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 wrote:
| 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 wrote:
| The concern here is accidentally vulnerable code, not
| malicious code.
| redserk wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| theamk wrote:
| I am not worried about xz-style intentional backdoors.
|
| I am worried about unintentional bugs which end up being
| remotely exploitable.
|
| So while making sure the image library is bug-free is
| practically impossible, it is pretty easy to check for
| compile-time feature flags. Build it once, then ldd to
| make sure the http library is not linked. Or check debug
| messages. Or objdump and make sure method is missing.
| Tons of very simple methods.
|
| From this standpoint, disabling favicon fetching is a
| 100% effective mitigation for all remote attacks. I've
| never bothered uploading favicons by hand, and I've never
| needed any images in my notes.
|
| No security theater, just a pragmatic view.
| redserk wrote:
| Yet how many people are checking what libraries are being
| linked on every compilation?
|
| CMakefiles are susceptible to bugs too. KeepassXC could
| also very well remove these build flags and people would
| be none the wiser.
|
| As I said, concerned users should look at other ways to
| isolate the application's behavior here instead of
| relying on the build process.
|
| Run it in an isolated network namespace if network
| connectivity is the prevailing concern.
| arp242 wrote:
| 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).
| worble wrote:
| > 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 wrote:
| 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 wrote:
| Interesting, what are some examples of questionable
| decisions?
| strken wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| Why does setting build flags constitute a fork?
| bdd8f1df777b wrote:
| 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.
| globular-toast wrote:
| 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
| chomp wrote:
| Seems like a positive change to me.
| brnt wrote:
| They disabled all plugins, not just those that may access
| networks.
|
| This is not good, it's nonsensical.
| Brian_K_White wrote:
| Thinking browser or other local integration is not as
| dangerous as network features is nonsensical.
|
| All of the disabled features are expendable. I never used any
| even while they were in there. Yet I do use keepassxc all day
| every day for the one job it actually does exist to do.
|
| Convenience and necessity are two different things. You
| _want_ conveninece, and you 're not wrong to want it, but you
| don't _need_ it, and your _want_ of convenience is not
| important enough to make the base utility _when it is a
| password manager and not a gif editor_ less safe than it
| could be by default. It is correct that if you want to trade
| away safety for convenience, that you have to go out of your
| way to add that yourself, even if most people will choose to
| do that, and even if the previous default was backwards and
| it 's now ever so slightly disruptive to correct that error
| now.
| timw4mail wrote:
| Absolute security means you can't do _anything_. Too much
| security friction can easily lead to *much more insecure*
| workarounds.
| Brian_K_White wrote:
| Somehow, I have been using the same app without any of
| those features. So, the idea that the app is not
| functional or useful without them is bullshit.
|
| As for friction leading indirectly to less security
| through user behavior... how many clicks and how many
| seconds is it to install the full version? So, yet more
| bullshit.
| Phelinofist wrote:
| > Convenience and necessity are two different things. You
| want conveninece, and you're not wrong to want it, but
| you don't need it, and your want...
|
| > Somehow, I have been using the same app without any of
| those features. So, the idea that the app is not
| functional or useful without them is bullshit.
|
| Different people might have different needs and wants and
| other criteria to consider it functional? I think this is
| not up for you to decide.
| Dylan16807 wrote:
| > Somehow, I have been using the same app without any of
| those features.
|
| And are you putting your passwords on the clipboard in a
| way that doesn't verify domain names?
|
| Congratulations, you're using insecure methods. Not
| bullshit.
| valicord wrote:
| Removing browser integration and auto-type doesn't increase
| security, it reduces it by exposing users to clipboard
| sniffing attacks and phishing websites.
| jeroenhd wrote:
| Browser integration, if done well, is actually more secure
| than the copy+pasting you end up doing otherwise. Storing
| passwords in the clipboard is a massive security risk, as
| the clipboard is shared by all applications and websites,
| while direct browser integrations allow for only providing
| the credentials to the specific web page they're meant for.
|
| While I'm not opposed to differentiating between a -full
| and a -minimal version, calling every plugin dangerous by
| default doesn't make sense.
| cyanydeez wrote:
| >if done well
|
| Is that xkcd of a tiny project doing a lot of heavy
| lifting.
| alyandon wrote:
| Gutting the functionality that upstream has built into a piece of
| software and then publishing it under the same name is dubious at
| best. If they want to go this direction they should publish as a
| fork under a different name so upstream doesn't get constantly
| barraged by complaints of users having issues.
|
| This reminds me of the time years ago when the Debian maintainer
| of Chromium decided to unilaterally disable the ability to
| install extensions. Thankfully, more pragmatic minded people
| prevailed and the patch was reverted.
|
| This also reminds me of a time many many many years ago when
| Debian removed the kernel interface that provided the ability to
| load binary firmware into network cards and broke networking for
| me.
| Dah00n wrote:
| They didn't "gut what upstream built". He published it _without
| plugins_ and made a -full version that include plugins. If
| plugins are plugged in as default it isn 't a plugin but a
| built-in feature. This is the correct way.
| tdb7893 wrote:
| Default plugins is a very common pattern and often what users
| want. There can be technical reasons but also for common
| features it's way to have them as opt-out instead of 99% of
| people needing to opt-in to the same stuff
| bananenpubs wrote:
| He published it w/o core package functionality. There are no
| plugins with KXC, that is one of their main arguments: don't
| rely on 3rd party code, bring it all inhouse, where it can be
| checked / maintained.
| TehCorwiz wrote:
| They're not "plugins". They're compiled in features. The
| Debian maintainer changed one compile flag and turned off
| these feature which are disabled by default in the UI anyway.
| And changing the compile flag didn't remove the options that
| enable the features from the UI. So, users are very confused
| why the features they're trying to use don't work. Further,
| what happens to existing users who had these features enabled
| and relied on them?
|
| EDIT: link to a KeeppassXC maintainer explaining that they're
| not plugins: https://github.com/keepassxreboot/keepassxc/issu
| es/10725#iss...
| NewJazz wrote:
| Isn't this something that Debian can do during upgrades,
| though?
|
| Like sure there is breakage, if you don't read the news
| before upgrading major versions.
| password4321 wrote:
| > _changing the compile flag didn 't remove the options
| that enable the features from the UI_
|
| Hopefully this will get fixed
| dannyw wrote:
| The role of a maintainer is more than copying and pasting
| upstream. They are allowed to exercise their judgement in what
| they believe is appropriate for end users of a distribution.
|
| In this case, there does seem to be reasonable security
| justifications for it, and an alternative is provided.
| winternewt wrote:
| You can do all that and still honor the points of the parent
| comment though. I agree that it's poor etiquette to make
| intrusive changes and hold the original author accountable
| for them.
| thaumaturgy wrote:
| If both upstream and a significant portion of users strongly
| disagree with a maintainer's judgement, then how is their
| role as maintainer justified?
|
| It's KeePassXC's job to secure the software and produce
| features that fulfill users' needs as they see fit. Julian's
| role as maintainer may intersect with that _to a limited
| extent_ , in deciding on what kind of defaults best fit the
| rest of the OS. But, in this case, the developers of the
| software disagree with his justifications, and reasonable
| users are also disagreeing with the change.
|
| It seems clear Julian wandered outside his role a bit here.
| cjk2 wrote:
| I think you'd have to actually ask the users about that.
| Not make assumptions based on some loud people on a
| Mastodon thread. What the user is given here is a choice.
| worble wrote:
| Well no, what the user is actually being given is a
| completely different application than the original one
| they downloaded, which is now increasing the maintenance
| burden upstream because THEY are they one getting all the
| bug reports because Debian decided to swap the packages
| out from underneath their users:
|
| https://github.com/keepassxreboot/keepassxc/issues/10725#
| iss...
|
| > This is now our fourth bug report because of the
| decision to neuter the base KeePassXC package in Debian
| cjk2 wrote:
| It's not completely different. They patched stuff out.
|
| And I, as an end user, am absolutely fine with that, as a
| user of vim-nox package etc etc...
| alyandon wrote:
| vim-nox is pretty much full-featured vim without x11
| stuff.
|
| Do you have a non-trivial .vimrc/.vim directory?
|
| Would you be accepting of the maintainer disabling a
| bunch of features and pushing those changes out under the
| main vim-nox package such that it breaks your existing
| install? Would it be reasonable to expect you as the end
| user to figure out what has happened and that you need to
| uninstall vim-nox and and install vim-nox-full?
| cjk2 wrote:
| My .vimrc is 8 lines. I learned not take the kitchen sink
| with me on holiday.
| riedel wrote:
| I thought from reading the bug report is that they only
| changed the default of a supported cmake build flag. I
| think that a keepass-nonet would have be a wiser choice,
| but I do not blame Debian people to be opinionated
| towards the more secure choice.
| yjftsjthsd-h wrote:
| But vim-nox is a separate package with a clear name
| saying that it's got X removed; I don't think this would
| be nearly as controversial if they'd shipped a keepassxc-
| nonetwork package.
| joeyh wrote:
| vim-tiny is installed by _default_ on debian (providing a
| vim command), and also has X removed.
| yjftsjthsd-h wrote:
| Okay? Calling it keepassxc-tiny would also be fine. I
| think it's relevant that `apt install vim` does _not_
| give you vim-tiny.
| naniwaduni wrote:
| Yeah, I hated that too.
| Arnavion wrote:
| Users should ideally report bugs to their distribution,
| not to upstream. The distribution package maintainer then
| does triage to determine if the issue is specific to the
| distribution package or should be forwarded upstream.
|
| That's how it used to be in the past (and still is for
| enterprise distros because you might as well use the
| support contract you paid for). But lately users have
| gotten more savvy about talking to upstream directly,
| especially since more and more upstreams are now on easy-
| to-use websites like GitHub instead of mailing lists.
| That's still fine if users do their own diligence to
| ensure the issue is with upstream and not with the
| distribution package, but alas they don't all do that,
| leading to these spurious reports.
| cqqxo4zV46cp wrote:
| What's your point? We all know why it's happening. The
| reality is that it's not to user expectations, which is
| bad.
| petee wrote:
| But they already had a choice, since the removed options
| were disabled by default.
|
| This really just breaks core functionality that exists
| and is expected by real users, under the guise of unnamed
| security risks...theres plenty of disabled options in
| Linux that are "potential" risks, so its a silly choice.
| cjk2 wrote:
| Hyperbole!
|
| $ apt install keepassx
|
| $ apt install keepassx-full
|
| Choice made.
| petee wrote:
| Choice was already made when they installed it with xyz
| features available.
|
| If it was so important they never should have packaged it
| in the first place. -Minimal option is the obvious
| reasonable choice, unless trying to be an arse to make a
| point, since you're changing a users choice _after the
| fact._
|
| Are we going to stop compiling sshd with plaintext pw
| options and root login, and suddenly?
|
| If a user has an option enabled you don't like anymore,
| notify them, don't blindly remove functionality and say
| "your fault for not reading the changelogs".
|
| Frankly the security claims ring more of hyperbole than
| anything
| kasabali wrote:
| > If a user has an option enabled you don't like anymore,
| notify them, don't blindly remove functionality and say
| "your fault for not reading the changelogs".
|
| apt shows the NEWS file during update when there's a
| change. These users not only have chosen to actively
| ignore the warning that has been shown to them by
| default, they've also chosen to directly go to upstream
| to complain instead of first their distributions
| channels.
| jdbernard wrote:
| Let's say that I had the previous version of keepassxc
| installed and used a Yubikey to protect it. Now when the
| distro updates, through no actions of my own, I will be
| locked out of my password DB because the Yubikey
| extension is no longer compiled in to the version of
| KeePassXC the distro is shipping under the original name.
| Yes, this breaks core functionality. How is this a good
| thing?
| thaumaturgy wrote:
| Users should be asked if they actually wanted the
| features in the existing package after all? Why shouldn't
| users have been asked _before_ changing the existing
| package?
|
| I'm one of those users. If I'm loud, does that mean my
| opinion doesn't count anymore?
| pessimizer wrote:
| It never counted. You can suggest or advise, but you
| never had the power to tell Debian what to do. Being loud
| will not change that, no. You'll have to resort to
| persuasion.
| kasabali wrote:
| > Why shouldn't users have been asked before changing the
| existing package?
|
| They were. _apt_ shows the NEWS file during update when
| there 's a change.
| barbariangrunge wrote:
| Sorry, why do maintainers owe us anything? They're
| typically unpaid or poorly paid and are doing everyone a
| favour. The code is open source and anyone who doesn't like
| their work can easily fork the project. They don't need to
| justify anything to us
| Kwpolska wrote:
| This isn't the project maintainer we're talking about,
| it's the Debian package maintainer. Their job is building
| a working .deb with working software, not randomly
| messing with it. Users have the right to demand their
| packages to be trustworthy.
| g1sm wrote:
| He wasn't randomly messing with it, there was a bug
| report about this:
|
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
| Kwpolska wrote:
| Doing it in response to a single user's bug report from
| 2020 that does not provide any rationale other than
| "network access bad" constitutes randomly messing with
| packages.
| WorldMaker wrote:
| You doubt that bug poster's "belief" that "most people
| want" that change?
| whoopdedo wrote:
| The feature flag is put there by upstream. If they don't
| want to support non-network installs then why do they
| even have that lever?
|
| That said it probably makes more sense for Debian to
| package a `keepassxc-nonet` alongside the default
| `keepassxc` so end users can choose the variant.
| Kwpolska wrote:
| If a user wants to build a hardened copy, they are free
| to do that. Distros should provide a version with
| standard features that are expected by end users.
| int_19h wrote:
| This kind of thing is one of the reasons why we have
| different distros. For Debian, it's actually common to
| provide a "minimal" package plus one or more versions
| built with different feature flags.
| netsharc wrote:
| I agree, it's also supremely obnoxious that upgrading a
| piece of software means losing a lot of functionality -
| unless the user knows s/he needs to replace the package
| with the -full version..
|
| Wahey, isn't that what MS does with e.g. Outlook.
| Congrats Debian, you're reaching Microsoft's level!
| kiwijamo wrote:
| I agree that is unfortunate however I would argue the
| package should have been built that way in the first
| place. It's not the best thing to do now but better late
| than never. I wonder if the Debian maintainer would
| consider some sort of transactional package which brings
| in the new package if you had the original one installed.
| However, as someone who has used Keepass and did not
| realise it had all these extra functionalities, I think
| the assessment that most users will see no difference is
| ultimately closer to the truth than many people realise.
| I migrated away from Keepass specifically because I
| thought it had no network functions which makes all this
| drama especially ironic for a software that was marketed
| (at the time) as a password manager to keep on your own
| device and not someone else's machine.
| kiwijamo wrote:
| As a Debian user I like how Debian just includes the
| basics in the main package and provides optional extras
| if you want them. I'm not sure how other distros handle
| it the other way around -- if the main package includes
| everything the risk is naive users install packages that
| include functions they don't need that end up exposing
| security issues. The Debian approach provides a reduced
| attack surface out of the box and if I happen to need
| something more its easy to just apt search
| ${package_name} and see what other extensions are
| available and install these. I do this regularly for PHP
| modules for instance if some PHP code complains a certain
| module is not available. It may not be your cup of tea
| but this is the Debian approach, and it makes sense from
| the perspective of a defensive user like me to keep
| things simple.
| sangnoir wrote:
| > Their job is building a working .deb with working
| software
|
| If that were was all there is to packaging - upstream
| developers could do the same job & have their CI/CD
| pipeline shoot out a .deb file.
|
| However, it's not unheard of for package managers to
| maintain an evolving patchset that changes the default
| behavior and better integrates the upstream project to
| the rest of the distribution and its philosophy.
| WorldMaker wrote:
| > If that were was all there is to packaging - upstream
| developers could do the same job & have their CI/CD
| pipeline shoot out a .deb file.
|
| That's what some users seem to want today. It's why both
| Flatpak and Snap exist with the goals of letting upstream
| developers just CI/CD spit out a "universal" package for
| Linux and getting a more "Mac-like" (or "Windows-like" if
| you prefer) install experience with less waiting for
| package maintainers to get around to publishing upstream
| changes.
|
| Admittedly, Flatpak and Snap aren't universally beloved
| either, yet, but the balance of what the job for a
| distro's package maintainers should be is definitely in
| shift.
| Kwpolska wrote:
| Upstream developers don't have the time and bandwidth to
| set up packaging for all distros and versions.
|
| Improving defaults may be fine according to some.
| Removing major features advertised by the software due to
| political reasons is not fine.
|
| My software is a victim of Debian maintainers as well:
| they chose to remove the default theme from our static
| site generator, because it was built on top of Bootstrap
| 3, but Debian only shipped Bootstrap 2 at the time in a
| global package (they also changed the bootstrap 2 theme
| to use symlinks to the global version). How is this
| "better integration with the philosophy"?
| sangnoir wrote:
| > My software is a victim of Debian maintainers as well:
| they chose to remove the default theme from our static
| site generator, because it was built on top of Bootstrap
| 3, but Debian only shipped Bootstrap 2 at the time in a
| global package (they also changed the bootstrap 2 theme
| to use symlinks to the global version)
|
| As a Debian stable devotee, this seems reasonable to me.
| If I wanted each package to bring along & manage its own
| dependencies, I'd use flatpaks.
|
| > How is this "better integration with the philosophy"?
|
| I'm guessing Bootstrap 3 wasn't yet in whatever
| release/channel your software was being packaged for?
|
| Can't you imagine any possible benefits of not shipping
| bootstrap v2 _and_ Bootstrap v3? Or do you just disagree
| with the Debian unstable - > testing -> stable
| philosophy? Dependency juggling is just one of the issues
| distro package maintainers have to wrangle with, that
| upstream maintainers typically don't care about - an
| upstream project can declare "this version requires the
| latest glibc", but distro packagers may have to patch
| around that because the latest version of glibc hasn't
| been through testing.
| Kwpolska wrote:
| We ship a copy of bootstrap within our data files. They
| could just leave it as-is and have it working. Bootstrap
| is a CSS/JS library, there is no global /usr/lib to be
| concerned about.
| sangnoir wrote:
| Most of HN who've been around know what Bootstrap is
| (rip, old Twitter). The same rules apply whether your
| package dependencies are .css, .js or .so
| cassianoleal wrote:
| > because it was built on top of Bootstrap 3, but Debian
| only shipped Bootstrap 2 at the time in a global package
|
| > there is no global /usr/lib to be concerned about
|
| Aside from possibly the path being different, which is of
| no concern, how can the 2 above sentences reconcile with
| each other?
| Kwpolska wrote:
| It is trivial to make the Bootstrap 3 global package
| install into a different folder than Bootstrap 2. It
| isn't so trivial for shared libraries without different
| sonames, for example.
| Am4TIfIsER0ppos wrote:
| Randomly messing with the code they package is the
| primary job of a debian packager. Which is how we get
| such great contributions from debian maintainers like the
| weak keys fiasco.
| kiwijamo wrote:
| It can also work the other way around. When I install
| Apache on other distros I end up having to disable so
| many modules -- whereas the default Apache config in
| Debian is pretty watertight I never really have to mess
| around with modules. Likewise installing PHP only
| installs the core PHP module, you have to specifically
| install the extras. Other distros install everything
| including the kitchen sink. Needless to say, I'll take
| the Debian approach, warts and all.
| Daviey wrote:
| _demand_? Perhaps if you are unhappy you should ask for a
| refund. I just can 't get my head around this sort of
| entitlement.
| lannisterstark wrote:
| >Sorry, why do maintainers owe us anything?
|
| "they're doing it for free, no one owes you anything" is
| always the argument people make when someone does
| something reasonably dumb and they need to defend the
| maintainers/devs. They don't owe anyone anything, but
| people DO HAVE _REASONABLE_ expectations of them.
| fullspectrumdev wrote:
| Package maintainer != Project maintainer.
|
| In this instance the maintainer of the Debian package for
| KeePassXC has unilaterally made a choice.
| kiwijamo wrote:
| Which is pretty much what all other Debian package
| maintainers do. For Debian users it's expected they
| ensure the software they are packaging fits in with the
| Debian way of doing things. This is what Debian users
| want -- if they wanted all packages 'nude' with no
| changes applied there are other distros e.g. Arch that
| are much better suited. I personally tried other distros
| which tries to package as close to upstream as possible,
| and I was pretty surprised by the poor upstream defaults
| of many packages and lack of useful utilities. E.g.
| Apache is so much better packaged by Debian -- it wasn't
| until I installed Apache in Arch that I realised many of
| the useful stuff I used in Debian was actually Debian-
| specific. Most packages in Debian come with very good
| defaults that my "setup" script (i.e. install/configure
| packages) for my Debian machine is literally <50 lines
| whereas for Arch it was something like 200 lines
| including due to having to reconfigure a lot of not-very-
| well-thought-out upstream defaults that Arch kept in
| place.
| fullspectrumdev wrote:
| With Debian I expect sensible default configs, but not
| "we deleted a load of actual features".
|
| In this case it's _features_ that were patched out - not
| _plugins_ or a mere config change.
| m-p-3 wrote:
| KeepassXC consider these options as "plugins", it's right
| there in their official documentation for the build
| options.
|
| The Debian package wasn't shipping the correct default
| configuration in the first place, it's unfortunate but
| better late than never, and it's not like you can't
| switch to the keepassxc-full package.
| kiwijamo wrote:
| Which is in line with how many other Debian packages work
| which is again why I think this isn't really a big issue
| from the perspective of a Debian user. Most of the upset
| seem to be coming from users of other distros unfamiliar
| with the Debian approach to doing things. I do agree it's
| annoying that this wasn't done from Day 1, but better
| late than never.
| thaumaturgy wrote:
| I anticipated this reply, either here or elsewhere, and
| was _really_ hoping it wouldn 't arrive.
|
| I do a lot of volunteer work too. Guess what? My
| decisions in those roles are not unimpeachable. Being a
| volunteer _also_ does not mean you are owed anything,
| even gratitude. It 's a thing you choose to do, and if
| you don't like doing it anymore, then you should stop
| doing it.
|
| Package maintainers aren't self-sacrificial saints or all
| that unique as volunteers go.
|
| This is a bad decision. It deserves criticism and
| discussion. The volunteer status of package
| maintainership is irrelevant.
| CooCooCaCha wrote:
| I share your frustration because comments like that show
| up in every thread about open source.
|
| By putting something out into the world you're creating
| connections with others. If people like what you've built
| and start to rely on it then that puts power into your
| hands, and any time you have power over others it should
| be wielded responsibly.
|
| Volunteering doesn't give people a pass to screw over
| others.
| otherme123 wrote:
| And who decides "responsible"? The mantainer made the
| decision of defaulting to no-network for safety reasons,
| that users can reverse with a flag. This sounds
| responsible enough for me.
|
| I bet that if a bug is found in the connection API and
| passwords leak, we would impale the head of the mantainer
| in a pike for not defaulting to safe mode, or to have
| connection at all.
| nrabulinski wrote:
| And the software authors made it clear that those
| features, even if compiled in, are _disabled by default_
| and the code _never_ executes.
| roenxi wrote:
| Connecting the internet and a password database together
| is one of those fundamentally bad ideas. This might well
| be an excellent technical decision. Although I agree with
| the thread root that this is a level of intervention that
| might justify some rebranding.
|
| > Package maintainers aren't self-sacrificial saints or
| all that unique as volunteers go.
|
| If you want keepassx, you can go install it. If you want
| the Debian archive's version, install that. All the
| options are open to critique, but the average Debian
| maintainer is doing so much more good than the occasional
| bad decision that they get a lot of benefit-of-doubt on
| this sort of choice. And some reasonable expectations of
| respect.
| techwizrd wrote:
| Is it a _fundamentally_ bad idea? The connected syncing
| feature of Bitwarden is one of my favorite things. I can
| save a password on one device, and its automagically
| available on others all while staying encrypted (and
| audited).
| kiwijamo wrote:
| Agreed but it is worth keeping in mind that Bitwarden's
| implementation of sync is probably a lot more
| sophisticated than KeepassXC; and is probably the main
| reason why one would use Bitwarden. I am a former user of
| Keepass and I never knew it had network functionality so
| I think it makes sense to provide two packages -- one
| containing the main keepass functions which which 99% of
| users will use and the othrer for the 1% using the exotic
| functions. This is in line with how Debian handles many
| other packages such as vim, exim, etc so it is not at all
| surprising for the typical Debian user.
| Snetry wrote:
| KeePassXC has no sync implementation.
|
| The functions related to Internet are:
|
| - getting the favicon for a specific entry (needs to be
| ran manually with an option to download via a DuckDuckGo
| proxy)
|
| - checking entries against HIBP (needs to be done
| manually in a submenu with a giant notice)
|
| Also this is about KeePassXC not KeePass which is a
| completely different project. There is also KeePassX,
| KeePassDX, KeeWeb, KeePass-electron and so on and so
| forth.
| Dalewyn wrote:
| >And some reasonable expectations of respect.
|
| Volunteers by definition do not (or at least should not)
| expect anything in return for their time. If you _want_
| respect as a so-called volunteer, you 're not a
| volunteer.
|
| I've seen both good and bad package maintainers, too.
| roenxi wrote:
| > Volunteers by definition do not (or at least should
| not) expect anything in return for their time
|
| That isn't really true. For starters, paid volunteers are
| actually a thing that happens from time to time.
| Secondly; there would be no volunteers if they didn't get
| _something_ for their time. It is just generally that
| something isn 't money. Volunteers aren't expected to be
| selfless.
| nrabulinski wrote:
| If you're getting paid you're _by definition_ not a
| volunteer. You may be getting some perks like
| volunteering at a convention giving you an entry pass for
| that convention, but as soon as you're getting some other
| gains, be it monetary or not, you're no longer a
| volunteer.
| roenxi wrote:
| > If you're getting paid you're by definition not a
| volunteer.
|
| You are technically incorrect. The US army, for example,
| is manned more or less entirely with paid volunteers.
|
| And while many volunteers may not get formal
| compensation, they have to expect to get _something_ out
| of the experience. Otherwise they would not do it. The
| subset of volunteers who are in it purely for a
| biblically pure sense of charity is tiny. And there is no
| expectation that Debian developers are motivated by some
| cultish wish to do good for the sake of free software.
| They 're allowed to be motivated by whatever motivates
| them to do good with free software. Even if it is money.
| Dalewyn wrote:
| >they have to expect to get something out of the
| experience.
|
| Volunteers are in it for the satisfaction of
| volunteering.
|
| If you want anything beyond that as compensation for
| volunteering, you are by definition not volunteering.
|
| Incidentally, those who receive monetary compensation for
| their time and work are known as _professionals_.
| thaumaturgy wrote:
| > _Connecting the internet and a password database
| together is one of those fundamentally bad ideas._
|
| Disagree. I use KeePassXC because I would prefer to have
| my passwords on my computer, instead of somebody else's
| computer (and I am willing to accept responsibility for
| managing my own password file).
|
| That is a delineation that is parallel to, but not the
| same as, "don't connect to the internet". Browser
| integration is a required feature for a modern password
| manager; without it, you don't have a password manager,
| you have an encrypted notepad. HIBP integration is,
| likewise, net-good for users.
|
| Also, as the KeePassXC devs have repeatedly pointed out
| in multiple places, these features are compiled in, but
| not enabled by default. Users who do not wish to use them
| can simply ignore them. Julian's argument at best seems
| to be some kind of concern about software supply chain;
| he is compiling the package without these features so
| that they are no longer available to the users who do
| want them.
|
| The people making the arguments in favor of this change
| "for security reasons" aren't even making strong
| arguments for it.
|
| > _If you want keepassx, you can go install it..._
|
| Okay. And if you want a super-paranoid version of
| KeePassXC without these features compiled in, _you_
| can... go compile it that way.
|
| Like everyone else, I already have thousands of little
| time sinks to contend with simultaneous to other
| increasing pressures in life. I am investing some time
| now to try to prevent another bad decision from adding to
| those faffs.
|
| > _some reasonable expectations of respect._
|
| First, from my reading here and on the Mastodon thread
| and on the GitHub thread, _most_ people have expressed
| dissatisfaction with this decision without crossing the
| line into disrespect towards the maintainer. The
| KeePassXC devs have maybe gotten a little heated, but
| they deserve all the same allowances you 'd give to a
| package maintainer. They are getting bug reports due to
| downstream's decision, which they strongly disagree with.
| That sucks. There is a little bit of the usual internet
| noise, but otherwise, this is about the best discourse
| that could be expected for something like this.
|
| Second, Julian himself kinda invited a strong negative
| response when he replied early on with, "This will be
| painful for a year as users annoyingly do not read the
| NEWS files they should be reading but there's little that
| can be done about that. ... All of these features are
| superfluous and do not really belong in a local password
| database manager, these developments are all utterly
| misguided. Users who need this crap can install the
| crappy version..."
|
| ---
|
| Getting back to some substantive discussion, it seems
| unlikely Julian is going to change his mind on this. This
| seems like a clear failure of package stewardship to me;
| KeePassXC's best move IMO is to set up their own
| repository and provide instructions for adding their repo
| and key to apt and then pin their keepassxc package. It's
| a bit of a nuisance for them, but probably less headache
| than ongoing bug reports and noise from the internet.
| There's already a lot of other software that gets
| installed this way, so I think it's fair to expect the
| average Debian user to be able to handle this process --
| it's copy-and-pasting about four lines into your
| terminal. Then, Julian will no longer need to bear the
| burden of maintaining the package.
| LoganDark wrote:
| > Browser integration is a required feature for a modern
| password manager; without it, you don't have a password
| manager, you have an encrypted notepad.
|
| Not really? I've been using KeePassXC without a browser
| extension for a while, probably not years but certainly
| many months. That doesn't make it any less of a password
| manager - it lets me generate random strings to use for
| each account, keeps them safe and encrypted, and also
| lets me enable TOTP for an unlimited number of accounts.
| That's pretty much a password manager to me (TOTP is
| extra but much appreciated).
| valicord wrote:
| > And some reasonable expectations of respect.
|
| I think that expectation ends once you start calling the
| other party's software "crappy".
| makeitdouble wrote:
| I agree volunteering doesn't mean decisions can't be
| criticized, but the notion of duty towards the user
| oversteps that.
|
| The same way maintainers make their decisions, the
| community is free to deal with it in any way shape or
| form. As long as money or malice or recklessness isn't
| involved, people should be free to do what they think is
| right, and the current maintainers aren't putting any
| roadblocks to prevent others from using the work in the
| way they want.
| mardifoufs wrote:
| They don't owe us anything, but that's completely
| unrelated to the current discussion. They can be
| completely free to do whatever they want, and users can
| also disagree with that and voice said disagreement. It's
| a two way street. Especially in a situation where there's
| only "one" maintainer per package per distro, meaning
| that users of the distro (who can be other maintainers
| too) can disagree with it and openly so. There's a reason
| why Debian doesn't allow a maintainer to say, gut systemd
| or switch to another init system unilaterally just
| because they are volunteering to maintain the package
| cqqxo4zV46cp wrote:
| This line is always ludicrous because it doesn't play in
| literally any other volunteering scenario. In a previous
| life I coordinated volunteers. You better believe that I
| still held them to a standard and told them their time
| was better spent elsewhere if they didn't want to play by
| the rules. "But they're volunteering!" Is a uniquely open
| source contributor mindset that only seeks to perpetuate
| some nerd's weird fiefdom. The reality is that for some
| people, they're just...fine not getting paid with money,
| because what they're really after is something to
| control.
| kiwijamo wrote:
| At the end of the day the volunteer is a volunteer for
| the Debian project (not KeepassXC or others) and doing
| what is deemed right for the Debian project. I agree
| volunteers should be held to a high standard, although I
| suspect in this case the volunteer is maintaining
| Debian's high standards. As a Debian user the volunteer's
| decision seems in line with Debian's ethos.
| valicord wrote:
| If you claim to distribute application FooBar, you owe it
| to the authors of said application to actually distribute
| FooBar and not something else that was modified against
| their wishes. If you want to distribute a modified
| version, you should call it something other than FooBar.
|
| You also owe it to your users to not mislead them by
| claiming that your modified version is actually the real
| FooBar.
| kiwijamo wrote:
| I note elsewhere in this thread that all they did was
| disable an option from the upstream build script --
| suggesting this is an acceptable option provided by
| upstream themselves? I think suggesting a rename is a
| bridge too far given even upstream provides a way to
| build the software without the extra functionality behind
| what sounds like a simple build option flag.
| pessimizer wrote:
| > If both upstream and a significant portion of users
| strongly disagree with a maintainer's judgement, then how
| is their role as maintainer justified?
|
| By their making the decision they think is best and that
| agrees with the philosophy of the distribution they're
| maintaining the package for? I'm glad they don't have to
| justify their existences to upstream and every "significant
| portion[...] of users."
|
| > It's KeePassXC's job to secure the software and produce
| features that fulfill users' needs as they see fit.
|
| You don't control free software after you've licensed and
| distributed it that way. The _entire point of the concept_
| is to make calls like this about anti-features. KeePassXC
| can feel free to comment on it, like anyone else. They can
| demand that Debian make available the modified sources.
| They can revoke any license to the use of trademarks. That
| 's it.
|
| If users only want to deal with KeePassXC, they can compile
| it themselves or use a portable version. If KeePassXC wants
| to deal with Debian users directly, they can host a package
| repository for their canonical version.
| makeitdouble wrote:
| > KeePassXC's job
|
| Is KeepassXC even a company ? looking at their site and
| wikipedia, they're just a bunch of people dedicated enough
| to maintain the project. Looking at the donation page [0]
| they don't even list anything going to themselves in the
| use of the money.
|
| So they're effectively paying with their time to keep the
| thing alive. If anything the community seem to own a ton to
| these guys.
|
| [0] https://keepassxc.org/donate/
| omoikane wrote:
| This reminds me of "The gift of it's your problem now"
| (2021): The best part of free software
| is it sometimes produces stuff you never would have been
| willing to pay to develop (Linux), and sometimes at
| quality levels too high to be rational for the market to
| provide (sqlite). The worst part of free
| software is you get what you get, and the developers
| don't have to listen to you. (And as a developer, the
| gift recipients aren't always so grateful either.)
|
| https://apenwarr.ca/log/20211229
|
| https://news.ycombinator.com/item?id=29736369
| HumanProtractor wrote:
| Upstream's irrelevant to a maintainer. Downstream?
| Maintainers typically know best, that's why the user chose
| that distro. I bailed on Debian when they decided to go
| systemd. That's Democracy.
| m-p-3 wrote:
| The default build of KeepassXC is without any optional
| modules
|
| https://github.com/keepassxreboot/keepassxc/wiki/Building-
| Ke... -DWITH_XC_ALL=[ON|OFF]
| Enable/Disable compiling all plugins above (default: OFF)
|
| To me, it seems like the maintainer is simply bringing the
| default package back to what it should have been, and he's
| offering another build with all features enabled under
| keepassxc-full
|
| If KeepassXC is unhappy with the defaults, they can adjust
| theirs to reflect what they feel should be available out of
| the box.
| tdb7893 wrote:
| Having things named the same across platforms but with
| significantly different features is a usability nightmare.
| They even created a package that does have all the same
| functionality but named it something different, if you're
| gonna change the functionality from other platforms then
| that's the one that should have a different name.
| dataflow wrote:
| > The role of a maintainer is more than copying and pasting
| upstream
|
| They can do that... under a name that doesn't mislead people.
| Is that so hard?
| Gud wrote:
| They should not alter basic functionality. Their sole job is
| to make the software work on their platform.
|
| I would be pissed if a FreeBSD package was some non-standard
| configuration.
| quectophoton wrote:
| Disclaimer: I don't use Debian, so I don't have a horse in
| this race.
|
| > I would be pissed if a FreeBSD package was some non-
| standard configuration.
|
| I'm of two minds here.
|
| On one hand, I agree that I would like packages to be
| packaged as similar to upstream as possible (even if this
| has also caused annoying changes during upgrades).
|
| On the other hand, I appreciate when package maintainers
| remove things like enabled-by-default telemetry (which is a
| whole another topic of its own).
|
| Of course for both cases one should _at least_ skim over
| the post-installation messages, or whatever they 're
| called. To look for deprecation notices, additional
| instructions, messages like "if you need X feature please
| install such package", etc.
|
| So if I don't read these messages, which appear right at
| the end of the install/upgrade process (can't miss them),
| that's my fault. If I don't do a zpool checkpoint before
| upgrading, that's my fault. If I don't verify important or
| major stuff (like my password manager, web browser,
| rebooting to ensure graphics drivers still work, etc) after
| the upgrade and _before_ deleting the zpool checkpoint,
| that 's my fault. If I didn't at least skim the list of
| package that were going to be upgraded, that's my fault. If
| I didn't backup my zfs mirror to a separate, plugged out
| drive before doing a major FreeBSD version upgrade, and the
| upgrade goes wrong, and I don't have any way to restore the
| pool to how it was before the upgrade, oh you better
| believe that's my fault.
|
| (EDIT: Sorry for the long paddlin' reference but the TL;DR
| is that, if something breaks, half of the responsibility
| lies on the user.)
|
| Changing topic back to TFA and Debian.
|
| Whether or not the Debian maintainer followed proper
| procedure for such a change, is a good question because
| there's not only the maintainer, but also Debian itself.
|
| So I'm kinda waiting to see if there's any response from
| someone higher up the Debian chain of command; if they
| (whoever writes the "Debian maintainer rules") consider
| this acceptable for a maintainer to do, or if they will
| issue a warning saying this was something not acceptable
| and "might lead to losing maintainer status if it repeats
| in the future".
| JeremyNT wrote:
| Maybe Debian maintainers consider it their role to do this,
| but that's absolutely not true in other distributions (e.g.,
| one reason I use Arch is to avoid such tinkering). Down this
| road lies problems with incompatibilities and new bugs that
| are distro-specific.
|
| As a user it defies my expectations to have software modified
| to remove functionality and retain the same name. This is a
| bit too opinionated for _my_ tastes.
| rcxdude wrote:
| This. As a user and a developer I've had more than a few
| run-ins with a distro deciding to be a bit different,
| usually with no very weak justification (pedantic
| interpretations of some standard, attempts to make
| something 'neat', or just random changes that someone
| thought would be cool). Debian is especially bad at this,
| Arch tends to be better but they've also done some stupid
| things (python-as-python3 being a thorn in so many
| developer's side for years).
| cycomanic wrote:
| The justification is absolute rubbish. I The argument is that
| it reduces attack surface, but compared to what, the
| alternative to including the yubikey code is not using a
| yubikey, which reduces security. The alternative to using the
| browser integration (or the ssh agent) is to use the
| clipboard, which is likely more code and definitely less
| vetted code.
|
| By the same argument we should remove encryption as well,
| because it increases the amount of code and thus the attack
| surface.
| undersuit wrote:
| >the alternative to including the yubikey code is not using
| a yubikey, which reduces security.
|
| The physics of someone cracking my passphrase and the
| physics of someone cracking my Yubikey are both in the boil
| the oceans amount of energy.
|
| I'm fine not letting a usb device masquerading as a
| keyboard have access to my password database.
|
| Remember: "When you lose your YubiKey or someone else gets
| access to it, your database is not secure anymore."
| lawn wrote:
| > When you lose your YubiKey or someone else gets access
| to it, your database is not secure anymore.
|
| You don't store your password on the YubiKey, you use it
| as a second factor _in addition_ to your password.
|
| Do you know what a YubiKey is when you argue against it?
| undersuit wrote:
| You can add different kinds of authentication to your
| password safe. I use a password and a key file. You can
| use just the Yubikey just like you can also have no
| encryption applied to the password safe.
| valicord wrote:
| What is the physics of someone sniffing your passphrase
| with a keylogger?
| undersuit wrote:
| The same as someone sniffing the Yubikey communications.
| valicord wrote:
| except yubikey communications are not static, so unlike
| password, sniffing it doesn't allow attacker to open all
| future versions of the db
| vilunov wrote:
| I don't understand the need of such a role at all. It's fine
| if it's the OS-level software, but for end-user applications
| such as KeePass I'd prefer that there would be no
| intermediaries between the developers of the app and the
| users. You don't need to repackage every piece of software
| that your users might want to use, let developers target your
| OS on their own by providing a stable set of APIs and ABIs,
| otherwise it's not really an OS.
| rfoo wrote:
| Oh no, xscreensaver or GNU Parallel flame war once again.
| temac wrote:
| > If they want to go this direction they should publish as a
| fork under a different name so upstream doesn't get constantly
| barraged by complaints of users having issues.
|
| What are you talking about? This is an upstream build option.
| Has upstream forked itself by providing this option?
| ErikBjare wrote:
| That seems entirely fair to me.
| zer00eyz wrote:
| IF apple said "hey we edited your app because we think its more
| secure"...
|
| People would have torches and pitchforks out.
|
| But a deb maintainer does it and there is debate?
|
| If there was a security issue then the insecure version should
| NOT be available. But again this is not the case.
|
| In an App Store world, the role of mainainter has to change.
| The job is to make the software work with the distro, not keep
| the name and make some pseudo fork because you want it to be
| another way.
| int_19h wrote:
| Debian does this all the time. There are thousands of .deb
| packages that are built with patches.
|
| In this case, though, it's not even a patch - it's a build
| flag that is provided by upstream.
| jdbernard wrote:
| The fact that they are customizing the software is not
| really the issue. The issue is that they are making a
| change that will remove significant functionality and in
| some cases completely lock some users out of their password
| database, which is a huge deal. Imagine if you wake up
| tomorrow, run a software update and then can't log in to
| your bank?
|
| I imagine the reason this has blown up so much is that the
| maintainer never reached out to the upstream about this,
| and was rude and condescending when upstream reached out to
| them.
| Vegemeister wrote:
| I've visited the App Store world, and my experience was that,
| weighted by how often packages appear in search results, the
| median is charitably described as "potentially unwanted", and
| honestly described as malware.
| BLKNSLVR wrote:
| Isn't this just FOSS working as intended?
|
| There are lots of distributions other than Debian.
| kragen wrote:
| lots of debian packages are compiled without some compile flags
| that enable optional functionality; emacs, for example, comes
| in emacs-nox, emacs-gtk, and emacs-lucid, the last two of which
| use two different x-windows toolkits to give emacs a gui. (it's
| nice to not have to install a gui environment in order to have
| a text editor, see.) vim similarly has vim-tiny, vim-nox, vim-
| motif, and vim-gtk3 versions
|
| in this case it seems like the debian maintainer moved optional
| functionality that was opening security holes to the keepassxc-
| full package, and the keepassxc maintainers are lying about it
| by saying that he has 'decided to remove ALL features from it'
|
| in https://github.com/keepassxreboot/keepassxc/issues/10725 the
| debian maintainer explains:
|
| > _It is our responsibility to our users to provide them the
| most secure option possible as the default. All of these
| features are superfluous and do not really belong in a local
| password database manager, these developments are all utterly
| misguided._
|
| > _Users who need this crap can install the crappy version but
| obviously this increases the risk of drive-by contributor
| attacks._
|
| and yeah i really, really do not want my password manager to
| _by default_ communicate with random web pages. that should be
| opt-in functionality and always should have been. given that it
| wasn 't, there's no _good_ option, but this is the least bad
| one
|
| one of the great benefits of free software is that it makes it
| hard for misguided or malicious maintainers to push
| antifeatures on users, because the users can always use
| somebody else's version of the software, for example, debian's
| or f-droid's. trusting debian to prevent shenanigans like the
| keepassxc team's is my biggest reason for using debian instead
| of something else
| netsharc wrote:
| Your points are valid, but doing a switcheroo of someone's
| software is the stupid part...
|
| You say you trust Debian, but until this update, they've been
| allowing those horrible horrible shenanigans, on your system!
|
| Would you trust a security guard who for many years didn't
| notice a part of the building he should've checked for
| unlocked doors, until someone pointed it out to him?
| kragen wrote:
| it's a question of degree. i'd trust him more if he'd been
| checking it all along, but i'd trust him less if he decided
| that he shouldn't start checking it even after it was
| pointed out
|
| debian has made much worse security mistakes than that; i
| personally danced tango at debconf with the debian
| maintainer who introduced the openssl bug, which is
| arguably the worst computer security hole in human history
|
| basically the social practices of software development make
| computer security unattainable at any cost. we can try to
| improve that situation, but for the time being, debian is
| close to the best there is, even if it's not openbsd or
| sel4
| moqmar wrote:
| So the Debian maintainer complains about the upstream project
| (which they decided to maintain the package for) bringing
| "crap" and having "utterly misguided" development? And
| somehow people say that this is the reasonable person here,
| basing a major change of a software's featureset on such an
| opinion?
|
| Independent from whether the original change is good or bad,
| so much of what's wrong with Open Source is people trying to
| work against each other instead of together...
| kragen wrote:
| what leads you to suspect he's wrong? from the quotes in
| your comment i suspect it's his choice to use plain
| language and openly disagree with others. in my experience
| that's how trustworthy, competent people talk
|
| people working together successfully in free software
| doesn't depend on them having the same values or getting
| along or wanting the software to do the same thing. it just
| depends on being clear and open about what the software
| does and doesn't do, and using licenses that keep them from
| suing you for distributing versions without their preferred
| features or antifeatures. remember that this is the
| movement that not only includes richard stallman but was
| founded by him. if it depended on getting along it never
| would have left the cradle
| LightFog wrote:
| I guess you missed the bits on Mastodon where the package
| maintainer simply didn't bother reaching out to the
| upstream whatsoever because he was 'too busy' and would
| only do so over a particular IRC setup. That's not
| competent or good faith maintenance.
| TheDong wrote:
| I suspect he's wrong because he's disabled some of
| KeepassXC's most important security features.
|
| One of the largest security threats to users is phishing
| websites, getting an email and clicking a link, and then
| typing your actual password into some fake hacker's
| webpage.
|
| Having browser integration in your password manager, such
| that it auto-enters the right password on "real-
| bank.com", but doesn't enter it on "rel-bank.com", is a
| strong protection against phishing.
|
| The maintainer disabled the browser integration for
| KeepassXC, which forces users to copy+paste passwords
| into webpage's password inputs, making them significantly
| more vulnerable to phishing.
|
| Their fear-mongering about supply-chain attacks and bugs
| in more LoC is silly when compared to the very real
| threat of phishing attacks, which are way more prevalent
| and a way more severe threat.
| phoerious wrote:
| The extra functionality isn't opening security holes. It is
| central functionality that users have come to expect such as
| Auto-Type or support for YubiKeys. The Debian maintainer has
| decided to disable the WITH_XC_ALL flag, which disables ALL
| optional features (not sure why you consider this a lie).
|
| Your claim that KeePassXC communicates with random webpages
| is also false. There are two cases in which websites are
| communicated with (none of them random): a) an optional
| update check (can be disabled), b) when you click the button
| to download a website's favicon. Please don't just state
| things that are not true.
| mikepavone wrote:
| All they did was change the XC_ALL build parameter to OFF [0]
| which happens to be the default in upstream's CMakeLists.txt
| [1]. If upstream thinks this functionality is so important
| maybe they should fix their defaults.
|
| I think it's a bit unfortunate that users of this package may
| be confused why stuff stops working when they upgrade, but
| having the unsuffixed package match upstream defaults seems
| entirely reasonable otherwise.
|
| [0]
| https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
| [1]
| https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
| dingensundso wrote:
| At first I thought it should be the other way around. Keep
| the current keepassxc package and create a keepassxc-minimal.
| But seeing the build options it makes sense to have a
| keepassxc-full.
|
| Only thing is this will annoy some people when they upgrade.
| But only when this reaches stable and then there will be
| notice in the upgrade documentation and apt-listchangea.
| c-hendricks wrote:
| > If upstream thinks this functionality is so important maybe
| they should fix their defaults.
|
| > none of these features are plugins. All of them are built-
| in functionality that belong to the main product. If
| anything, we will reduce the number of such compile-time
| flags in the future, so these things cannot be disabled
| anymore.
|
| https://github.com/keepassxreboot/keepassxc/issues/10725#iss.
| ..
| out-of-ideas wrote:
| > Gutting the functionality that upstream has built into a
| piece of software and then publishing it under the same name is
| dubious at best
|
| reminds me of busybox's implementations of: bash, sed, awk, ect
| and similar situations when folks go and ask 'how something-in
| bash works' then 'it doesnt work' all because of macos bash vs
| gnu bash, and forever on the battle goes with naming.
| blablabla123 wrote:
| Kind of interesting actually. In the 2000s/2010s it was quite
| normal that distributions provided modified packages. Maybe not
| necessarily function-wise but theming, config files to a degree
| that interoperability wasn't the best. Even more funny that
| this is done now by Debian which always had a reputation of
| providing vanilla packages... But I guess after the xz debacle
| this is getting a new kind of attention
| jdbernard wrote:
| If this was the first time they were packaging keepassxc,
| this would be fine. If they instead chose to remove the
| keepassxc package and provide two new packages, keepassxc-
| minimal and keepassxc-full, it would be fine. It's the fact
| that the main package that people already have installed will
| no longer have functionality that many users depend on,
| breaking their configurations after an update.
| 2OEH8eoCRo0 wrote:
| It sounds like a necessary but painful change if we want secure
| by default.
| bananenpubs wrote:
| Speak for yourself, please, not for 'us'.
| unparagoned wrote:
| People always crap over LastPass, but when you ask them what they
| do, it's some elaborate process relying on thousands of no name
| packages and devs.
| lawn wrote:
| These kind of "feature changes" in Debian packages is one reason
| I stay away from Debian.
|
| And it's not just features that might change. A Debian maintainer
| introduced a bug in the OpenSSL random number generator making it
| insecure, a couple of years ago.
| wswope wrote:
| > a couple of years ago
|
| You're bearing a grudge based on an unintentional bug
| introduced _18_ years ago. Weak take and irrelevant to topic at
| hand.
| charles_f wrote:
| > It is our responsibility to our users to provide them the most
| secure option possible as the default. All of these features are
| superfluous and do not really belong in a local password database
| manager
|
| While that sounds like a reasonable argument, I think it misses
| the fact that you need reasonable usability to get users to use
| your product. E.g there's no way my wife will use KP of she
| doesn't have autofill, and she'd then revert to someone else's
| computer like lastpazs or 1password instead, which I'd argue is a
| worse solution in all ways possible.
|
| The other thing that makes me question this a little, is removing
| yubikey support and auto type. While you don't get the full
| advantage of MFA, having a rotating encryption key is still an
| additional layer of protection. Meanwhile, without auto type you
| will need to copy-paste usernames and passwords - and listening
| to the clipboard is much easier than building a key logger.
|
| I mean, if really what you're looking for is barebones, you can
| also not use a password manager and come up with a cypher
| instead.
| Brian_K_White wrote:
| No. They are completely right. I use keepassxc every day
| without any of those features intentionally for years. So,
| obviously it is quite functional without them. It is not
| remotely a case of "fine let's just unplug the electricity that
| is even safer!"
|
| Those extra hooks and integrations can exist, and you can use
| them, and you aren't automatically wrong for having different
| priorities where you are willing to use them, but there is no
| excuse for avoidable bug & attack surfaces being in there,
| specifically in a security utility, by default.
|
| It's backwards priorities.
| jeffalyanak wrote:
| I think the solution suggested by drawks seems clearly the
| correct choice:
|
| > I think the proper solution would probably be to package both a
| "-full" and "-minimal" version of the software and utilize Debian
| package meta-data fields to define a Conflicts relationship
| between the packages and tag them also both with a Provides for
| keepassxc and also add a tag Replaces: keepassxc to the -full
| build so that during a package upgrade an existing user would be
| provided the version that continues to provide the features of
| the package which is being upgraded/replaced while new users can
| choose for themselves which of the versions they'd like to
| install
|
| https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
|
| Why would this _not_ be the obvious choice?
| rfoo wrote:
| Because maintainers have an opinion and explicitly wanted to
| _change_ the default.
| jeffalyanak wrote:
| That does allow you to change the default for users
| installing the packages and while ensuring that users who
| already have it installed don't lose functionality during an
| upgrade.
| GorsyGentle wrote:
| Perhaps, and that's not unreasonable in and of itself. But to
| do so in such a user-hostile manner? That's a bit over the
| top. A new minimal package, advertising it, and only then
| eventually making it the default would have been far, far
| more effective.
|
| If an engineer of mine pulled this on our user-base I'd have
| them reverting it in a heartbeat regardless of the technical
| merit. They already failed just in how they executed this and
| have burned good will, the technical merits no longer matter.
| Once you've lost the faith and trust of the user, it's over.
|
| The original request[0] was more or less simply a user asking
| for the networking to be removed, and follow-up to just have
| a -nonetwork variation. Instead, we have comments from the
| debian maintainer:
|
| The OP report: > Users who need this crap can install the
| crappy version but obviously this increases the risk of
| drive-by contributor attacks.
|
| The debian package description[1]: > See keepassxc-full if
| you absolutely need those.
|
| The PR[2] > Feature creep like SSH agent support, browser
| integration, Freedesktop.org secret storage, KeeShare pose
| undue risks for most users.
|
| Each one of these sends a message. And it was entirely
| avoidable with a bit of grace and kindness to the existing
| userbase.
|
| [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
|
| [1]: https://packages.debian.org/sid/keepassxc
|
| [2]: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d1
| 6e3f...
| rfoo wrote:
| Yeah, I agree with you. I'm joking that KeePassXC
| developers should make parsing .kdbx an optional feature
| (that's an attack surface by itself for sure!) and see
| whether Debian package maintainer enable it or not.
| kasabali wrote:
| > user-hostile manner
|
| This isn't user hostile.
|
| You know what'd be user hostile? Removing the functionality
| and _not_ providing the _-full_ package alongside.
| LightFog wrote:
| It is.
|
| The software has been broken - the UI wasn't designed
| with those toggles in mind so now users suddenly have non
| functioning features presented to the in the UI.
|
| The argument the all users should be keeping up to speed
| on NEWS - especially in the stable channels this will end
| up in - to explain why their UX is suddenly broken is not
| exactly 'user friendly'.
| kasabali wrote:
| > all users should be keeping up to speed on NEWS
|
| They don't need to, it is _shown_ to them during apt-get
| upgrade
|
| > especially in the stable channels
|
| This is in testing/unstable. Stable users aren't and
| won't be affected until until the next major Debian
| version is released and the users decides to do the
| upgrade.
| Brian_K_White wrote:
| I think it's correct for the default package to be the safest-
| possible one. It's a password manager not an mp3 player.
|
| Yes it's annoying that an existing behavior will change, but that
| problem is not more impportant than the problem of what should be
| the default behavior of a security app.
|
| keepassxc should have always been like that by default and all
| the added conveniences that also add bug-surface and attack-
| surface should have always been things you have to go out of your
| way to add.
|
| It wasn't and so now to fix that error requires a disrupting
| change, but that is not enough excuse for not fixing the error.
| kernal wrote:
| A password manager with a built-in MP3 player? That's my next
| project.
| Brian_K_White wrote:
| The songs could tell you where to find the post-it note
| within your record library. Let the hackers gain access to
| your google drive AND decrypt the db. :)
| Latty wrote:
| Safest by what metric? Calling the browser integration a
| "convenience" feature only is just fundamentally wrong.
|
| Realistically the most common attack most users face is a
| phishing attack, removing the browser integration which checks
| the URL programmatically before filling the password opens the
| user up to being phished more easily (users check URLs less
| consistently and less reliably), so arguably this makes the
| package less secure in the real world.
| Spivak wrote:
| Debian is somewhat inconsistent with this but it does have
| precedent for package to be package-minimal and a corresponding
| full- variant.
|
| Odd to just break users by doing this, should have been done
| with a major release when people expect breakage.
| aragilar wrote:
| Uh, it's only changed in unstable, so it will be a major
| release when current testing is released.
| rfoo wrote:
| Title is wrong. The original post said maintainer has removed ALL
| features, not only networking features, and this was true, ALL
| optional features, including entirely offline features, were
| turned off during build.
| jchw wrote:
| Considering it would be completely possible to make this
| distinction _without_ breaking existing users, it 's difficult to
| see this as anything other than a bad decision by the Debian
| package maintainer. While having the ability to have KeepassXC
| without networking features is certainly nice, considering the
| browser integration to be a niche feature is just severely out of
| touch; I would be willing to place real money on betting that
| more than half (probably _well over_ half) of users of KeepassXC
| in Debian today want features that will be surprise-disabled
| because the maintainer chose a way of doing this that would break
| existing users to impose their opinion.
|
| It is ultimately their decision to make, but that doesn't mean it
| is a good one, I contend it is not.
| kernal wrote:
| I like this solution. He reduced the attack vectors in the base
| application by removing features a large majority of people don't
| use. And if they want these additional features then download the
| full version.
| nulld3v wrote:
| > features a large majority of people don't use.
|
| I would be shocked if this was true. I have recommended
| KeepassXC to many of my friends and family and they all use at
| least one of the features that was in the removed list. To be
| fair, none of them use debian, but some of them do use other
| Linux distros.
|
| I don't use debian on desktop anymore on my main machine, but I
| did use BunsenLabs for a long time and even back then KeepassX
| (and afterwards KeepassXC) auto-type was a critical feature I
| used literally every day.
| gr4vityWall wrote:
| I never knew KeepPassXC could talk with my browser or
| interact with ssh until I saw this thread, and I've been
| using it for almost 10 years now.
| coppsilgold wrote:
| I have already been using bubblewrap[1] to isolate KeePassXC from
| the network and more (the only access it has is to its own
| private directory and a hardened Wayland socket[2]). I wouldn't
| recommend relying on devs or maintainers to do application
| isolation work for you.
|
| [1] <https://github.com/containers/bubblewrap>
|
| [2] <https://git.sr.ht/~whynothugo/way-secure>
| 0x_rs wrote:
| I would like to believe package maintainers should operate under
| a principle of least astonishment and not disable core features
| (and not plugins, despite currently 25 entries of that word in
| this comment section) unless there's a documented or at the very
| least probable risk, none of which seem to be the case here.
| KeePassXC has many features but none that would on their own, and
| without explicit user intervention, be a likely source of
| vulnerabilities. The browser integration must be toggled on
| before you can even set it up, likewise for (I believe) every
| other function disabled with this flag, so a -minimal package may
| have been more appropriate. The small subset of users that could
| benefit in some indeterminate future from this change must be
| incredibly small, while it's going to be a serious annoyance for
| anyone using the browser integration, a function that's generally
| far safer than clipboard access. It also doesn't feel in line
| with the project's vision:
|
| _Our goal is to create an application that can be used by anyone
| while still offering advanced features to those that need them._
| DDiggler wrote:
| Meanwhile in Arch land (possibly other distros as well), the
| fwupd package (which I imagine to be a fairly common package to
| be installed among the user base) has been silently configured to
| depend on passim, which spins up an open web server on
| 0.0.0.0:27500[1] without any(!) explicit user consent whatsover.
| Passim then uses GnuTLS, which is famous for containing more
| holes than Swiss cheese [2][3].
|
| Absolutely insane to me, and I would not be surprised if there's
| an xz type of exploit hidden somewhere in the chain.
|
| [1]: https://github.com/fwupd/fwupd/issues/6721
|
| [2]: https://news.ycombinator.com/item?id=7347500
|
| [3]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls
| workethics wrote:
| Good to know. I think this should probably be it's own post
| 1oooqooq wrote:
| https://news.ycombinator.com/item?id=40322408
| 1oooqooq wrote:
| why fish for fwupd? systemd-resolved which is everywhere, will
| open (at request) an LLMNR server (a.k.a. mDNS, nee microsoft
| netbios) on port 5355.
|
| With IoT everyone have access to your LAN, so now people are
| making sure linux also join the REDACTED party
|
| btw, fix for fwupmdg, since they have a low quality default
| conf file without commented out defaults: ```
| # /etc/fwupd/fwupd.conf [fwupd] P2pPolicy=none
| ```
|
| fix for resolved is commented out on /etc/systemd/resolved.conf
| `LLMNR=no`, and you probably also want `DNSStubListener=no`.
| heck here is a good default ``` #
| /etc/systemd/resolved.conf [Resolve]
| DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net
| 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
| FallbackDNS=127.0.0.1 ::1 Domains=~.
| DNSOverTLS=yes LLMNR=no DNSStubListener=no
| ```
| 1oooqooq wrote:
| looking at the fwupmgr code.
|
| The client uses DBUS to ask the server how many bytes were
| download from your LAN peers (unless you connect your device
| directly to the internet, then i guess i will show how many
| bytes ssh probes downloaded from you, inflating their numbers
| and making them more aggressive on the server feature)
|
| https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa.
| ..
|
| https://github.com/hughsie/passim/blob/ae38c13da1a63fff8c8fa.
| ..
|
| also, note the quaint code to tell how much carbon it saved
| earth.
|
| edit: interestingly, if you search for that data collection
| method name, both ddg and google only find the call from
| fwmgr side. the actual one, older, from passim code is not
| shown anywhere
|
| https://duckduckgo.com/?q="passim_client_get_download_saving.
| ..
|
| but it's there https://github.com/hughsie/passim/blob/ae38c13
| da1a63fff8c8fa...
| AceJohnny2 wrote:
| > _mDNS, nee microsoft netbios_
|
| veering offtopic: I always thought mDNS was an Apple thing,
| since Bonjour is the most extensive implementation of it (and
| Windows sucks at it. In fact the only way I found to get a
| full mDNS implementation on Windows a few years ago was to
| install Bonjour via an installer _extracted from iTunes for
| Windows_ ).
|
| The Wikipedia page for mDNS [1] doesn't have a lot of history
| information, saying just that the idea of mDNS was first
| proposed by Bill Woodcock & Bill Manning to the IETF in 2000,
| and neither seem obviously tied to Microsoft. Apple later
| published Bonjour in 2002, and mDNS only became an official
| rfc6762 in 2013!
|
| [1] https://en.wikipedia.org/wiki/Multicast_DNS
| 1oooqooq wrote:
| Because the history is not linear. See
| https://techcommunity.microsoft.com/t5/networking-
| blog/align...
|
| it goes like this:
|
| 1. MS uses netBios.
|
| 2. apple uses bounjour, similar to netbios, but with modern
| conveniences, like NAT aware.
|
| 3. windows add same niceties on top of netbios and call it
| LLMNR.
|
| 4. apple standardize bounjour as mDNS and open it up just
| because they would have to publish code because of some
| licenses they offended (but going into this is veering way
| too much offtopic on your offtopic)
|
| 5. everyone standardize on mDNS
|
| 6. RedHat (using their fake open source promotion called
| freedesktop, nee XDG) pushes for LLMNR for god knows why!
| (well, might be a reason poetering works for MS now)
|
| 7. even microsoft abandon LLMNR and netbios in favour of
| mDNS. everyone is using mDNS. RH/freedesktop/systemd/fwmg
| (all the same people) chose to base their LAN distribution
| service logic on LLMNR.
|
| 8. RedHat works backward compatibility of LLMNR into mDNS
| and things get VERY confusing. Or not. Their documentation
| uses the name interchangeably and honestly, at this point I
| am not sure of anything and I'm not paid to look at that
| code for over a year. I wouldn't be surprised if resolved
| is actually using mDNS but the setting/code is still just
| "called" LLMNR. /shrug.
| rationably wrote:
| Thank you, Internet stranger. This LLMNR/mDNS dichotomy
| has been on the back of my mind for quite some time.
| You've made it clear.
| 1oooqooq wrote:
| ur welcome. parts of it are in the zero conf wikipedia
| page btw.
| tuetuopay wrote:
| So in the end they reduced the attack surface for a program
| running on your computer by increasing the attack surface on the
| meatbag operating the computer? (i.e. browser integration which
| is the only effective thing against phishing)
|
| Seems like a good deal /s
| cyanydeez wrote:
| This reminds me of the how to secure a trashcan from bears in
| yellow stone: the dumbest person and the smartest bear has
| significant overlap.
|
| Protecting a few dumb people means exposing a lot more people
| to attack vectors.
| lawn wrote:
| From a KeePassXC maintainer:
|
| > In the lead up to this thread I received three reports of this
| new package method crippling people's workflow. One report was a
| user who couldn't open their database anymore because the yubikey
| feature was removed. Let that sink in for a second. People who
| lose access to their most important secrets can sometimes do
| irrational things in the moment of panic.
|
| https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
| guilhas wrote:
| Everyone using an offline password manager without having a
| backup might as well consider everything lost
|
| This sounds like emotional blackmail
|
| How many times I lost everything, hardware failure, updates
| that broke OS, using dd in the wrong drive...
| valicord wrote:
| How would a backup help in this scenario? The data is fine,
| it's the application that stopped working.
| guilhas wrote:
| If the yubikey stops working, you also loose access to the
| database
|
| So I would have a backup with a simple password, or even
| unencrypted in a USB somewhere
| valicord wrote:
| You backup the yubikey seed (whatever it's called)
| separately from the password db, so that the attacker
| still has to get 3 separate pieces of information (db,
| password, seed) to get the full access.
| TheChaplain wrote:
| What is the big issue? The maintainer put up two packages, one
| stripped down and another with full functionality.
|
| I'd say it's really good to have options so the user can choose
| themselves.
| SAI_Peregrinus wrote:
| They made the default the stripped-down one, which removes
| security features like the anti-phishing prevention in the
| browser extension.
| shmerl wrote:
| There was some comment about it. Basically, it's for security
| reasons. Those who aren't using those features wouldn't expect
| them to appear (especially sneakily). And those who are planning
| to use them will figure out what package to install.
|
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
|
| This was the message from maintainers:
| 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.
| Dylan16807 wrote:
| Browser integration and autotype are not feature creep.
|
| Making everything copy-paste is bad for security.
| nsajko wrote:
| Horrid PR for Debian. The decision is ignorant and capricious and
| makes Debian seem like a personal toy project instead of a FOSS
| cornerstone. On top of that the Debian maintainer then responds
| by calling upstream "crappy".
| gradientsrneat wrote:
| Said maintainer also does dev work for Canonical. So this
| probably affects optics for Ubuntu too. Although, speculating
| charitably, maybe the maintainer knows something we don't about
| the upstream's security policies.
| FdbkHb wrote:
| Debian maintainers are experts at touching things they
| shouldn't and creating a mess in the process. The worst case,
| by far, was when they broke the RNG of SSH key generation:
|
| https://jblevins.org/log/ssh-
| vulnkey#:~:text=In%20May%202008....
|
| Those guys are out of control and constantly having conflicts
| with upstream, I'm astounded to see the amount of support I see
| for debian in this thread.
| cookiengineer wrote:
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
|
| I don't think the Debian maintainer is aware that the favicon
| download feature is optional and manual. You literally need to
| press a button labelled "Download favicon" before it connects to
| the internet.
| vbezhenar wrote:
| This maintainer does not respect upstream developers. He must
| step down and pass this package to someone who respects the
| upstream developers and their judgement. He must not keeping this
| name hostage and damaging the brand.
| gr4vityWall wrote:
| The maintainer's position seems reasonable to me. A different
| package, compiled with the network features, is provided too. I
| like this as a default.
| xcdzvyn wrote:
| Fortunately Debian maintainers have a fantastic track record of
| writing ad-hoc patches for security-sensitive software.
| hi-v-rocknroll wrote:
| I abandoned KeePassX (pre XC fork) when they made wonky changes
| ~10 years ago.
|
| Use Bitwarden (optionally run your own sync server) or Keeper
| (for less technical people).
| hiAndrewQuinn wrote:
| I recently switched from BW to XC in the wake of their
| acquisition, and I have to admit, the mobile experience is just
| a little more annoying. But I sleep better at night knowing
| that I don't keep anything critical on servers I don't own.
| hi-v-rocknroll wrote:
| 1. What acquisition? https://bitwarden.com/blog/
|
| 2. You can run your own FOSS Bitwarden sync server. It even
| works airgapped.
|
| https://bitwarden.com/help/install-and-deploy-offline/
| yawaramin wrote:
| A password manager without browser integration is essentially
| dead in the water. Seems like what they're shipping is unusable
| for most people. We all know 'unusable FOSS' cliche but in this
| case it actually applies.
| parasti wrote:
| It's crazy the amount of power maintainers hold over someone
| else's software. This reminds me of the time when Fedora
| maintainers disabled GLES1 support in Mesa because "nobody should
| be using it anymore (there are newer OpenGL versions)",
| disregarding the fact that GLES1 was well and fully maintained
| upstream, and was and is still the only option on many devices.
| YPPH wrote:
| >power maintainers hold over _someone else 's_ software
|
| There's some subtle assumptions about ownership in this comment
| that aren't accurate, insofar as free and open source software
| is concerned.
|
| FOSS software is not "someone else's" software. They may own
| the trade mark, but by releasing the software under a FOSS
| licence, they lose the right to control the direction the
| software may take. I'm free to copy it, edit it, and
| redistribute it as I see fit. So are you. So is Debian.
| parasti wrote:
| That's besides the point. You can do whatever with the
| software, but it gets muddy when you then release it under
| the same name as the original. That name may not be
| trademarked, but it is still not yours to use.
| YPPH wrote:
| This simply is irrelevant. A FOSS licence fully permits
| what Debian has done here. So, _that_ is beside the point.
| kasabali wrote:
| Not even comparable. Debian users can choose between the
| stripped and full version of Keepassxc, unlike the MESA example
| above.
| raverbashing wrote:
| Hissy-fits like these are one of the reasons there's never going
| to be a "year of the linux on desktop"
|
| But why do they care, right? Most people on their irc channel
| (that have a basement NAS may I add) agree with their decision.
|
| Now my bet is that your average Debian user does care about
| convenience. Replacing (default off) selection boxes with
| different sw packages is acceptable in only a minority of cases,
| and doesn't seem to be the case here.
| danpalmer wrote:
| We used to deploy on Debian at my previous place, and we hit this
| sort of shit all the time. Maintainer ripped out features they
| disagreed with (political reasons, or just engineering/product
| taste), maintainers changing the configuration files to things
| that suited them better, etc.
|
| I understand it's all volunteer work, I understand it's open
| source so anyone can add their own custom packaging, on top, but
| Debian (the OS) certainly uses the ecosystem as a selling point,
| and it really can come back to bite you.
| rationably wrote:
| Could you provide an example where maintainer "ripped out" a
| feature because of a strictly political reason?
| juliangmp wrote:
| I have a lot of respect for the Debian project but every now and
| then one of their maintainers does something completely stupid
| and unreasonable and expects applause
| egberts1 wrote:
| Should bave left the original KeyPassXC Debian package alone and
| ...
|
| Instead to create a `keypassxc-offline` package with those
| tweaks.
___________________________________________________________________
(page generated 2024-05-11 23:02 UTC)