Email or username:

Password:

Forgot your password?
Top-level
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:

pages.nist.gov/800-63-3/sp800-

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

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.
3 comments
Julian Andres Klode 🏳️‍🌈

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

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.

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.

Go Up