Live data from Hacker News

KeePassXC Debian maintainer has removed all network features

fosstodon.org

291–300 of 367 posts

Re: KeePassXC Debian maintainer has removed all network features

#291
post #287

Earlier quoted context omitted.

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.

> 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. A…

>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.

Re: KeePassXC Debian maintainer has removed all network features

#292

Earlier quoted context omitted.

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…

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.

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.

Re: KeePassXC Debian maintainer has removed all network features

#293

Earlier quoted context omitted.

Package maintainer != Project maintainer. In this instance the maintainer of the Debian package for KeePassXC has unilaterally made a choice.

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…

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.

Re: KeePassXC Debian maintainer has removed all network features

#294

Earlier quoted context omitted.

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…

> 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, sayin…

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.

Re: KeePassXC Debian maintainer has removed all network features

#295
post #138

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/keepassxre…

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...

How would a backup help in this scenario? The data is fine, it's the application that stopped working.

Re: KeePassXC Debian maintainer has removed all network features

#296
post #80
post #52

Earlier quoted context omitted.

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.

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.

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".

Re: KeePassXC Debian maintainer has removed all network features

#297

Earlier quoted context omitted.

> 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, sayin…

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…

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.

Re: KeePassXC Debian maintainer has removed all network features

#298

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 (t…

Could you provide an example where maintainer "ripped out" a feature because of a strictly political reason?

Re: KeePassXC Debian maintainer has removed all network features

#299

Earlier quoted context omitted.

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).

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…

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.

Re: KeePassXC Debian maintainer has removed all network features

#300
post #52

Earlier quoted context omitted.

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.

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…

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.
Post reply on HN