Je kunt in ieder geval niet zeggen dat men niet kritisch is.

nu kun je in Debian ( of any other linux distro) makkelijk sshfs gebruiken, dan ziet KeepassXC niet meer dat het eigenlijk om een netwerk resource gaat.

Ik vind het een uitstekende beslissing van de Debian-maintainer. En goed doordacht: netwerkfuncties kan je wel krijgen, maar de default wordt een versie zonder die optie. Kan het ook niet per ongeluk worden gebruikt. KeePassXC is een goed programma, maar een onprem password manager gebruik je met redenen. Een daarvan is reduceren van aanvalsoppervlak.

Ik draai het sowieso op een host die helemaal geen internetconnectiviteit heeft (en binnen het LAN heel beperkt en alleen inkomend), en open het via ssh. Kan ik iedereen aanraden (nog geen verbindingspogingen vanuit KeePassXC gedetecteerd, trouwens).

KeePass Password Safe is toch de beste? origineelste?
Protonpass is ook erg goed trouwens
graag reacties, want ik ben een leek op dit gebied....

Wat opvalt is dat het om niet meer dan een build-optie gaat: WITH_XC_ALL. Opmerkelijk genoeg staat die uit in de default-configuratiefile¹, maar wordt in de installatie-uitleg op de commandoregel weer aangezet². Dus wat de default is hangt af van waar je naar kijkt, en dit via instructies voor de commandoregel regelen wekt bij mij de indruk dat men het er binnen dat project zelf niet volledig over eens is wat nou eigenlijk de bedoeling is.

De discussie waar de laatste link in het artikel naar verwijst is interessant om even doorheen te neuzen voor argumenten over en weer.

¹ https://github.com/keepassxreboot/keepassxc/blob/develop/CMakeLists.txt#L51
² https://github.com/keepassxreboot/keepassxc/blob/develop/INSTALL.md (2e stap in het hoofdstukje Build Steps)

KeePassXC draait bij mij in een sandbox die geen netwerk interfaces heeft, waardoor 'calling home' is uitgesloten.

Klets. Het is opt-in en staat standaard uit. Van 'per ongeluk' zal dus geen sprake zijn.

Het is sowieso een rotgewoonte van Debian om pakketten te pas en te onpas in stukken te hakken of anderszins om te bouwen op een manier die upstream nooit in gedachten heeft gehad.

De "Netwerk code" gaat niet hierover, KeePassXC kan namelijk helemaal niet zelf met remote bestanden werken. (deze oplossing met SSHFS werkt natuurlijk)

het gaat hier om de volgende features:
- Download favicon (niet echt nodig, wel handig.. word niet automatish gedaan)
- SSH-agent (dus je sleutel in Keepass en alleen de agent heeft toegang tot de key)
- Browser-plugin (deze commmuniceert ook d.m.v. 'netwerk code'.) dus je moet al je ww overtypen / copy pasten. (met alle risicos vandien)

en wat vooral ernstig is: de vorgie versie die gebouwd was door Debian, had wel al deze functies. en de Suggestie om een goede upgrade path te hebben voor de huidige gebruikers, alsmede de optie om een alternatief pakket te maken alla "KeePass-XC-No-Network" zijn genegeerd... en de maintainer wil niet 'terug' naar de oude situatie, of voorkomen dat mensen ineens features kwijt zijn.

Nee, KeePass XC is superieur in eigenlijk alle opzichten:
- Ondersteunt geen plugins (dus alleen known / tested / audited features)
- Ondersteunt andere soort geheimen dan alleen wachtwoorden (zoals SSH-sleutels)
- Werkt native op alle OS'en (uitzondering mobiles)
- Ondersteunt Hardware sleutels
- Dark mode
- Audited
- Betere Crypto


en voor mobile zijn er goede varianten beschikbaar.

'De backdoor staat standaard uit', oh nee dan is het goed. De 'upstream' is de gedachte achter KeePassXC gewoon uit het oog verloren. De waarde van KeePassXC was juist een no-nonsense on-premise password manager zonder gebedel om clouddiensten af te nemen of netwerkconnectiviteit. Die functionaliteit toevoegen vergroot de complexiteit van de software en daarmee het aanvalsoppervlak, ook als de backdoor standaard uit staat. Niemand gebruikt KeePassXC omdat ze zo graag netwerkconnectiviteit in hun on-premise passwordmanager willen, anders hadden ze al lang een van de tientallen andere passwordmanagers die die functionaliteit wel biedt gekozen.

Gelukkig zijn er nog developers die wel de kernwaarden van hun (of andermans) project begrijpen, waaronder de maintainers van Debian. Het verwijderen van deze functionaliteit is niets anders dan het wegsnijden van necrotisch weefsel dat tegen alles waar het project voor stond ingaat. Als KeePassXC door gaat met dit soort fratsen komt er gelukkig vanzelf een fork onder een andere naam die wel de geest van het project (en dus de wensen van haar gebruikers) snapt. Het enige waarmee ik het met de dev van KeePassXC eens ben is de kwestie over de naam, er zou een duidelijk onderscheid moeten komen tussen KeePassXC met backdoor en KeePassXC zonder backdoor, desnoods onder een compleet andere naam.

Precies, als ik een passwordmanager met clouddiensten, online back-ups en overige netwerkconnectiviteit wil kies ik wel voor één van de tientallen passwordmanagers die die opties wel bieden. De devs van KeePassXC zijn de scope van hun project totaal uit het oog verloren. Mensen gebruiken toch ook geen LibreOffice omdat ze hun aantekeningen in de Microsoft cloud willen opslaan?

Zo heurt het.

Daarom zegt Debian daar dit over:
https://www.debian.org/Bugs/Reporting

Je kan het een rotgewoonte vinden, maar dit is waarom Debian zo fucking stabiel is, en dat is de reden dat het de basis is voor zo indrukwekkend veel andere distro's, waaronder Ubuntu en (via Ubuntu maar ook direct) Mint. Ze hebben ideeën over hoe hun stabiele systeem in elkaar moet zitten om die stabiliteit waar te maken, en waar pakketten daarvan afwijken passen ze de pakketten aan hun systeem aan. Het is open source, weet je nog? Zo'n aanpassing mag.

Ik snap overigens dat upstream-projecten last hebben van bugrapporten van gebruikers die niet de moeite doen om dit soort details over hun distributie te leren kennen en bugs in Debian toch bij de upstram-projecten melden in plaats van bij Debian.

Mocht jij de ontvanger zijn van dat soort bugs, en aan een pakket werken waar Debian wijzigingen/splitsingen in aan heeft gebracht, leer dan om die mensen naar Debian te verwijzen voor hun bug-reports, hoe pijnlijk dat ook is om te doen. Want het is niet aan jou om problemen in Debian op te lossen als jij geen Debian-ontwikkelaar bent.

Hetzelfde kan vermoed ik over menige andere distributie gezegd worden. Ook daar geldt dat je mensen naar de juiste plek moet durven te verwijzen om niet overladen te worden met dingen waar jij niets aan kan doen.

Voor Linux-gebruikers in het algemeen: meld bugs voor pakketten uit je distributie bij de distributie die je gebruikt, niet bij de "upstream" makers van die pakketten.

Ik krijg het gevoel dat ie een beetje teveel op de developer stoel wil zitten zonder de lasten, maar wel de lusten van een bekend project.

Ik vind het een terecht commentaar van het keepassxc project dat als de maintainer een soort van fork wilde, het aan hem was om een gewijzigde naam te nemen , zoals -minimal .

Het pakket enorm strippen maar wel blijven meeliften op de bekende naam voelt gewoon als een kaping.

Van een debian pakket dat "projectnaam" heeft verwacht je gewoon dat het precies is wat je vindt/leest/verwacht op basis van de wiki/readme/blurb van het upstream project.

Heel goed nieuws!
Ik gebruik zelf KeepassDX op Android, volgens het manifest heeft de app daar ook geen netwerk toegang.
https://f-droid.org/en/packages/com.kunzisoft.keepass.libre/
https://www.keepassdx.com/#donation
https://opencollective.com/f-droid

KeepassDX voor Android en KeepassXC voor GNU+Linux.
Voor Windows weet ik het niet want die doe ik nooit open, dan krijg ik teveel Microsoft binnen en dat is niet goed voor mijn gezondheid.
Vergeet niet het magikeyboard van KeepassDX aan te zetten en te gebruiken, dat voorkomt clipboard-hijacking.
Kijk trouwens ook eens naar hardwarekeys voor 2FA. (Yubikeys e.d.)
Deze gebruik ik zelf via de Yubico 2FA app voor codes. (Zo hoeft u de 2FA codes niet op de telefoon zelf te bewaren)

Via kwetsbaarheden in de code die wel wordt uitgevoerd kan het voor elkaar te krijgen zijn om code te injecteren die routines aanroept die normaal niet bereikbaar zijn. Het is beter als die routines om te beginnen al niet in de runtime aanwezig zijn, dat verkleint de mogelijkheden van een aanvaller.

Je denkt teveel in termen van wat wél de bedoeling is en te weinig in termen van wat níét de bedoeling is. Code waarvan de bedoeling is dat die niet wordt uitgevoerd kan echt ook beter niet aanwezig zijn. Een geslaagde aanval gebruikt altijd mogelijkheden waar je geen rekening mee gehouden hebt. Mogelijkheden die je weglaat kunnen niet misbruikt worden.

Een andere oplossing met dezelfde zienswijze:
https://keepassium.com/articles/cloud-sync-sandboxing

Verifieer even of je gevoel wel klopt voor je je erop baseert. ;-)

Als je er een beetje in duikt zie je dat dat strippen niet betekent dat de Debian-maintainer met de botte bijl zelf van alles uit de code sloopt. Wat hij doet is niet meer dan een build-optie gebruiken die de makers van het pakket zelf bieden. Daardoor is dit een volkomen legitieme variant van het pakket die door de makers expliciet wordt ondersteund.

Sterker nog, in het configuratiebestand met build-opties van het pakket is de keuze die de Debian-maintainer maakt de default. En hier wordt het raar. KeepassXC heeft een default in het configuratiebestand met build-opties, en in de tekst met instructies voor hoe je het pakket compileert laten ze gebruikers op de commandoregel afwijken van die default. Dus ze raden als default aan om af te wijken van de default die ze zelf in het daartoe bestemde configuratiebestand hebben staan. Waar slaat dat nou weer op? De juiste manier om een default aan te passen is om het in dat configuratiebestand te doen, niet om mensen te instrueren om default via de commandoregel af te wijken van de default. De variant die de Debian-maintainer kiest is de variant die je krijgt als je niet op de commandoregel afwijkt van de default in het configuratiebestand.

Die rare kronkel maakt het in mijn ogen nogal onduidelijk wat je hier als goed en als fout moet beschouwen.

Waar het uiteindelijk om gaat is wat voor impact deze wijziging heeft. De Debian-maintainer heeft voor maximale veiligheid gekozen, en heeft daar naar mijn mening goede argumenten voor. Code die je niet gebruikt moet niet eens aanwezig zijn in software met zo'n kritische security-gerelateerde functie als deze. Wat er niet in zit kan ook niet via een fout elders toch geactiveerd en misbruikt worden door een aanvaller. Het tegenargument is gemak voor gebruikers die mogelijk met een wijziging worden geconfronteerd waar ze misschien iets voor moeten doen, niet alleen bij Debian zelf maar ook bij de vele op Debian gebaseerde Linux-distributies (denk aan Ubuntu en Mint), als de maintainers daarvan dit blind overnemen althans.

Het gaat hier om veiligheid versus gebruikersgemak dus.

Gebruikersgemak is heel belangrijk, maar niet ten koste van alles. Een systeem waarin zich langzaam steeds meer onveilige situaties opstapelen omdat gebruikersgemak zo heilig is dat die nooit meer rechtgezet mogen worden rammelt uiteindelijk aan alle kanten. Dat resulteert zelf in een heel serieuze aantasting van gebruikersgemak die razend complex en nagenoeg onoplosbaar is. Dat is in mijn ogen een heel verkeerde weg om in te slaan. Af en toe kom je een zure appel tegen waar ook de gebruikers even doorheen moeten bijten. Dit lijkt er een te zijn.

Dit is juist DE redenen waarom KeePassXC gekozen wordt. Het werkt perfect met vele mogelijkheden die voor gebruikers zeer gebruikers vriendelijk zijn.

Misschien moet JIJ juist een andere KeePass applicatie uitzoeken, die precies aan jou requirements voldoet?
Stil staan in ontwikkeling hoeft niet een goede keuze te zijn? Als andere applicaties beter zijn, stappen je gebruikers over.

Waarom niet?
Onedrive gebruiken, maar geen MS Office?

Beter optie was geweest, een nieuw package te maken: KeePassXC-NoNetwork en dit dan aan de gebruikers over te laten.
Nu krijgen je KeePassXC met verschillende functionaliteit wat voor een gebruiker onhandig gaat zijn.

[qupte]KeePassXC is een goed programma, maar een onprem password manager gebruik je met redenen. Een daarvan is reduceren van aanvalsoppervlak.[/quote]Waarom?

Ik gebruik juist KeePassXC om overal mijn wachtwoorden gemakkelijk te gebruiken, zonder thuis netwerk afhankelijkheid. Voor uitwisseling gebruik ik OneDrive. Veilig en Secure. Veel beter dan dat ik thuis iets moet gaan onderhouden.

Leuk voor die 0.00001% van de gebruikers.

En door deze functionaliteiten heeft het enorm veel gebruikers er bij gekregen. Misschien met een redenen?

Juist de brower integratie is veel beter bij KeePassXC dan bij KeePass.
Beter Cloud Sync, zonder plugins.
Net zoals SSH Agent en de favicon.
Werkte allemaal juist veel beter dan in andere varianten. DE redenen om KeePassXC te nemen. Geen aparte plugins meer noodzakelijk, die misschien nauwelijks meer onderhouden werden.

En daarmee eigenlijk foute keuzes maakt. Hij had gewoon een apart package moeten maken. Nu heeft 1 applicatie naam straks verschillende functionaliteiten.
Zeer gebruikers onvriendelijk en zeer onwenselijk.

Welke backdoor?
Maar dit had de enige goede oplossing geweest.

Heb je ook een bron voor deze bewering?


De browserintegratie van KeePassXC gaat via een aparte plugin...

https://addons.mozilla.org/en-US/firefox/addon/keepassxc-browser/
https://chromewebstore.google.com/detail/keepassxc-browser/oboonakemofpalcgghocfoadofidjkkk
https://microsoftedge.microsoft.com/addons/detail/keepassxcbrowser/pdffhmdngciaglkoonimfcmckehcpafo
https://keepassxc.org/docs/KeePassXC_GettingStarted#_install_the_browser_extension

En KeePassXC heeft geen ingebouwde Cloud Sync...


https://keepassxc.org/docs/

Je roept maar wat.


LE-ZEN:



Oh het is een feature, geen bug?

HAHAHAHAHAHAHAHAHA

Heeft je broodrooster al een ingebouwde SSH-agent?

Bron? Of ben jij soms de officiële woordvoerder van alle KeePassXC gebruikers?


Hoeft niet, doet Debian al voor me. :D


Geen backdoor toevoegen is stilstaan in ontwikkeling? Waarom integreren ze niet gelijk een hele VPN server in KeePassXC? Lekker handig toch? Hoef je geen OpenVPN meer te downloaden. En als ze toch bezig zijn, doe er maar gelijk een webserver met webinterface bij. Dan kun je vanaf je slimme broodrooster bij je wachtwoorden. We willen immers niet stilstaan in ontwikkeling toch?

Wat? Aanvalsoppervlak? Lekker belangrijk bij een wachtwoordmanager.


Precies, ik wacht met smart op de Debian versie van KeePassXC. Zoals de devs van KeePassXC op hun website zelf al aangeven:


https://keepassxc.org/docs/

Bij Debian zijn ze gewoon net iets lower on code dan de KeePassXC devjes. Zou dat de rede zijn waarom Debian zo stabiel is? Zou dat soms de reden zijn dat Debian een standaard is onder linux distro's? Zouden ze bij Debian soms verstand hebben van wat ze doen?


Waarom wel? Een big tech clouddienst afnemen wanneer dat niet nodig is. Als ik wil dat mensen meekijken douche ik wel in m'n voortuin.

Voordeel bovenop KeePass, is dat je geen plugins voor veel functionaliteit nodig hebt. Plugins die je ook weer moet beheren en onderbouwen.
Bij KeePass heb ik standaard de deze functionaliteit nodig:
Webbrowser integratie => Plugin nodig.
favicon downloader => Plugin nodig.
Goede cloud sync => Plugin nodig.

Waardoor er van dezelfde applicatie, nu 2 types zijn, met veel verschillende functionaliteit.
Ze hadden gewoon heel simpel een andere naam moeten verzinnen, en dan was de hele discussie overbodig geweest.

Backdoors? Functionaliteit die gebruikers eigenlijk willen bedoel je?
Ik zie ook niet wat OpenVPN er mee vandoen heeft.

Gewoon een andere naam gebruiken en het probleem was opgelost.
Gebruikers gemaak en plugin beheer zijn ook 2 punten die je niet moet vergeten.

terwijl de cloud sync out of the box perfect werkt.

Prima, kies een andere naam, en je hebt alle discussie opgelost.

Dat is geen antwoord.
Leuk voor je thuis, maar de wereld is een stuk groter.
Er is gewoon een OneDrive client voor Linux, maar geen MS Office. Net zoals bijvoorbeeld EDGE bestaat voor Linux.
Linux support zit ook steeds meer in Intune.
Je laat hier dus eigenlijk al je beperkingen zien, de wereld is veel groter dan jij denkt.

Ik denk dat juist deze discussie laat zien, dat sommige ontwikkelaars of ITers niet weten hoe gebruikers werken met applicaties. Ze denken even alles voor iedereen te kunnen verzinnen vanuit hun eigen perspectief. Ze denken alles beter te weten dan andere.

Hadden ze gewoon een aparte naam gemaakt voor het package, was er geen discussie geweest.

Dit is geen bron, dit is herhalen wat ik al onkracht heb. KeePassXC heeft geen ingebouwde browserintegratie en geen ingebouwde cloudsynchronisatie:

De browserintegratie van KeePassXC gaat via een aparte plugin:

https://addons.mozilla.org/en-US/firefox/addon/keepassxc-browser/
https://chromewebstore.google.com/detail/keepassxc-browser/oboonakemofpalcgghocfoadofidjkkk
https://microsoftedge.microsoft.com/addons/detail/keepassxcbrowser/pdffhmdngciaglkoonimfcmckehcpafo
https://keepassxc.org/docs/KeePassXC_GettingStarted#_install_the_browser_extension

KeePassXC over het ontbreken van ingebouwde Cloud sync:


https://keepassxc.org/docs/

Wederom: je roept maar wat.


Deze discussie is sowieso overbodig aangezien ik al meerdere keren heb aangegeven dat ik het op dat punt met ze eens. Voor de derde keer:


Overigens maakt Debian wel onderscheid middels de naam 'keepassxc-full', dat staat gewoon in het artikel. Maar het zou inderdaad beter zijn als dat onderscheid nog duidelijker zou worden, bijvoorbeeld door 'keepassxc-full' te vervangen door 'keepassxc-BACKDOORED' of 'keepassxc-bloatware' en de Debian versie 'debian-keepass' te noemen of iets dergelijks.


Wederom: bron? Waaruit blijkt dat KeePassXC gebruikers die functionaliteit willen. Ben jij soms de officiële woordvoerder van alle KeePassXC gebruikers?


Ik maak middels een hyperbool een vergelijking met andere overbodige functionaliteit. Maar dat gaat je blijkbaar boven de pet.


Voor de vierde keer:



KeePassXC is dat inderdaad niet vergeten aangezien ze zelf gebruik maken van plugins voor browserintegratie.



https://keepassxc.org/docs/


Hebben ze al gedaan, maar daar zijn de devs van KeePassXC niet tevreden mee. Wat de devs van KeePassXC vergeten is dat Debian gaat over de naamgeving in Debian's repo, niet de devs van KeePassXC. Maar voor de zoveelste keer: ook ik zou het toejuichen als Debian nog meer onderscheid zou maken, of nog beter, als ze KeePassXC helemaal uit hun repo zouden gooien. Gebackdoorde software hoort niet thuis in een repo van Debian.


Dat is wel een antwoord, het is alleen niet het antwoord dat jij wil horen.


Waar heb je het over? Ik heb nooit ontkent dat je LibreOffice bestanden niet in de Microsoft cloud kunt opslaan, noch heb ik ooit ontkent dat er OneDrive of Edge support voor Linux bestaat (dat is ook helemaal niet relevant voor deze discussie). Het verschil is dat ik alleen voor mezelf praat, jij denkt te spreken namens 'de wereld'. En iedere keer als ik om een bron vraag als jij roept dat 'gebruikers' iets willen negeer je dat of herhaal je ad nauseam je standpunt zonder verdere onderbouwing. Nogmaals, ik spreek namens mezelf, jij denkt te spreken namens 'gebruikers' en 'de wereld'.


Deze discussie laat vooral zien dat jij moeite hebt met begrijpend lezen. Ik spreek voor mezelf, het is voor mij helemaal niet relevant hoe andere gebruikers werken met applicaties. Het zou mij een zorg zijn welke bloatware jij of Pietje Puk op je computertje hebt draaien. Ik spreek over mijn mening en mijn ervaring. Jij denkt ondertussen voor 'gebruikers' en 'de wereld' te kunnen spreken. Je onderbouwt geen enkele bewering als je roept dat 'gebruikers' of 'de wereld' iets willen maar je verkeert wel in de waan voor hen te kunnen spreken. Op basis waarvan dan? Kom eens met een bron om je beweringen te onderbouwen zoals ik doe.


Als je het artikel gelezen zou hebben zou je hebben geweten dat ze dat gedaan hebben, maar dat de devs van KeePassXC daar niet tevreden mee zijn. Helaas voor hun gaat Debian over de naamgeving in Debian repo's, niet de devs van KeePassXC.

Hele korte samenvatting: als Debian vind dat ze de netwerk functionaliteit uit Firefox moeten slopen, want veiliger, en ze de naam het zelfde laten, en een firefox-full maken met netwerkfunctionaliteit, dan is dat fantastisch, want veiliger!

ps: ik denk dat die OneDrive als voorbeeld is gebruikt, er zijn meer "cloud" sync dingen, zoals het hier zo vaak geroemde Syncthing of zo, wat lekker via allerhande onbekende peers gaat, en dus heel veilig, of zo.