|
Top-level
@keepassxc An exceptionally bad decision to wreck a huge existing installation base, "because I can". The rude reply by @juliank is condescending, and far from what I am used to read. https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817 54 comments
@juliank @tuxwise @keepassxc I fall into this category, though I would obviously like to think I'm unique. Either way, you mentioned taking the time to make a desicion, and yet the upstream devs seemed to have been caught completely by surprise. That really shouldn't happen for what I hope are obvious reasons. What went wrong here? Did they just ignore all your communications and deliberations about this decision?  @mvgorcum It's a question for the Debian project I polled other Debian developers on IRC. We already knew upstream's position on this. Could I have communicated it to them? Sure. Did they abandon IRC years ago? Yes. Well there's some weird Heisenbridge thing but it's WEIRD and nobody has talked to me for years. ๐คทโโ๏ธ I barely have the energy to package new versions, seeking out and engaging with upstream on these grounds on downstream decisions is a tad much. @juliank @tuxwise @keepassxc I don't run debian testing, so I hadn't run into this yet, but I would certainly have gone to upstream when I saw this breaking change. I would argue that at least doing them the courtesy of a heads up would be the decent human interaction thing. It may have allowed them to join the discussion, and possibly made my life easier as a user, but certainly their life easier. Adversarial packaging is allowed by GPL, but wouldn't that be a last resort? @juliank @tuxwise @keepassxc on a related note: this whole thing must not be fun, I do appreciate that this gives you a lot of work that you didn't really ask for. Thank you for packaging keepassxc and spending the time, and I'm sorry you have to deal with loads of people having opinions on your choices, that's never fun... @mvgorcum @juliank @tuxwise @keepassxc also im unsure how this improves security. Any user who finds out about this will just immediately move to the full release. Adding a โliteโ package would have been better. @juliank @mvgorcum @tuxwise we have multiple, MULTIPLE, means to get in touch with us. We moved to matrix years ago, but still bridge to IRC. Easily found through our Readme. Sorry this went down this way but it does end up having a huge negative impact on us when downstream shit breaks unexpectedly. @juliank @tuxwise @keepassxc I will not repeat your extremely rude vocabulary here, but leave that for interested parties to look up, since it is documented at github. โStable release users should read the release notes.โ No they shouldn't. That's exactly why they use stable: so things don't break unexpectedly and they can work on problems that they want/need to work on. @stardust @tuxwise @keepassxc That's a misunderstanding, they should read the release notes when upgrading to the next release @juliank @stardust @tuxwise@tchncs.de I disagree with this statement on a fundamental level. If you see Debian as an expert tool for a very specific expert target group, then fine, whatever. But Debian is the base for a general-purpose operating system for millions of users with no technical background or simply no nerve and time to deal with things like this. You cannot and should not expect these users to know about any obscure text files, let alone read and understand the tech babble that's in them. @juliank @stardust @tuxwise@tchncs.de I certainly don't fire up a text editor and check the NOTES files first before I run apt upgrade or click the "Install now" button on the update reminder popup and I am probably much more of an expert user. We can only implore you to revert your decision. Your concerns about supply chain attacks in particular are certainly not unfounded, but you cannot export the complexity of this decision to your users in a way they will not and cannot understand. @keepassxc I think renaming the package to keepassxc-minimal will make it much clearer, and I'll try to do that and I hope it gets accepted. I'm very torn on the upgrade path with a transitional keepassxc package, we can depend on keepassxc-minimal|keepassxc-full or the other way around. Once we drop the transitional package is when things become nice: apt install keepassxc will tell you that there's a minimal and a full, and you can select it. 4. If I could step down from maintaining it I would. My KeePass database stores a handful of high value passwords and the password to my Bitwarden where the majority of day to day password lives so I can use it on all devices. People just are acting very suspicious, trying to push new features or new upstream releases in without giving it any review or thought. *This* would be breaking the trust implied in my relationship with my users. 2/3 5. Checking against online password databases can be nice to have but sadly we can't have everything and it's misaligned with being a local database password manager. We are talking about a tool where you have to manually synchronise your password databases over your myriad of devices. Only die hard security fanatics would use such a contraption in the first place. 3/4 6. This did not happen in an instant but you can clearly see it took over a year to reach this point where the plan could be finalised and executed. The upstream developments have been very concerning, I can't be the only one feeling that way. In fact I know I'm not the only one feeling that way because I've had users tell me. Actually security engineers too. @juliank "The upstream developments have been very concerning, I can't be the only one feeling that way." Could you elaborate these a bit? @varjolintu What happens with keepassxc packaging is exactly the same thing what happened with xz-utils. People demand new upstream releases getting merged quickly, some with upload rights threaten to upload them themselves, people "helpfully" package new upstream versions for you. I employ a 0 trust model, so I need to redo it all anyway to make sure it was not tampered with. Now they may be honest, but after being burned out by time_t and then xz-utils you can understand I'm very cautious @varjolintu On the upstream side, I think there's some misalignment between various fractions. I need my password manager to manage my passwords. In fact I use keepaasxc only for high value targets, like my backup encryption keys, or the key to my day-to-day bitwarden account (as I need the sync to Chromebooks, family account sharing, etc, I do self host a vaultwarden for it). @varjolintu There are several people like this, and what they are looking for is not a constant influx of new features or large changes to fix bugs. And that to me is the most logical choice. You went to all that trouble to pick the hardest to use (across devices) password management solution in the world, you're paranoid and trust nobody, you don't suddenly want to poke holes in it for convenience like browser extensions, just use the clipboard, it's much more secure. @juliank As far as I know, clipboard can be accessed by any application, especially in Windows. Encouraging to use it instead of more secure alternatives might not be the way to promote any "secure defaults". Speaking of password managers in general, as a Bitwarden user, do you think their browser extension and Vaultwarden is more secure than KeePassXC's browser integration that works only locally? Or are you using only clipboard with Bitwarden too? @varjolintu No I do not think Bitwarden is more secure. I only trust it with 2nd tier passwords, most web accounts. It is more secure in the context that I don't need to keep my high security KeePass database open. But then one could have two databases. But I wouldn't trust my backup encryption keys, to it, or my Google account 2 factor code. @varjolintu The clipboard thing is a bit annoying, as far as I understand it's privileged in Wayland to some extent, and the autotype doesn't work there. But having one password in there for 15s, that a malicious software would need to correlate with what you are doing to find out what it's for is very much a better choice than exposing APIs to query any password IMO. @juliank There's an API but it isn't exposed in a way that anyone could query something from it without user knowing about it. Plus it only works locally and is not exposed to outside world. Is these one of the features that are insecure in your opinion? @varjolintu I understand there are some access controls, but they can be buggy. A bug in the browser extension IPC access control could reveal your entire database to your browser. If you don't have the means to query the database from other processes the entire attack vector goes away. i.e. keepassxc-light or whatnot could only ever have critical CVEs if it messed up the database encryption. @varjolintu Optimally I'd go a step further: - make keepassxc open files using portals (it might already, I don't know) Then you can select databases, key files, and work with them and rest assured that even if keepassxc core is compromised (whether that's a new malicious maintainer sneaking in, or a gcc backdoor ๐) it can't talk anywhere else. @juliank There are already a few PR's waiting for 2.8.0 that will reduce the possibility of such attacks. One is storing access related settings directly to a database instead of a config file. Another one allows restricting processes that can access the database. Revealing the entire database without user knowing it would be very difficult even now. Are you concerned about the possible attack vectors on Bitwarden? With multiple dependencies, and as an Electron application it has its downsides.  @juliank @varjolintu In theory access to the clipboard on Wayland is limited to the focused window, though in practice this isn't really secure (on most compositors), since compositors tend to give focus to windows when they are created. Something like wl-copy/wl-paste exploits this with a small temporary window. @juliank Are there some memory issues with keeping KeePass database open we are not aware of? It should be much more protected than a browser's memory. @ubernostrum you seem to mistake there's no going back for something it isn't but it means the situation was untenable. I do not have a problem offering an explicit choice between a keepassxc-minimal and a keepassxc-full package. Anyway, right now, keepassxc packages the default build flags, and keepassxc-full passes the option to turn additional features on. We're not at the outrageous territory where we need to take defensive measures by patching code, yet anyway.  @tuxwise @juliank @keepassxc I don't think so, and many users in the discussion agree. If most users use only a small subset of the functionnality, then the smart secure move is to provide it and make it the default. Now it would be better if Keepassxc showed a message saying that that version is the minimal one, and that a full one is available, but that's not in the hands of the debian maintainer. I was not referring to providing a minimal and a full version, to which the original developer agreed to as well. As you can easily see from actually reading what I wrote, I criticized the rude tone, and the wrecking of the implied contract with those who have installed the existing package. And I stand by that. @tuxwise @RLetot @keepassxc I was just being courteous, signing in on my phone and giving a short reply while travelling. The concern is that somebody leaves or somebody new comes and picks up a subsystem and eventually maintains it on their own because the others don't actually use it and then believe the subsystem expert. That's somewhat normal. This opens the doors for malicious actors to appear and compromise less popular subsystems. 1/2 @tuxwise @RLetot @keepassxc Hence I did not want to expose new users to optional subsystem code by default. This seems a reasonable stance. It is what Debian users generally expect. Sadly I could not do that without breaking some users existing functionality. I can add a debconf dialog on upgrades to tell you more explicitly. I will have to think about how we can solve this better in the future for similar situations (upgraded get X, new gets Y), but this requires new apt features. @tuxwise @RLetot @keepassxc We can also rename the existing package to KeePassXC-minimal and then remove the keepassxc package. Then users will get a message from apt when doing install keepassxc that tells them it's provided by either. But anyway I hope this longer explanation seems less rude to you, I had to sit down in the middle of a city trying to get it out on my phone. I personally wouldn't mind and would in fact choose to use the minimised version with all those things removed, aside from the YubiKey support. That's the only part that seems a bit odd... All the other features, though? I would happily use the "feature-less" version. (would *strongly* opt for it, in fact, if it did still have YubiKey support) There is no point in continuing to discuss with you if you now call your rude tone "courteous" and think that deflecting from that tone by adding more and more reply text will somehow cover up your foul language. You are muted now, don't bother to reply. @tuxwise @keepassxc I know that English is not my language, so maybe I missed something, but where is there foul language from @juliank ??? @tuxwise What in the ever loving F... are you talking about? Please quote @juliank being rude. @tuxwise sorry, but I find your tone a lot more rude and condescending than what I read from @juliank. You want more respect from people ? Maybe start by respecting them yourself. Bye. @keepassxc |
Gregory's Server
@tuxwise @keepassxc why do you think it's rude and condescending?
The first thing Debian users should be looking at when something changes unexpectedly is the /usr/share/doc/<package>/NEWS.Debian.gz
That is the way breaking changes are communicated. Users of testing/unstable are expected to have apt-listchanges installed to see them automatically.
Stable release users should read the release notes.
People annoying upstream isn't something I can solve.