Julian Andres Klode, Entwickler bei Debian und Ubuntu sowie Betreuer des Passwortmanagers KeePassXC bei Debian reagierte kürzlich auf einen Bug-Report aus dem Jahr 2020 und entfernte aus Sicherheitsgründen alle Netzwerkdienste und die Interprozesskommunikation aus Version 2.7.7+dfsg.1-2 des Pakets keepassxc, das sich derzeit in Debian Unstable befindet.
In der Paketbeschreibung des aktuellen Pakets heißt es unter anderem:
Dieses Paket enthält nur das absolute Minimum an Funktionalität und keine Sicherheitskomplikationen wie Netzwerk, SSH-Agent, Browser-Plugin, fdo-Geheimnisspeicher. Siehe keepassxc-full, wenn Sie diese unbedingt benötigen.
Browser-Integration fehlt
Das bedeutet unter anderem, dass die Browser-Integration von KeePassXC, die zum automatischen Eintragen von Credentials nötig ist, nicht mehr funktioniert. Wer künftig diese und andere zusätzliche Funktionen nutzen möchte, muss das Paket keepassxc-full installieren. Auch bei Bestandsanwendern werden mit dem Update auf Version 2.7.7+dfsg.1-2 diese Funktionen entfernt, was aus mehreren Bug-Reports gegen KeePassXC hervorgeht. Das ist problematisch, da es im Allgemeinen ein Verstoß gegen die Debian-Richtlinien darstellt, wenn ein Upgrade bestehende Funktionalität zerstört.
Community nicht erfreut
Die Meinung des Maintainers geht dahin, dass solche Funktionalität nichts in einem Passwortmanager zu suchen haben. Damit macht er sich in der Community von KeePassXC auf GitHub keine Freunde. Deren Bitte, das Originalpaket doch im alten Zustand zu belassen und eine abgespeckte Version ohne die beanstandeten Funktionen zu erstellen, lehnt er ab. Seine Begründung lautet:
Es ist unsere Verantwortung gegenüber unseren Benutzern, ihnen die sicherste Option als Standard anzubieten. Alle diese Funktionen sind überflüssig und gehören nicht wirklich in einen lokalen Passwort-Datenbank-Manager, diese Entwicklungen sind alle völlig fehlgeleitet.
Benutzer, die diesen Mist brauchen, können die beschissene Version installieren, aber das erhöht natürlich das Risiko von Drive-by-Attacken.
J. A. Klode https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817
Antwort steht aus
Auf die Nachfrage von vor zwei Tagen, welche Sicherheitsprobleme er im Einzelnen sieht, hat Klode bisher nicht geantwortet. Die entfernten Funktionen sind im bisherigen Paket nach der Installation standardmäßig deaktiviert, es liegt beim Anwender, ob er sie nutzen möchte oder nicht.
Was ist denn das wieder für ein Sturm im Wasserglas über eine im Grunde Nichtigkeit.
Es gibt doch ein -full paket, also ist doch alles gut? Im Notfall auch ein flatpak.
Es gibt doch jede Masse Software die je nach Distri von den Maintainern unterschiedlich, z.T. sogar in unterschiedliche Pakete verteilt ausgeliefert wird.
Es geht nicht darum, dass ein Paket abgeändert wird, sondern um die Art, wie das geschah. Wenn das in Testing und Stable landet, werden Tausende Anwender, die einen Computer lediglich als Mittel zum Zweck benutzen, vor den Kopf gestoßen, weil gewohnte Funktionen nicht mehr verfügbar sind, ohne dass sie verstehen, warum. Oder will Debian solche Anwender nicht?
Naja Debian selbst wirds egal sein, denn man verdient ja mit der Distro eh kein Geld vom Anwender und dann gibts ja noch euch oder die ppa.
Also alles kein Thema.
Sie sollten KeePassXC komplett aus den repos nehmen, statt diesen Kauderwelsch zu veranstalten.
Ich glaube nicht das es Debian egal ist und dabei spielt es keine Rolle, ob die Geld damit verdienen oder nicht.
Ich sehe das so wie Ferdinand. Es geht mal wieder um die SRT und Weise wie etwa geändert wird. Das geht gar nicht!
Natürlich gibt es das “*-full” package oder Flatpak oder, oder, oder. Was passiert wenn ich Upgrade? Mein Paket wird sang und klanglos ersetzt. Was dann? Manuell austauschen oder was?
Das ist shit und bleibt shit!
Hoffe da passiert noch etwas.
Warum? Wo ist das Problem? Du kannst es doch exportieren und in die neue Instanz importieren und fertig.
Weis nicht, wo ihr da Probleme seht.
Wie ich schon sagte besser waere es eigentlich, wenn sie das Paket ganz entfernen wuerden.
Andere Moeglichkeit waere, das Paket als hold kennzeichnen, dann wird es nicht beachtet beim Upgrade.
Du darfst nicht von dir ausgehen, sondern vom technisch nicht versierten Anwender. Dem fehlen plötzlich nach dem Update gewohnte Funktionen. Der liest keine Blogs oder Changelog-Einträge. Der muss jetzt Zeit aufwenden, um herauszufinden, was los ist und den Schaden zu beheben, den ein Maintainer mit seiner rüden Art angerichtet hat. Ich schätze die Arbeit von Andreas Klode z.B. bei APT sehr, aber hier hat er daneben gegriffen.
Ja ich verstehe Dich da schon und bin da auch zu einem Teil bei dir. Nur sind wir hier bei Linux, d.h. der user muss sich schon etwas damit beschaeftigen.
Und mal in eine Suchmaschine eingeben und lesen sollte man von einem Linux user der Debian nutzt schon erwarten koennen.
Fuer alles andere gibts derivate oder andere Distributionen, die den user an die Hand nehmen. das ist und war nie die Aufgabe bei debian.
Mit dr Art und weise bin ich auch nicht zu frieden. Paket rausnehmen aus dem Repository und gut ist. Haette keinen Staub aufgewirbelt.
Ich habe erst einmal kein Problem …noch nicht. Ich finde einfach die Art und Weise nicht gut. Ich glaube das ein anderer Weg besser wäre.
Ich würde mich zwischen User mit Anspruch und etwas fortgeschrittener bezeichnen und wenn hier nicht immer wieder solche Berichte wären, würde das ein oder andere an mir vorbei rauschen.
Ich bin nicht der User, der sich durch Mailinglisten wühlt oder Blogs verschlingt.
Das könnte dann tatsächlich in einem solchen Fall zu einem Thema werden.
In frühen Jahren mit Debian habe ich heftigeres durchlebt und habe viel dabei gelernt und bin dankbar dafür. Exakt was ich wollte.
Mittlerweile bin ich aber auch froh darüber, dass vieles OOTB bei Debian funktioniert (richtige Vorarbeit voraus gesetzt). Das schätze ich sehr.
Solch ein Stolperstein muss mMn nicht sein und verstehe den Maintainer nicht wirklich.
Hier wünsche ich mir von Debian Nachbesserung.
Ohne Browser-Plugin kann das neue passkey Feature in KeepassXC nicht benutzt werden.
Oder liege ich da falsch?
Ich finde, man muss das differenziert betrachten.
Dass er das im keepassxc geändert hat: das war mist. als nutzer eines pakets erwarte ich keine krassen änderungen innerhalb eines releases bezüglich der funktionalität wenn es keine konkreten sicherheitslücken gibt.
Wenn er ein keepassxc-minimal gemacht hätte, und keepassxc so gelassen hätte, wäre das okay gewesen aus meiner sicht.
ein solches keepassxc-minimal würde ich auch gerne sofort benutzen, da ich tatsächlich die netzwerk/ipc funktionalität auch als sicherheitsproblem sehe. Aber Lifecycle-management schlägt bei “potentiellen Problemen von IT-Sicherheit” die IT-Sicherheit.
Finde das Ziel (mit beiden Paketen) gut, nur muss beim _Upgrade_ vom alten _keepassxc_ dann zwingend gefragt werden, ob man bei _keepassxc-full_ bleiben will (und das installiert werden).
…abgesehen von der Wortwahl des Entwicklers kann ich den Sinn dieser Einschränkungen schon verstehen. Passwortmanager sind ein prädestiniertes Ziel für Angriffe aller Art, sie sollten daher so wartbar wie möglich sein (Beschränkung auf Kernfunktionalitäten!) und so wenig Angriffsflächen wie möglich bieten.
Netzwerkfunktionalitäten brauche ich in KeePassXC wirklich nicht und will sie auch nicht, die Synchronisation der verschlüsselten Datenbank erfolgt bei mir komplett davon unabhänging. Auf Inter-Prozess-Kommunikation kann ich (abgesehen von der Zwischenablage) ebenfalls weitgehend verzichten, da die Übernahme von Anmeldeinformationen bei mir ein ganz bewusster, manueller Zugriff auf den Passwortmanager ist. Ich möchte *keinesfalls* irgendwelche Automatismen im Hintergrund und nutze daher nicht die Browserintegration.
So ein Passwortmanager ist der *Schlüssel zum Königreich* – Bequemlichkeitswünsche sind dort absolut nachranging…
Solange es die “Full Version” gibt und das auch so kommuniziert wird, ist doch alles in Ordnung. die Alternative wäre eine “Paranoid” Version 🙂
lar gibt es die “Full Version” immer, da es ja kein Tool von debian ist. Also kannst Du es ueberall kriegen.
Sehr gut, genau so schuetzt man eine Distribution. Wer es anders will, der muss sich eben das Paket selbst aus den Sourcen bauen. Das ist ja kein Hexenwerk. Oder installiert aus den sourcen.
Viele tun ja so als waere das ein unueberwindliches Hindernis.
Man kann auch das Paket aus einem Debianableger, der die Sicherheit nicht so eng siet nehmen.
Wo bitte ist denn das Problem?
Wo endet das? Linux ist für Erwachsene. Kein Kinderspielzeug, das keine scharfen Kanten haben darf weil man es jederzeit in den Mund stecken kann. Mit dem Entfernen aus den Repos wird das Gegenteil erreicht: Wie lange dauert dann die Schließung einer Sicherheitslücke auf allen Endpunkten?
Es ist Linux, da kann eh jeder machen was und wie er es will.
Warum muss man dann auf der Entscheidung einer Distro rumreiten?
Man ist doch nicht von Distributionen abhaengig.
Wenn einem alle nicht gefallen baut man sich eben selbst seine Eigene.
Das Problem ist beispielsweise die Frechheit, Bestandsinstallationen beim Update zu kastrieren. Das geht überhaupt nicht.
Ja ich bin auch der Meinung sie sollten es komplett entfernen, da ersparen sie sich das Ganze.
Ein Passwortmanger ist dafür da eine Distribution zu schützen.
Und ich brauch auch niemanden der meinst mir was vorschreiben zu müssen. Die Zeiten sind zumindest bei mir schon lange vorbei. Ich hasse es wenn sich jemand aufspielt und meint mir was vorschreiben zu müssen. Ich entscheide das ganz alleine. Da brauch ich niemand für.
Und ich könnte dir Dinge erzählen, die genau durch so einen Mist entstehen. Um eben diese Bevormundung zu umgehen.
Und das Problem sind die Weltverbesserer, die meinen ihre Meinung den den anderen aufzwingen zu müssen. Das greift mittlerweile um sich.
Man braucht kein extra Paket, denn im eigentlichen Paket kann man das wunderbar deaktivieren wenn man es denn unbedingt so möchte.
Und wenn so ein beschnittenes Paket kommt, dann soll er ein neues generieren und nicht das bestehende einfach “kastrieren”. Welcher normale User liest denn den Changelog bei einem Update?
Das Schoene an Linux ist doch, das Jeder es so machen kann, wie er moechte.
Also wo ist die Bevormundung?
Also alles gut und was eine Distro fuer notwendig haelt und was nicht, das ist nicht Nutzersache.
Ein selbsternannter Retter der Entrechteten jubelt den Leuten ein amputiertes Programm unter und suggeriert mit dem Paketnamen Vollständigkeit. Diese Art von militaristisch-extremistischem Bevormundungshabitus hat mich bereits Mitte der 2000er wieder nachhaltig von Debian abgeschreckt. Da kommt nichts Gutes bei raus.
Wo war das denn der Fall?
cdrtools. War seinerzeit ein ziemlicher flamewar.
‘mal so nebenbei:
Solch nette und freundliche Worte sind doch immer wieder schön zu lesen.
Da bekomme ich wieder richtig Lust auf Debian.
Es sollte an Taten, nicht an Worten gemessen werden.
Für den Typen sind seine User halt kein Nutzvieh.
Und auch wenn ich’s nicht selbst einsetze, finde ich den Schritt von Debian gut.
Der User kann dann ja die Prioritäten für seine Paketauswahl selbst treffen.
Ich sehe das Technical Committee schon die Axt schärfen 😀
Uiuiui 😀
Da hat sich jemand in der Tat weit aus dem Fenster gelehnt.
Wenn er der dieser Meinung ist gibt es, in meinen Augen, bessere Wege.
Ich würde 2. sagen. Seine Version suggeriert nun dass alles vorhanden ist und führt zur Irritation beim normalen Benutzer. Das ist im Grunde Bevormundung der übleren Art…
Hast Du Linux verstanden? Linux ist eigentlich der kernel. Alles andere sind ein Konvult aus einzelnen, externen tools und programmen, die zu eine Distribution zusammengefuegt werden.
Programmiert wird das sehr wenig. In den Fall jetzt wird hal die Funktion abgeschalten und es kann jeder fuer sich einschalten. Entsteht ein Schaden entsteht dieser somit nicht durch die Distribution und das ist doch gut so.
Der Maintainer hat offenbar die Funktionsweise eines Passwortmanagers nicht verstanden. Ich würde sogar sagen, dass dies sogar essenzielle Bestandteile eines Passwortmanagers sind, die er da gerade entfernt hat. Ohne diese, könnte man ja auch LibreOffice Calc nutzen – und das machen ja auch tatsächlich mehrere Leute in meinem Bekanntenkreis. Ob es aber WIRKLICH sicher so viel sichererer ist – da habe ich meine Zweifel (Kommt ein bisschen darauf an, wie man diese ODS Datei dann sichert). Oder sie verwenden Optionen in der Cloud, weil das so komfortabel ist. Daher muss KeepassXC gewisse “Komfort-optionen” anbieten (Welche sich übrigens auch alle in den Optionen abschalten lassen), um die Leute von der Cloud abzuhalten, weil das ist dann wirklich ganz anderes Level von Unsicherheit.
genau. Die naheliegende “Alternative” jetzt wäre, das Paßwort per Zwischenablage zu übertragen -möglichst noch mit einem aktiven Clipboard Manager wo das dann unkontrolliert wochenlang darin bleibt. Na toll. Sicherheit ist kein Produkt sondern ein Prozeß, der 90% mit Bewußtsein zu tun hat. Ich kann mit einem 300 PS Auto genauso sicher – wenn nicht sogar sicherer fahren, wie mit der Basismotorisierung – muß nur verantwortungsbewußt mit der Kraft umgehen. Wir leben leider in einer Epoche kindischer Bevormundung. Dashat sich so weit in unsere Kultur hereingefressen, daß man dem Debian Maintainer schon faßt keinen Vorwurf machen kann. PS: wer Autos nicht mag – noch in den 90ern konnte man in Berlin die Türen der betagten (“classic”) S-Bahn-Züge während der Fahrt öffnen. Einfach so herausgefallen ist da niemand. Jedem Kind wurde beigebracht, sich von den Türen fern zu halten – heute nicht mehr – und da passieren die Unfälle.
es ist sicherer, weil die verschlüsselung von keepassxc geaudited wird und die datei im gegensatz zu calcsheets standardmässig offline verschlüsselt ist. ausserdem schliesst sich keepassxc wenn der bildschirm schoner angeht.
du hast “offenbar die Funktionsweise eines Passwortmanagers nicht verstanden.”. Ooooder du hast bloss eine andere Sichtweise auf das Thema.
Ich empfinde ein keepassxc ohne Netzwerk/IPC/AutoFillimBrowser) als ein Plus. Aber der maintainer hat hier beim lifecycle im release management gepfuscht. das ändern gehört sich nicht INNERHALB des releases.
Ich habe die Gefahr noch nicht so ganz erkannt, aber ich sehe das auch so. Ein wenig über das Ziel hinaus geschossen.
Vor allem wie der Maintainer sich hier verhält, ist etwas kindisch.
Da würde ich mir mehr Einfluss von dem Debian Team erhoffen.
Wenn die Begründung zweifelsfrei bewiesen ist und durch mehrere Experten bestätigt, dann mag das gerechtfertigt sein.
So sieht es nach Willkür aus und wäre ein Missbrauch seiner Stellung (was in jeder anderen Distribution aber auch passieren könnte).
Wenn ich das richtig verstanden habe, dann gibt es das Paket ja weiterhin, nur mit erweiterter Bezeichnung. Das wiederum würde beim Upgrade (hoffe doch das es für Stable erst einmal so bleibt) allerdings die Funktionalität zerstören bzw. diese entfällt.
Wie wird Debian das für den Upgrade Prozess regeln? Wird es eine Abfrage geben welches Paket ich nutzen möchte oder muss ich das im Nachgang manuell gerade ziehen, was unschön wäre!
Wird das “full” Paket auch voll umfänglich betreut oder was passiert damit?
Welche Alternative hätte ich?
Habe mich seiner Zeit für den KeePassXC entschieden, obwohl KDE (ich als GNOME User!). Was ist hier vergleichbar?
Ich hoffe für Debian, dass dieser Prozess noch nicht zu Ende gedacht ist und sie die einzelne Gewalt eines Maintainers grundsätzlich überdenken.
Ist doch alles kein Thema. KeePassXC ist ein Debian-Programm also somit auch keinerlei Probleme.
Ich waere sogar dafuer, das sie es komplett aus der Distro nehmen.
Also ich bin absolut für Datenschutz. Werde im privaten und beruflichen Umfeld deswegen oft schräg angeschaut. Aber man kann auch alles übertreiben. Und diese Änderung läuft dem eigentlichen Sinn der Passwortmanagerverwendung entgegen.
Ich muss schon genug Passwörter usw. weiter eingeben. Und ich will mit dem PC arbeiten und nicht mit der Verwaltung beschäftigt sein.
Also meiner Meinung nach absolut unnötig und völliger Bullshit.
Sorry für die deutlichen Worte.
> Verstoß gegen die Debian-Richtlinien darstellt, wenn ein Upgrade bestehende Funktionalität zerstört
Wer was verlässliches braucht, nimmt eine vernünftige Distribution.