@juliank @tuxwise @keepassxc You went into their GitHub...

1. Please leave my employer out of it. That's crossing a line.
2. It's entirely normal to refer to stuff considered superfluous as crap, at least in German, that's quite a normal expression.
3. I wrote this quickly after waking up before hopping on a train and a plane to be nice and let them know that there's no going back. That doesn't mean there's no way forward.

1/2

Expand text...

11 May at 7:42 | Open on mastodon.social

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

11 May at 7:44 | Open on mastodon.social

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

11 May at 7:52 | Open on mastodon.social

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.

11 May at 7:56 | Open on mastodon.social

varjolintu

@juliank
"People just are acting very suspicious, trying to push new features or new upstream releases in without giving it any review or thought."

"The upstream developments have been very concerning, I can't be the only one feeling that way."

Could you elaborate these a bit?

11 May at 9:31 | Open on mastodontti.fi

@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

11 May at 10:16 | Open on mastodon.social

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

11 May at 10:20 | Open on mastodon.social

https://pages.nist.gov/800-63-3/sp800-63b.html

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

11 May at 10:23 | Open on mastodon.social

varjolintu

@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?

11 May at 10:36 | Open on mastodontti.fi

Julian Andres Klode 🏳️‍🌈 replied to varjolintu

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

11 May at 10:40 | Open on mastodon.social

Julian Andres Klode 🏳️‍🌈 replied to Julian Andres Klode 🏳️‍🌈

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

11 May at 10:42 | Open on mastodon.social

varjolintu replied to Julian Andres Klode 🏳️‍🌈

@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?

11 May at 10:47 | Open on mastodontti.fi

Julian Andres Klode 🏳️‍🌈 replied to varjolintu

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

11 May at 10:53 | Open on mastodon.social

Julian Andres Klode 🏳️‍🌈 replied to Julian Andres Klode 🏳️‍🌈

@varjolintu Optimally I'd go a step further:

- make keepassxc open files using portals (it might already, I don't know)
- write an AppArmor profile that only allows r/w configuration files, and read access to /usr

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.

11 May at 11:00 | Open on mastodon.social

varjolintu replied to Julian Andres Klode 🏳️‍🌈

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

11 May at 11:01 | Open on mastodontti.fi

Ian Douglas Scott replied to Julian Andres Klode 🏳️‍🌈

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

13 May at 3:35 | Open on fosstodon.org

varjolintu replied to Julian Andres Klode 🏳️‍🌈

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

11 May at 10:46 | Open on mastodontti.fi

James Bennett

@juliank @tuxwise @keepassxc You work for a company that maintains a distro on which you are a core developer. That is relevant, especially because it makes it harder to hold you accountable for your bad actions: people might feel threatened by the power of your employer in the open-source world and let you get away with bad actions that others would not get away with.

And while it may be quite normal for a German to insult other people, it is quite normal for an American to say someone who does a bad job should be fired. Respect for culture must go both ways!

(though all the Germans I am friends with are generally quite nice people who do not go around insulting others, so perhaps it is not something you can blame on culture)

And if you are saying "there's no going back”, that means you are not open to discussion or to having arguments presented which would change your mind or change your actions. This should disqualify you from a position where you make decisions that impact other people.

You are a distro maintainer. You can decide to package something or not to package it. You should not decide to package something and also effectively fork it in the distro package because you do not like the choices the developers made. If you disagree with their choices, go to them and present your arguments and try to convince them to change. If you do not convince them, you can always perform a real fork and promote your fork.

Above all, what you should NEVER do is abuse your position as a distro maintainer and employee of a distro company to force your preferences onto someone else’s project against their will. But that is exactly what you did. If you called your package “Julian's KeePassXC Fork” and lobbied to have Debian include it, that would not be a problem. But you call your package KeePassXC and prevent the real KeePassXC from being allowed into Debian, just because you prefer to make people use Julian's KeePassXC Fork. That is a problem.

And, again, features like checking against databases of compromised passwords are strongly recommended best practices. See, for example, section 5.1.1.2 here:

I direct you again to my previous post suggesting what actions you should take.

Expand text...

Screenshot of NIST Special Publication 800-63B, “Digital Identity Guidelines”, section 5.1.1.2, highlighting this text:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

* Passwords obtained from previous breach corpuses.

* Dictionary words.

* Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

* Context-specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

11 May at 8:18 | Open on infosec.exchange

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

11 May at 8:25 | Open on mastodon.social

James Bennett

@juliank @tuxwise @keepassxc The situation is untenable because you made it that way. You have decided that you know better than upstream.

This is sadly something that Debian maintainers have a history of doing with many projects, not just this one, and has caused many headaches for upstream maintainers who only find out from the deluge of bug reports that Debian broke their software.

Debian should not in general do that and you personally should not do that. You should package something that would cause the least surprise to someone migrating onto your package from an installation performed some other way. Or, if you are not willing to do that, you should step down and make room for someone who will do a better job.

@juliank @tuxwise @keepassxc The situation is untenable because you made it that way. You have decided that you know better than upstream.

Expand text...

11 May at 8:32 | Open on infosec.exchange