Gerade wurde KeePassXC 2.7.10 veröffentlicht, das sowohl Verbesserungen der Oberfläche als auch neue Funktionen ausliefert. Auf der Benutzeroberfläche lässt sich jetzt die Schriftgröße anpassen. Passwörter lassen sich direkt über das Kontextmenü deaktivieren.
Erweiterter Import
Als wichtigste Neuerung wird in der Release-Note der jetzt mögliche Import aus Proton Pass genannt. Passkeys können bei Importen aus Bitwarden mit übernommen werden. TOTP-Einstellungen aus KeePass werden nun auch in KeePassXC gewürdigt. Zur Verbesserung der Übersicht bei Verwendung mehrerer Datenbanken lassen sich jetzt Farben und Symbole zuordnen. Der Dialog im Passwortgenerator zeigt in der neuen Version die Zeichenanzahl, die Passwortstärke wird mit Icons verdeutlicht.
Alle weiteren Änderungen sind im Changelog aufgeführt.
Open Source hält Passwörter sicher
Der Open-Source-Passwortmanager KeePassXC ist ein Community-Fork von KeePassX, das Ende 2021 eingestellt wurde. Es ist plattformübergreifend und bringt zusätzliche Funktionalität mit. Der Fork KeePassXC unterliegt der GPL. Neben der Unterstützung für Auto-Type beherrscht KeePassXC auch noch den Import von KeePass 1-Datenbanken, obwohl die App das Format von KeePass2 verwendet. Es speichert viele verschiedene Arten von Informationen wie Benutzernamen, Kennwörter, URLs, Anhänge und Notizen in einer verschlüsselten Offline-Datei, die an einem beliebigen Ort gespeichert werden kann, einschließlich privater und öffentlicher Cloud-Lösungen. KeePassXC verschlüsselt mit AES und einem 256-Bit-Schlüssel.

Wie gut das es nicht nach Euch geht und die, die Entscheidungen treffen / Einfluss haben weit über den Tellerand hinausschauen und unbeeindruckt weiter machen. Einige Zahlen sprechen schon jetzt für sich. Alleine nur Flathub kommt pro Tag auf über 1 Million Downloads….2017 waren solchen Downloadzahlen unter Linux absolutes Wunschdenken und der Linux Desktop hat nichtmal 4% Marktanteile. da geht was 🙂
Der aufschwung rührt nicht daher, das flathub so toll ist. Nein. Der einzige Grund ist, dass immer weniger mitarbeiten wollen. Weil die Distris den Hilfswilligen immer mehr Stein und Vorschriften in den Eeg legt. Und weil sieit immer weniger Leuten irgendwelche Finanzinvestoren zufrieden stellen wollen und müssen. Also auch Leute rauswerfen.
Hey User, wie hast du es hinbekommen, das flatpak KeePassXC mit flatpak Firefox kommuniziert. Habe verschiedene Anleitungen genutzt aber letztlich stets gescheitert. Hast du eine valide und aktuelle Anleitung?
Grüße
Xavin
Moinsn, ja stimmt es gibt viele Anleitungen. Bei mir hat diese funktioniert:
Flatpak KeepassXC mit Flatpak Firefox verbinden:
flatpak override --user \ --filesystem={/var/lib,xdg-data}/flatpak/{app/org.keepassxc.KeePassXC,runtime/org.kde.Platform}:ro \ --filesystem=xdg-run/app/org.keepassxc.KeePassXC:create \ org.mozilla.firefoxhttps://nextcloud/index.php/apps/notes/note/54#h-flatpak-keepassxc-mit-flatpak-firefox-verbindenErstellen Sie ein Wrapper-Skript für keepassxc-proxy:
Fügen Sie folgenden Inhalt in das Skript ein:
#!/bin/bash APP_REF="org.keepassxc.KeePassXC/x86_64/stable" for inst in "$HOME/.local/share/flatpak" "/var/lib/flatpak"; do if [ -d "$inst/app/$APP_REF" ]; then FLATPAK_INST="$inst" break fi done [ -z "$FLATPAK_INST" ] && exit 1 APP_PATH="$FLATPAK_INST/app/$APP_REF/active" RUNTIME_REF=$(awk -F'=' '$1=="runtime" { print $2 }' < "$APP_PATH/metadata") RUNTIME_PATH="$FLATPAK_INST/runtime/$RUNTIME_REF/active" exec flatpak-spawn \ --env=LD_LIBRARY_PATH=/app/lib \ --app-path="$APP_PATH/files" \ --usr-path="$RUNTIME_PATH/files" \ -- keepassxc-proxy "$@"Machen Sie das Skript ausführbar:
Erstellen Sie die Native Messaging Host JSON-Datei:
Fügen Sie folgenden Inhalt ein:
{ "allowed_extensions": [ "keepassxc-browser@keepassxc.org" ], "description": "KeePassXC integration with native messaging support", "name": "org.keepassxc.keepassxc_browser", "path": "/home/user/.var/app/org.mozilla.firefox/.local/bin/keepassxc-proxy-wrapper.sh", "type": "stdio" }Naja – warum einfach, wenn es auch extrem umständlich geht?
Jo unschön. Ein Helper-Script ist in arbeit 🙂
Ich habe einen Fehler beim Kopieren + Einfügen gemacht:
das ist natürlich falsch:
Das ist mein Notizeintrag in Nextcloud. Das muss du im 1. Codeblock unten entfernen. Sorry.
Hey Xavin, ich hab die Schritte in ein Script gepackt. Erstelle einfach eine Datei mit folgenden Inhalt und mache sie ausführbar (chmod +x). Stelle sicher das in Flatpak Keepass die Browserintegration aktiviert ist und Firefox ausgewählt ist. Hab das eben in einer VM gestestet und hat funktioniert. Ich hoffe bei dir auch🤞
#!/bin/bash # Setzt Flatpak-Override, um KeePassXC mit Firefox zu verbinden echo "Setze Flatpak-Override für KeePassXC und Firefox..." flatpak override --user \ --filesystem={/var/lib,xdg-data}/flatpak/{app/org.keepassxc.KeePassXC,runtime/org.kde.Platform}:ro \ --filesystem=xdg-run/app/org.keepassxc.KeePassXC:create \ org.mozilla.firefox echo "Flatpak-Override gesetzt." # Erstellen des Wrapper-Skripts für keepassxc-proxy echo "Erstelle Wrapper-Skript für keepassxc-proxy..." WRAPPER_DIR="$HOME/.var/app/org.mozilla.firefox/.local/bin" WRAPPER_SCRIPT="$WRAPPER_DIR/keepassxc-proxy-wrapper.sh" mkdir -p "$WRAPPER_DIR" echo "Schreibe Wrapper-Skript..." cat << 'EOF' > "$WRAPPER_SCRIPT" #!/bin/bash APP_REF="org.keepassxc.KeePassXC/x86_64/stable" for inst in "$HOME/.local/share/flatpak" "/var/lib/flatpak"; do if [ -d "$inst/app/$APP_REF" ]; then FLATPAK_INST="$inst" break fi done [ -z "$FLATPAK_INST" ] && exit 1 APP_PATH="$FLATPAK_INST/app/$APP_REF/active" RUNTIME_REF=$(awk -F'=' '$1=="runtime" { print $2 }' < "$APP_PATH/metadata") RUNTIME_PATH="$FLATPAK_INST/runtime/$RUNTIME_REF/active" exec flatpak-spawn \ --env=LD_LIBRARY_PATH=/app/lib \ --app-path="$APP_PATH/files" \ --usr-path="$RUNTIME_PATH/files" \ -- keepassxc-proxy "$@" EOF echo "Wrapper-Skript erstellt." # Wrapper-Skript ausführbar machen echo "Setze Berechtigungen für Wrapper-Skript..." chmod +x "$WRAPPER_SCRIPT" echo "Wrapper-Skript ist nun ausführbar." # Erstellen der Native Messaging Host JSON-Datei echo "Erstelle Native Messaging Host JSON-Datei für Firefox..." NATIVE_MESSAGING_DIR="$HOME/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts" NATIVE_MESSAGING_FILE="$NATIVE_MESSAGING_DIR/org.keepassxc.keepassxc_browser.json" mkdir -p "$NATIVE_MESSAGING_DIR" echo "Schreibe Native Messaging JSON-Datei..." cat <<EOF > "$NATIVE_MESSAGING_FILE" { "allowed_extensions": [ "keepassxc-browser@keepassxc.org" ], "description": "KeePassXC integration with native messaging support", "name": "org.keepassxc.keepassxc_browser", "path": "$WRAPPER_SCRIPT", "type": "stdio" } EOF echo "Native Messaging JSON-Datei erstellt." echo "Setup abgeschlossen. Bitte KeePassXC und Firefox neu starten, um die Änderungen zu aktivieren."Wow! Danke, aber wenn das nötig ist, um das keepassxc flatpak zu benutzen, wünschte ich mir lieber, dass auch in “stable” mache Anwendungen (wie eben keepassxc) halt doch aktueller wären.
Naja das ist halt ein Feature von Flatpak, das Apps erstmal isoliert voneinander laufen. Ein Zusammenspiel Untereinander ist eher eine Ausnahme. Aber bedenke das normale Apps dich nicht fragen, sondern einfach machen. Mit sudo gibt es sogut wie garkeine Einschränkungen. Noch ist das kein großes Problem, aber Linux wird immer populärer und damit kommen auch die kriminellen und dann geht das ruckzuck. Nur durch Zufall wurde vor kurzem eine Backdoor entdeckt. Dabei handelte es sich um OpenSource Projekt und wirklich jeder Distributions Maintainer hat es blindlinks durchgewunken. Wäre das nicht aufgeflogen wäre JEDE Linuxdistrubution verwundbar gewesen.
Linux und Marktanteile? Haeae? In Linux spielen Marktanteile und Konkurenzdenken keine Rolle.
Da wo es eine Rolle spielt, da ist es Firma und das ist nicht Linux.
Entwicklungen von Firmen im Linuxbereich sind für dich kein Linux? Wenn das wirklich so wäre, dann wäre Linux heute nicht da, wo es ist.
Hab ich so nicht gesagt aber die Mehrheit von Linux ist eben nicht Firma.
Das war schon immer so, da kann man so tun wie man will es bleibt so.
Und wo Linux jetzt waere? Genau dort wo man es haben will, bei Leuten die dazu stehen und eben nicht von Marktanteilen und Geld reden.
Linux fuer mich ist frei, individuell, gestaltet von Individualisten und nicht Business.
Das Business ist doch nur auf den Linuxzug aufgesprungen, das sollte man ncht vergessen.
Dank der GPL ist es doch beides. Frei für jeden der will, der Eine wie Du, der Andere wie google (als Synonym für “Firma”). Oder?
> Das Business ist doch nur auf den Linuxzug aufgesprungen […]
Weil sie erkannt haben welche Möglichkeiten Linux für’s Geschäft eröffnet? Man kann “google” schlecht die Nutzung verbieten, oder?
Das hat aber nix mit dem von mir gesagten zu tun.
Genau aus diesem Grunde zaehle ich sie eben nicht zur Linuxgemeinde, schon weil sie ganz andere Interessen vertreten und haben, die mit derLinuxidee garnichts zu tun haben.
Ich verstehe das.
Alles quark mit Soße. Wenn es nach dir ginge wären Millionen Menschen morgen arbeitslos und auf der Straße. Lösch mal alles nur von AMD oder Intel…tschau Linux 🙂
Eines der wenigen Programme für die es unter Linux keine Alternative gibt. Ich hoffe die Entwickler fokussieren sich mehr auf Flatpak und weniger auf Snap. Für das Zusammenspiel mit Flatpak Firefox Browserplugin ist leider ein kleiner großer Aufwand nötig. Hier wünsche ich es ähnlich einfach wie bei der Snapversion.
Bitte?
Die geben sicht nichts. Ist wie Pest und Cholora.
Nimm einfach ein Paket deiner Distribution und alles funktionert wie es soll.
Niemand braucht, insbesondere für Keepass flatpack oder gar snap.
Das Problem ist doch, dass bei den meisten Distris die Version hinterher hinkt. Unter Mint ist noch 2.7.6 aktuell, mal schauen wann sich das ändert. Bei Rolling-Distris mag das anders aussehen, aber nicht jeder möchte diese nutzen. Wobei ich persönlich auch kein Paket am Repo vorbei installieren möchte, da gilt es eben dann, Kompromisse zu finden.
Auch ich nehm lieber stabile Distris. Aber zur Lösung gibts mehrere Möglichkeiten. Zum einen muss man nicht unbedingt die neuste Version haben. Dann kann man die Distri wechseln. Oder man spricht den Maintainer an. Und zu guter letzt baut man sich das Paket selbst.
Und ich wiederhole mich. Snap und flatpack dienen nur dazu Verantwortung und Arbeit und somit Arbeitsplätze abzugeben.
> dass bei den meisten Distris die Version hinterher hinkt
Das ist Aberglaube bzw. eine reduzierte Sicht, die sich nur auf eine Nummer bezieht.
Ich als upstream maintainer richte meine Releases z.B. nach dem Debian Release Zyklus aus. Das bedeutet, dass ich bei nahendend Debian Release (so wie jetzt gerade) keine großen Dinge mehr mache, sondern mehr auf Stabilität hin Arbeite. Neue fancy Dinge, kommen dann erst nach dem Debian Release raus. Die werden dann von Arch/AUR und Ubuntu Usern fröhlich getestet, weil die ja immer den neusten heißen S**** haben müssen. Bis zum nächsten Debian Release zwei bis drei Jahre später ist dann wieder alles stabil.
Ich gebe dir im Großen und ganzen recht. Major version sollten in einer stabilen Distri nicht geändert werden. Minor versionen aber schon. Hier stellen sich doch viele ziemlich quer. Und davon halte ich nichts.
Denn die patcherities steigert bestimmt nicht die Sicherheit oder Stabilität. Und warum soll man Fehler nicht durch upstream fixen lassen. Als nicht durch noch einen weiteren Patch.
Das sehe ich anders.
Gerade Minor releases sind in der Realität tendenziell weniger stabil bzw. bürgen ein entsprechendes Risiko, da diese ja “klein” sind und mal eben so “nebenbei” gemacht werden.
Das entspricht natürlich nicht der Definition eines Minor release, ist gerade im FOSS Umfeld bei kleinen Projekt nicht unüblich.
Das Problem bei diesen Projekten, so wie bei meinem auch, sind fehlende Ressourcen (bei mir selbst und der Community) für ausreichende Tests (jeder Art!).
Wenn das nächste Debian Release noch 2 Jahre hin ist, bin ich da pragmatischer und risikofreudiger. Ist das nächste Debian näher, werde ich ganz pingelig halte PRs zurück, bis das Release durch ist.
Also ich sehe was anderes in den Changelogs.
Und genau diese Meinung, und dieses Handel, bringt diese leidigen Paketsysteme nach vorne.
Und wenn man schon so für Sicherheit ist, dann bitte für die wahre Sicherheit und. nicht für evtl. Programmfehler. Alleine, auch wenn da etliche dagegen sprechen, ist eine Sicherheitshölle.
Im übrigen, hatte ich seit über 20 Jahren noch nie Probleme mit Minorupdates. Noch nie!
Upstream Entwickler sollten sich um die Entwicklung kümmern und nicht ums Paketieren, egal welches Format. Für das Paketieren sind die Distros zuständig. Und wer in der Community ne Extrawurst benötigt, muss eben eine alternative Paketquelle (PPA, AUR, XYZ-Pack, backports, …) anbieten.
Es geht auch um kommerzielle Apps wie Photoshop, AutoCAD, Ableton Live & Co. Die sollen endlich auch auf Linux portiert werden.
Portierung und Paketierung sind aber völlig verschiedene Dinge.
Die Dinge die du da auflistest, sind übrigens keine “Apps”, sondern Applications oder Anwendungen.
Wir sollten als Expert*Innen Verantwortung übernehmen und aufhören das Marketing-Sprech “der Großen” zu übernehmen.
APPlications auch Apps genannt. Und Maintainer sollten sich lieber um das Basissystem kümmern und Apps wie KeepassXC den Entwicklern überlassen die diese Software schliesslich auch entwickeln. Denn die übernehmen schliesslich auch den Support und kennen ihre Software aus dem FF. Aber das ist ja der Albtraum unter Linux und der Grund wieso gerade kommerzielle Anbieter eher sagen nein danke, lass mal nach mit Linux und wenn dann pickt man sich Ubuntu raus weil diese Distri am weitesten verbreitet ist. Super geschäftsmodell.
Sorry. Das ist Blödsinn. Zum einen gibt es etliche Programme für die gibt es klein flatpack. Und auch die Mär, dass die Programme dann überall laufen stimmt nicht.
Es geht den Firmen nur um Geld. Um sonst nichts. Da interessiert sie das Paketformat nicht. Auch nicht die Dustri. Die schließen Geschäfte. Versienen Geld. Das ist das einzigste was ihnen wichtig ist. Und Distribution gehen leider in letzter Zeit auch immer mehr auf die Schiene.
Das finde ich sehr schön, wenn @buhtz sich am Debian Release Zyklus ausrichtet. 😉
Außerdem bestätigst ihr meine Meinung darin, wie wertvoll RR-Distributionen für den upstream Entwickler sind.
Flatpak hat hingegen ganz andere Aufgaben. Da geht es tatsächlich mehr um Profitmaximierung, Einsparungen beim Support und um den Endkunden ein definiertes Produkt anbieten zu können.
Für die Entwicklung von freier Software bringt flatpak und snap keinerlei Vorteile.
Was kostet so ein Flathub Rechenzentrum? Wieviele Menschen werden gebraucht in Vollzeit das am laufen zu halten? Wieviele entwickeln diese Plattform weiter? Sollte Flathub wirklich mit einem Bezahlsystem ausgestattet werden wo jeder Spenden, abonnieren und Lizenzen erwerben kann, dann beginnt ein neues Kapitel. Ja es geht um Geld. Was denn sonst?