Software-update: KeePass Password Safe 2.54

Dominik Reichl heeft versie 2.54 van KeePass Password Safe uitgebracht. Met deze opensource-wachtwoordmanager kunnen accounts worden opgeslagen, inclusief de bijbehorende gegevens, zoals gebruikersnaam, wachtwoord en URL. Alle gegevens worden veilig in een met het Rijndael-algoritme versleutelde database opgeslagen. Verder kan het programma automatisch wachtwoorden genereren en lijsten im- en exporteren. Door het toevoegen van dit taalbestand kan het programma ook in het Nederlands worden gebruikt.

Van KeePass Password Safe bestaan twee verschillende uitvoeringen die beide actief worden ontwikkeld. Versie 1.x is niet afhankelijk van andere software en werkt alleen onder Windows. Versie 2 maakt intern gebruik van XML en heeft verder minimaal versie 2.0 van het .NET Framework nodig of, als het programma onder Linux, macOS of FreeBSD wordt gebruikt, van Mono versie 2.6 of hoger. Een volledig overzicht van de verschillen tussen versie 1 en 2 is op deze pagina te vinden. In deze uitgave is onder meer het probleem verholpen dat het hoofdwachtwoord onder bepaalde omstandigheden kon worden achterhaald. De complete changelog van deze uitgave ziet er als volgt uit:

Important

Certain items are now saved to the enforced configuration file. If you are using one or more of the following features/items and are upgrading to KeePass 2.54 using an installer (setup EXE or MSI), please note the following:

• Triggers:
  If your triggers were not stored in the enforced configuration file up to now, KeePass 2.54 disables the trigger system. If you want to continue using your triggers, open the 'Triggers' dialog (via the main menu item 'Tools' → 'Triggers'), activate the 'Enable trigger system' option, check all triggers (with regard to security, privacy, functionality, compatibility, etc.) and click the 'OK' button.
• Global URL overrides:
  If your global URL overrides were not stored in the enforced configuration file up to now, KeePass 2.54 disables them (individually; therefore, it is recommended that you remember the overrides that you have enabled before upgrading to KeePass 2.54, e.g. by taking a screenshot). If you want to continue using your overrides, open the 'URL Overrides' dialog (via the main menu item 'Tools' → 'Options' → tab 'Integration' → button 'URL Overrides'), check all desired overrides (with regard to security, privacy, functionality, compatibility, etc.), enable them and click the 'OK' button.
• Password generator profiles:
  If your password generator profiles were not stored in the enforced configuration file up to now, KeePass 2.54 disables them. If you want to continue using your profiles, open the 'Password Generator' dialog (via the main menu item 'Tools' → 'Generate Password'), click the shield button (top right) and check all profiles (with regard to security, privacy, functionality, compatibility, etc.).

If you are using the portable ZIP package, KeePass 2.54 tries to migrate triggers, URL overrides and password generator profiles automatically.

If you were using an enforced configuration file that allows mixing enforced items with non-enforced items, the non-enforced items may be overwritten, because the default content mode of some elements has changed. In this special scenario, it is recommended to migrate the local/global items to the enforced configuration file manually (using an XML/text editor) before starting KeePass 2.54.

When starting KeePass 2.54 for the first time, it checks whether there is an enforced configuration file containing one of the elements whose default content mode has changed. If so, a backup of your local/global configuration file is created in your temporary folder ('%TEMP%', usually 'C:\Users\USERNAME\AppData\Local\Temp'; file name 'KeePass_DATE_TIME.config.xml'). After the migration steps above, you can delete the backup file, if you wish, or the operating system will delete it sometime. If you want to keep the backup file, move it to a different folder.

New Features:

• Triggers, global URL overrides, password generator profiles and a few more settings are now stored in the enforced configuration file.
• Added dialog 'Enforce Options (All Users)' (menu 'Tools' → 'Advanced Tools' → 'Enforce Options'), which facilitates storing certain options in the enforced configuration file.
• Export confirmation dialog banners now have a yellow-orange background.
• In export confirmation dialogs, the text of the 'OK' button is now changed to 'Confirm Export'.
• In report dialogs, passwords (and other sensitive data) are now hidden using asterisks by default (if hiding is activated in the main window); the hiding can be toggled using the new '***' button in the toolbar.
• The 'Print' command in most report dialogs now requires the 'Print' application policy flag, and the master key must be entered if the 'Print - No Key Repeat' application policy flag is deactivated.
• The 'Export' command in most report dialogs now requires the 'Export' application policy flag, and the master key must be entered.
• Single line edit dialogs now support hiding the value using asterisks.
• On Unix-like systems, commands that require elevation now have a shield icon (like on Windows).
• TrlUtil: added 'Move Selected Unused Text to Dialog Control' command.

Improvements:

• Improved process memory protection of secure edit controls.
• The content mode of the configuration elements '/Configuration/Application/TriggerSystem', '/Configuration/Integration/UrlSchemeOverrides' and '/Configuration/PasswordGenerator/UserProfiles' is now 'Replace' by default.
• The built-in override for the 'ssh' URI scheme is now deactivated by default (it can be activated in the 'URL Overrides' dialog).
• When opening the password generator dialog without a derived profile, the '(Automatically generated passwords for new entries)' profile is now selected by default, if profiles are enabled (otherwise the default profile is used).
• Improved UI update performance in the password generator dialog.
• Improved and renamed dialog banner styles.
• The separator line of light dialog banners is gray now.
• Improved serialization/deserialization of custom configuration settings (used by plugins).
• Improved reporting of unknown database header fields.
• On Unix-like systems, the clipboard workarounds are now disabled by default (they are not needed anymore on most systems).
• Improved clipboard clearing on Unix-like systems.
• Improved starting of an elevated process on Unix-like systems.
• TrlUtil: improved keyboard shortcut assignment and toolbar construction.
• Installer: the desktop shortcut is now created for all users (if the option 'Create a desktop shortcut' is activated).
• Installer: removed the Quick Launch shortcut option.
• Upgraded installer.
• Various UI text improvements.
• Various code optimizations.
• Minor other improvements.

Bugfixes:

• In report dialogs, the 'Print' and 'Export' commands now always use the actual data (in previous versions, asterisks were printed/exported when the application policy flag 'Unhide Passwords' was turned off).
• The icon of the custom algorithm options button in the password generator dialog is not cut off anymore.

Versienummer	2.54
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, BSD, macOS, Windows 8, Windows 10, Windows 11
Website	KeePass Password Safe
Download	https://keepass.info/download.html
Bestandsgrootte	4,17MB
Licentietype	GPL

Reacties (62)

[Cyb]

Ik vind KeePassXC een beter alternatief.
KeePass begint met negatief op te vallen door dat ze nog steeds SourceForge gebruiken, ipv GitHub waar bijna iedereen op zit.
Ook de wijze hoe het team met deze recente CVE is omgegaan (weer een andere dan hier op Tweakers genoemd in dit nieuwsbericht), is al een reden opzich om het te wantrouwen. Daarin zorgde aanpassing van een plain text configuratie file voor een plain text export van het complete database bij het openen ervan, stilletjes op de achtergrond. Hier een PoC.

[Reactie gewijzigd door Cyb op 24 juli 2024 23:56]

[RoestVrijStaal]

KeePass begint met negatief op te vallen door dat ze nog steeds SourceForge gebruiken, ipv GitHub waar bijna iedereen op zit.

Dat is echt een non-issue.

Omdat SourceForge niet populair is, is het iets slechts?

Juist omdat GitHub teveel tractie heeft, heeft Microsoft de gelegenheid om de FOSS community manipuleren. Alleen al dat GitHub niet al te kritisch om gaat met takedown-verzoeken zou je het al moeten vermijden als de pest.

[Anonymoussaurus]

Zie hier waarom het wél een issue is: Anonymoussaurus in 'KeePass Password Safe 2.54'

[Cyb]

Dat "ipv GitHub waar bijna iedereen op zit" wat ik schreef, is trouwens niet bedoeld als argument, maar meer een constatering. Wat opzich nog geen reden is om op SourceForge kritiek te hebben.

SourceForge oogt vooral als een download site voor de eindgebruiker (waar onderdeel is/was van het business model). Als project source code repo service vind ik het erg onoverzichtelijk, en daardoor minder geschikt, wat uiteraard aan mij kan liggen, maar het is niet voor niets dat veel projecten er van afgestapt zijn. De "Sync your GitHub Project to SourceForge" lijkt in ieder geval niet echt te helpen.

Ook heeft SourceForge een erg dubieuze geschiedenis, met het misleiden van eindgebruikers, waarbij je al snel per ongelukg de door SourceForge geinjecteerde adware en crapware geinstalleerd kreeg op je computer. Ook kaapte SourceForge bepaalde grote projecten die overgingen naar GitHub, om daar vervolgens weer adware in te injecteren. Dit is eigenlijk al een reden opzich, om per direct SourceForge te dumpen, uit ethische overwegingen.

[elmuerte]

Microsoft heeft ook een dubieuze geschiedenis. Eentje die vele male erger is dan SourceForge een paar jaar gehad heeft,

[Zer0]

Omdat SourceForge niet populair is, is het iets slechts?

Nee, maar wel vanwege dit soort praktijken: nieuws: SourceForge stopt met adware bij verlaten projecten

[Willem_54]

Inderdaad heeft SourceForge hier niets mee te maken.

Dat Dominik Reichl bij de laatste twee CVE meldingen traag reageerde is wel jammer.
Hij heeft natuurlijk best een punt dat een besmette PC niet meer “jouw” PC is omdat dan manipulatie mogelijk is.

Toch blijft Keepass een van de beste en meest functionele Wachtwoordmanagers die er zijn. Zeker voor ontwikkelaars die op Mainframe en Midrange systemen werken via terminal emulators kunnen er zeer veel profijt van hebben.

Als je Keepass draait vanaf twee goed beveiligde USB sticks, een met Keepass en de database en de andere met een Keyfile, dan is het knap lastig om je gegevens te hacken.

[batjes]

Het is voor mij ook een hekelpunt.

nieuws: SourceForge stopt met adware bij verlaten projecten

Het is al enige tijd geleden, in 2016 zijn ze overgenomen en hebben ze beloofd niet meer zulke geintjes uit te halen. Maar het blijft voor mij tenminste een raar gevoel geven elke keer als ik iets van Sourceforge download.

Plus het is gewoon fijn dat bij FOSS projecten, de broncode gewoon naast de download te vinden is.

[webhalla]

Bedankt voor de links, zoiets belangrijks als een wachtwoordmanager moet veilig zijn.
Volgens mij staat in de documentatie van deze poc:

Fix Released : Changes from 2.53 to 2.53.1:

https://keepass.info/news/n230109_2.53.html

De door U aangegeven poc heeft het ook over het invoegen van triggers in de publiek leesbare xml file en de release notes van deze versie geeft ook aan:

If your triggers were not stored in the enforced configuration file up to now, KeePass 2.54 disables the trigger system

Kunt U beoordelen of het probleem nu opgelost is?

[Cyb]

Dat probleem is opgelost, maar het ging vooral om de wijze waarop: negeren, bagatelliseren, etc, totdat er CVE's werden aangemaakt en grotere sites er over gingen berichten: https://www.bleepingcompu...-stealthy-password-theft/
Waardoor KeePass negatief in het nieuws kwam. Daarna kwam er een oplossing.
Het is de wijze waarop het ging, wat vertrouwen er in schaadt.

[webhalla]

Idd, de vertraging en reacties van de ontwikkelaar Dominik Reichl (imho het hele team achter KeePass) op cve’s is niet bevorderlijk voor het vertrouwen, maar er zit natuurlijk wel een kern van waarheid in zijn redenatie. Als het systeem al dusdanig gecompromitteerd is dat bestanden vrijelijk gelezen en geschreven kunnen worden, kunnen wachtwoorden op vele andere manieren worden worden gekaapt dan alleen op deze manier. Op een volledig gecompromitteerd systeem lijkt mij de wachtwoord manager wel het minste probleem.

[Cyb]

Op een volledig gecompromitteerd systeem lijkt mij de wachtwoord manager wel het minste probleem.

Dan zou een hacker bijv. de executable kunnen vervangen met eentje waarmee hetzelfde bereikt kan worden, is dan vaak het argument. Al hoewel dat klopt, is het meestal wel een stuk gemakkelijker om te exploiteren door een plain text configuratie file aan te passen, dan door een aangepaste executable er op te krijgen. Ook kan security software een wijziging van een executable gemakkelijker detecteren dan een wijziging van voor security software willekeurige andere file die door de geexploiteerde software wordt uitgelezen. De drempel en het gemak is dus anders dan bij een executable.

Ook het gebruik van een keylogger hoeft op een volledig gecompromitteerd systeem niet altijd te werken, want iemand zijn KeePass goed wilt beveiligen, zou ook een hardware token er bij gebruiken.

De verantwoordelijkheid om een systeem dusdanig te beveiligen dat een executable niet vervangen wordt door een kwaadaardige, ligt bij de gebruiker. Maar de verantwoordelijkheid dat een executable van een software pakket niet zomaar stilletjes op de achtergrond code van een kwaadaardige configuratie file kan executeren, dankzij een relatief onbekende feature, ligt bij de software bouwer. Deze moet dan op zijn minst waarschuwingen of opt-in inbouwen. (Wat KeePass uiteindelijk heeft gedaan, na het steeds afschuiven van zijn verantwoordelijkheid.) Ook is het apart dat de bouwer van een software pakket dat je passworden moet beveiligen praktisch gezien zegt: als je systeem gehacked is, dan had je net zo goed je passworden in notepad kunnen opslaan. Dan had je dus eigenlijk volgens hem ook net zo goed meteen je passworden in notepad kunnen opslaan, en is KeePass dan een overbodig product op het gebied van veiligheid. (Wat het uiteraard niet is, maar dat was wel een beetje de redenatie van het KeePass team. Terwijl het hebben van security in werkelijkheid niet zo zwart/wit is, er zou sprake moeten zijn van gelaagde security.)

[Anoniem: 1576590]

Door Cyb:

Dan zou een hacker bijv. de executable kunnen vervangen met eentje waarmee hetzelfde bereikt kan worden, is dan vaak het argument. Al hoewel dat klopt, is het meestal wel een stuk gemakkelijker om te exploiteren door een plain text configuratie file aan te passen, dan door een aangepaste executable er op te krijgen.

Bij een targeted aanval, waarbij de aanvaller (bijv. huftercollega plus niet gelockte PC) weet dat het slachtoffer Keepass gebruikt en alleen dáár geïnteresseerd in is, zou dat kunnen. Maar dan kan er veel meer.

In de praktijk is er veel multifunctionele malware - die o.a. wachtwoorden uit zoveel mogelijk programma's probeert te plukken.

Door Cyb:

Ook kan security software een wijziging van een executable gemakkelijker detecteren dan een wijziging van voor security software willekeurige andere file die door de geexploiteerde software wordt uitgelezen. De drempel en het gemak is dus anders dan bij een executable.

Een aanvaller hoeft keepass.exe niet te vervangen (op mijn PC kan dat trouwens niet zomaar, want met mijn ordinary-user account heb ik daar geen schrijfrechten op).

Het toevoegen van een executable en het aanpassen van een snelkoppeling of browser-plugin kunnen volstaan.

Door Cyb:

Ook het gebruik van een keylogger hoeft op een volledig gecompromitteerd systeem niet altijd te werken, want iemand zijn KeePass goed wilt beveiligen, zou ook een hardware token er bij gebruiken.

Dat helpt niet, en een systeem hoeft niet "volledig" gecompromitteerd te zijn.

De essentie van Keepass en andere wachtwoordmanagers is een sterk versleutelde database die je kunt back-uppen en waar niemand iets mee kan zonder wachtwoord.

Zodra je die database ontsleutelt is het aanvalsoppervlak (vooral onder Windows) enorm groot.

Door Cyb:

Maar de verantwoordelijkheid dat een executable van een software pakket niet zomaar stilletjes op de achtergrond code van een kwaadaardige configuratie file kan executeren, dankzij een relatief onbekende feature, ligt bij de software bouwer. Deze moet dan op zijn minst waarschuwingen of opt-in inbouwen. (Wat KeePass uiteindelijk heeft gedaan, na het steeds afschuiven van zijn verantwoordelijkheid.)

De feauture is inderdaad riskanter dan zinvol en ook de communicatie had anders gemoeten.

Ontwikkelaars kijken echter vanuit een ander perspectief: zij weten dat Windows, processen van dezelfde gebruiker nauwelijks of niet van elkaar isoleert (iOS en Android doen dit beter).

De wake-up call voor gebruikers moet zijn dat Windows jou niet tegen jezelf beschermt. Je zult alle software moeten vertrouwen die (bedoeld of onbedoeld) op jouw systeem terecht is gekomen en zou kunnen draaien.

Door Cyb:

Ook is het apart dat de bouwer van een software pakket dat je passworden moet beveiligen praktisch gezien zegt: als je systeem gehacked is, dan had je net zo goed je passworden in notepad kunnen opslaan. Dan had je dus eigenlijk volgens hem ook net zo goed meteen je passworden in notepad kunnen opslaan, en is KeePass dan een overbodig product op het gebied van veiligheid.

Nee, want als de schijf in jouw PC of een back-up niet versleuteld is en in verkeerde handen valt, kan een tekstbestand eenvoudig worden uitgelezen.

Vooral bij beveiligingssoftware is het essentieel dat je goed begrijpt welke dreigingen er (kunnen) bestaan en hoe je die allemaal zoveel mogelijk beperkt.

Lastig daarbij is dat o.a. Keepass verstopte features heeft en met allerlei maatregelen (zoals clipboard wissen) suggereert dat het veiliger is dan het is; schijnveiligheid dus.

[Cyb]

Uiteraard zijn er veel meer mogelijkeden, ik gaf slechts voorbeelden. Op een volledig gecompromitteerd systeem is haast vanalles mogelijk, afhankelijk van de definitie van "volledig". Maar dat er met minder ook veel bereikt kan worden, ontken ik ook helemaal niet.
Dat stuk over notepad begrijp ik uiteraard ook wel, maar het is de suggestie die de bouwer haast communiceert om het probleem te bagatelliseren. Het is dus niet iets waar ik achter sta, het is juist iets waar ik kritiek op heb.

[Anoniem: 1849202]

Je Keepass Database hoort als het ware een kluis te zijn, zodat zelfs als een inbreker je huis binnenkomt deze niet zomaar de kluis kan openen. Als jij een computer deelt met meerdere mensen, mag je verwachten dat je Keepass database niet via een simpele toevoeging aan de configuratie alle paswoorden in plain text ergens wegschrijft zodra jij de database één keer ontgrendeld.

Neem aan dat jij van een kluis verwacht dat deze ook niet automatisch ontgrendeld zodra iemand de voordeur opent of een raampje ingooit en zo het huis betreedt?

Stel jij bent zelf nog zo veilig bezig door je Keepass Database op een USB-stick ten allen tijden bij je te hebben (ook niet altijd verstandig maar goed), omdat je niet wilt dat iemand kopieën gaat maken en deze gaat brute-forcen, dan zou het wel heel knullig zijn als de installatie van Keepass op zo'n simpele wijze gecompromitteerd kan worden. Dan moet je dus al een portable installatie van de applicatie hebben en dan alsnog hopen dat deze de inbegrepen configuratie bestand gebruikt en niet ééntje die elders is weggeschreven.

[Reactie gewijzigd door Anoniem: 1849202 op 24 juli 2024 23:56]

[Anoniem: 1849202]

Het niveau van de CVE doet mij denken aan mijn stageperiode bij een hoge school, waarbij ze een examentool hadden die reguliere computers op het campus kon inzetten in een kiosk-achtige examen-modus maar ook de examendata verwerkte van- en naar de server.

Daar zat een administrator tool bij waarin je examens kon klaarzetten, de configuratie van de tool zat echter in dezelfde folder als.exe.config-bestand, daarin stond het volgende:

<setting name="Admins" serializeAs="Xml">
<value>
<ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<string>administrator</string>

Als test had ik de applicatie op mijn persoonlijke laptop gezet, tussen de regel <string></> mijn username van mijn laptop erin gezet ([e-mail]) en tada ik had administrator-rechten in de applicatie op het reguliere WiFi-netwerk van de school, dus in feite had iemand enkel de tool nodig om examens te stelen of aan te passen die op een aparte server werden opgeslagen...

Uiteraard heb ik dit aangegeven, plus het feit dat ze BIOS niet beveiligd hadden op de computers, wat het effectief mogelijk maakte voor iemand om een live disc te gebruiken met data recovery om afgenomen examens terug te halen, naast de gehele beveiliging van de computers te ondermijnen.

Geen idee of ze dat inmiddels gefikst hebben, maar het was een tool die ontwikkeld was en jaren werd gebruikt door een universiteit....

[Reactie gewijzigd door Anoniem: 1849202 op 24 juli 2024 23:56]

[3raser]

Is KeePassXC volledig compatibel met KeePass? Oftewel, kan ik dezelfde database op de ene machine gebruiken/aanpassen met KeePassXC en op de andere machine met KeePass?

Ik zou KeePassXC graag proberen maar als het niet bevalt zou het heel handig zijn als ik zonder dataverlies weer terug kon schakelen.

[Cyb]

KeePassXC zegt:
https://keepassxc.org/docs/

Which password database formats are compatible with KeePassXC?

KeePassXC currently uses the KeePass 2.x (.kdbx) password database format as its native file format in versions 3.1 and 4. Database files in version 2 can be opened, but will be upgraded to a newer format. KeePass 1.x (.kdb) databases can be imported into a .kdbx file, but this process is one-way.

Ik vind de tekst erg verwarrend, maar dat kan aan mij liggen. Er is eigenlijk sprake van drie soort versies: 1) KeePass, 2) KDBX file format, en 3) KeePassXC.
Maar het zou dus compatibel moeten zijn met KeePass 2.x, maar je kan het beste een kopie bewaren van de database die je als laatste in KeePass met succes hebt geopend, zodat je zeker weet dat je altijd je oude wachtwoorden nog kan benaderen.
Als nog met KeePass 1 werkt, en je gaat het importeren en vervolgens opslaan met KeePassXC, dan kan je het niet meer met KeePass 1 openen. Maar dat is op zich ook verwacht, want het heeft een andere file extensie, en het gaat via de import functie ipv open functie.

Een andere reden om KeePassXC te gebruiken, is dat deze ingebouwde Yubikey support heeft. Als je daar gebruik van maakt in KeePassXC of andersom in KeePass, dan moet je waarschijnlijk de Yubikey sleutel uit je db verwijderen, voordat je overschakelt.

[stijnos1991]

Kleine FYI, er is geen KeePass team, het is 1 ontwikkelaar. Ook dat kan voor jou / andere organisaties een rede zijn om met alternatieven te werken.

[Marsmillo]

KeepassXC is toch op Keepass gebaseerd, mag ik dan de aanname maken dat Keepass issues ook van toepassing zijn op KeepassXC? Of zijn beide al voldoende onafhankelijk van elkaar in ontwikkeling?

[Cyb]

KeePassXC gebruikt hetzelfde file database formaat als KeePass, wat overstappen gemakkelijk maakt. Het is een fork van KeePassX, wat een Linux port van KeePass is. Het zou misschien kunnen dat er code voorkomt die ook in KeePass voorkomt, maar beiden worden onafhankelijk van elkaar verder ontwikkeld.

Ook komt KeePassXC voor in PrivacyGuides, i.t.t. KeePass.
Verder heeft KeePassXC recent een onafhankelijke security audit gehad.

[Bor]

Ook komt KeePassXC voor in PrivacyGuides, i.t.t. KeePass.

Zonder inzicht in de achterliggende reden heeft dit weinig tot geen waarde. Waarom staat de ene er wel in en de andere niet?

[Cyb]

Dat is me niet heel duidelijk. Als ik het goed begrijp beschouwen ze KeePassXC mogelijk als een betere client, en daarmee KeePass als overbodig voor een opname. Maar met de CVE's er bij, zal KeePass er gok ik niet snel in komen, ondanks dat ze opgelost zijn.

[Bor]

Maar met de CVE's er bij, zal KeePass er gok ik niet snel in komen, ondanks dat ze opgelost zijn.

Wat natuurlijk onzin is. Elk product bevat bugs. Uiteindelijk gaat het om de huidige staat van een product. Een gepatchte en opgeloste CVE is niet meer van toepassing tenzij je een oude versie gebruikt wat sowieso geen goed idee is.

[Cyb]

Met CVE's bedoel ik niet alleen de CVE's opzich, maar ook de wijze hoe daar mee omgegaan is, en het type CVE dat voorkomt. Naar mijn mening is dus niet alleen de huidige staat belangrijk, maar ook de context waarin er geopereerd wordt. Dat kan namelijk invloed hebben op de toekomst. Een site als PrivacyGuides houdt er denk ik niet van om een product in de lijst op te nemen, om er vervolgens misschien later er weer mogelijk uit te moeten halen. Het is denk ik bedoeld als een stabiele lijst. Neem bijv. een product als LastPass. Zelfs als deze qua privacy zou voldoen, dan is het aantal en type security incidenten dusdanig hoog, dat zelfs als alles wat bekend is, is opgelost, het product nog steeds af te raden is op basis van geschiedenis en de beschikbare alternatieven.
KeePass zou dan (uitgaande dat ze context meenemen) misschien geschikter zijn voor een lijst waar men meer vooruit durft te lopen/risico durft te nemen, bijv. https://github.com/pluja/awesome-privacy#password-managers Maar ook daar is KeePass opvallend genoeg niet in opgenomen (reden weet ik niet), terwijl je zou verwachten dat KeePass, toch wel één van de bekendste lokale password managers is.
Maar ik vind je punt over CVE's verder wel begrijpelijk, al hoewel ik er niet helemaal mee eens ben: context is belangrijk. (Maar die discussie hebben we vaker gehad, bijv. bij Kaspersky )

[Friemel]

Bij KeePassXC mis ik de triggers die nodig zijn om met meerdere locaties te synchroniseren. Is daar inmiddels al iets voor?

[Marsmillo]

Dat wist ik niet, bedankt voor de informatie.

[bussie66]

Je aanname is onjuist.

Laatst was er een issue met het master-password van KeePass en dat issue was er niet bij KeepassXC

[epias]

KeePass begint met negatief op te vallen door dat ze nog steeds SourceForge gebruiken, ipv GitHub waar bijna iedereen op zit

Ik zie dat eerder als een pluspunt. Gelukkig is niet iedereen een 'volger' en hebben sommige nog een eigen mening.

[Anonymoussaurus]

Hoe is het een pluspunt? Je wordt geacht om maar een ZIP te downloaden en er maar vanuit te gaan dat dát de source code is die ook daadwerkelijk gecompileerd is. Je kan geen pull requests aanmaken, ook geen issues oid, niks. Dan was self-hosted GitLab nog beter geweest.

[Reactie gewijzigd door Anonymoussaurus op 24 juli 2024 23:56]

[RoestVrijStaal]

Je wordt geacht om maar een ZIP te downloaden en er maar vanuit te gaan dat dát de source code is.

Het *zou* moeten staan in https://sourceforge.net/p/keepass/code/HEAD/tree/

Je kan geen pull requests aanmaken, ook geen issues oid, niks. Dan was self-hosted GitLab nog beter geweest.

https://sourceforge.net/p/keepass/patches/

Even buiten je git-bubbel denken

[Reactie gewijzigd door RoestVrijStaal op 24 juli 2024 23:56]

[Anonymoussaurus]

Je hebt ook daadwerkelijk gekeken naar je linkjes of dat niet? Laatste wijziging is van vele jaren geleden en de branches folder bevat niks.

En omdat er niemand SourceForge heeft zowat, maakt niemand een PR aan. Ook de reden waarom er bijna geen pull requests zijn.

[RoestVrijStaal]

Je hebt ook daadwerkelijk gekeken naar je linkjes of dat niet? Laatste wijziging is van vele jaren geleden en de branches folder bevat niks.

Ja, dat zie ik ook. Blijkbaar hebben de huidige(?) ontwikkelaars niet veel behoefte aan openheid. Ik krijg daar geen goed gevoel bij...

En omdat er niemand SourceForge heeft zowat, maakt niemand een PR aan.

Dat is de keuze van een persoon om een account aan te maken of niet. Zo moeilijk is het ook weer niet om een e-mailadres en wachtwoord in te vullen.

Ook de reden waarom er bijna geen pull requests zijn.

Het werkt ook het beste als de pull request goed uitgewerkt is om geaccepteerd te worden.

In ieder geval zijn de niet-transparante acties van de ontwikkelaars van KeePass verwijtbaar.

Echter denk ik dat het geen verschil zal maken of KeePass nu op GitHub of SourceForge zit. Op GitHub hoeft er ook maar enkel een README.md in de repo zelf te staan, de Releases wel gevuld en de Pull Requests tabje weg of dat er niets mee wordt gedaan

[Anonymoussaurus]

Dat is de keuze van een persoon om een account aan te maken of niet. Zo moeilijk is het ook weer niet om een e-mailadres en wachtwoord in te vullen.

En toch is het een extra barrière, zo blijkt maar weer.

Het werkt ook het beste als de pull request goed uitgewerkt is om geaccepteerd te worden.

Dat sowieso, maar welk platform er dan gebruikt wordt boeit niet.

Echter denk ik dat het geen verschil zal maken of KeePass nu op GitHub of SourceForge zit. Op GitHub hoeft er ook maar enkel een README.md in de repo zelf te staan, de Releases wel gevuld en de Pull Requests tabje weg of dat er niets mee wordt gedaan

Ik denk wel dat het verschil zal maken qua transparantie en hoe betrouwbaar iets overkomt.

[RoestVrijStaal]

[...]
En toch is het een extra barrière, zo blijkt maar weer.

Om bij GitHub een PR te doen moet je ook een account aanmaken.

Dus waarom je nog steeds van mening bent dat "het idee van een account aanmaken" wel een probleem is bij SourceForge en NIET bij GitHub is mij een raadsel.

Ik denk wel dat het verschil zal maken qua transparantie en hoe betrouwbaar iets overkomt.

Nogmaals, dat is te verwijten aan de ontwikkelaars van KeePass en niet te verwijten aan SourceForge. Ik ben het gruwelijk met je eens dat die ontwikkelaars (flink) wat transparanter mogen zijn.

[Anonymoussaurus]

[...]
Om bij GitHub een PR te doen moet je ook een account aanmaken.

Dus waarom je nog steeds van mening bent dat "het idee van een account aanmaken" wel een probleem is bij SourceForge en NIET bij GitHub is mij een raadsel.

Kom op zeg. Je weet zelf ook wel dat de kans dat een developer een GitHub account heeft vele malen groter is dan dat een developer een SourceForge account heeft.

[Cyb]

Echter denk ik dat het geen verschil zal maken of KeePass nu op GitHub of SourceForge zit. Op GitHub hoeft er ook maar enkel een README.md in de repo zelf te staan, de Releases wel gevuld en de Pull Requests tabje weg of dat er niets mee wordt gedaan

Ik kan het verkeerd hebben, maar ik denk dat de gemiddelde programmeur GitHub een stuk overzichtelijker vindt dan SourceForge, even los van de discussie van Git vs SVN. SourceForge is dusdanig onoverzichtelijk dat je snel dingen over het hoofd ziet. Het is oogt ook meer als een download site (met vroeger door SourceForge crapware er in geinjecteerd), i.p.v. een source code project repo zoals bij GitHub. Potentieel nieuwe gebruikers zullen snel geneigd zijn om SourceForge daarom over te slaan.

Ook degenen die daar hun actieve projecten hebben staan, lijken de projecten te verwaarlozen.
Van de top 20 projecten van "most downloads last week" zijn slechts 12 dit jaar nog geupdate, waaronder KeePass.

Ben wel benieuwd de verhouding tussen projecten die SourceForge naar GitHub verhuizen t.o.v. ondersom.
Op het moment dat een project van SourceForge naar GitHub gebruikt, denkt men meestal: "begrijpelijk". Op het moment dat een project van GitHub naar SourceForge verhuist, denkt men: "wtf".

[Reactie gewijzigd door Cyb op 24 juli 2024 23:56]

[RoestVrijStaal]

Ik kan het verkeerd hebben, maar ik denk dat de gemiddelde programmeur GitHub een stuk overzichtelijker vindt dan SourceForge, even los van de discussie van Git vs SVN. SourceForge is dusdanig onoverzichtelijk dat je snel dingen over het hoofd ziet

Door de vorige en huidige UX hipster trends ziet het er idd onoverzichtelijk uit. Maar dat is ook gewenning. Het is ook gericht op een iets technischere doelgroep. Dan hoeft het IMHO niet zo erg gelikt uit te zien. Als de boel maar werkt.

[...]
Op het moment dat een project van GitHub naar SourceForge verhuist, denkt men: "wtf".

En die redditors hebben enkel het woord "SourceForge" gelezen en zijn daarna gaan steigeren. Als je leest WAAROM er van GH naar SF gemigreerd wordt, is het antwoord kraakhelder: kosten om de boel in de lucht te houden. Het was dat SF dat gratis aanbod, anders was het gewoon over en uit met OpenGApps. Het is de overweging tussen idealisme/ethiek en voortbestaan. Of moet alles maar wijken of dood gaan voor het idealisme/ethiek?

[Reactie gewijzigd door RoestVrijStaal op 24 juli 2024 23:56]

[Cyb]

Die "waarom" had ik ook gelezen, maar die "wtf" gaat wel verder dan alleen de naam "SourceForge". Zoals ik zelf ook al meerdere punten heb aangegeven.

Ook lijkt OpenGApps dat naar SourceForge overstapte, nu niet echt heel actief meer, net zoals veel andere projecten in de top 20 van SourceForge. En voor de source code verwijst OpenGApps via SourceForge alsnog gewoon naar GitHub. Wat in lijn is met mijn mening: SourceForge is meer een download site (wat SourceForge zelf nog eens benadrukt door crapware in downloads te injecteren) met daarbij code repository als een extra feature, terwijl GitHub vooral bedoeld is als code repository, waar download releases meer een extra feature is. Samenwerken in een team met andere programmeurs, doet men daarom liever op GitHub dan op SourceForge.

Dat veel projecten zijn overgestapt uit "gewenning" klinkt ook tegenstrijdig. Het zou voor nieuwe potentiele programmeurs kunnen gelden, maar voor bestaande projecten op SourceForge zou dat minder moeten gelden. Ze zijn immers SourceForge al gewend, maar stappen om wat voor reden dan ook, over naar nieuwer platvorm (GitHub). Het aantal dat terug naar SourceForge gaat is minimaal. OpenGApps is één van de uitzonderingen, maar is vervolgens toch nog afgestoten/verlaten (althans, zo lijkt het).

[Reactie gewijzigd door Cyb op 24 juli 2024 23:56]

[aikebah]

[...]
Ja, dat zie ik ook. Blijkbaar hebben de huidige(?) ontwikkelaars niet veel behoefte aan openheid. Ik krijg daar geen goed gevoel bij...

https://sourceforge.net/p...pass/files/KeePass%202.x/

moet je zijn... source-zip side by side met iedere binary. Niet bepaald eenvoudig om de change-historie in te zien inderdaad, maar volledig open en als je wilt zou je ze zelf kunnen brouwen ondertekend met eigen code-signing keys.

[DataGhost]

En omdat er niemand SourceForge heeft zowat, maakt niemand een PR aan. Ook de reden waarom er bijna geen pull requests zijn.

Als je net nieuw bent op internet heb je misschien nog geen SF-account. Ik heb er al ruim 20 jaar eentje. Maar als iemand een bug belangrijk genoeg vindt om een ticket/PR te gaan maken is het aanmaken van een account een triviale extra stap. Er zijn nog steeds zat high-profile projecten die geen Github gebruiken en vaak ook eigen bugtrackers hebben waar je dus weer een aparte account voor nodig hebt. Bijvoorbeeld Linux, om maar een kleintje te noemen. Toch zie ik ook daar achterlijk veel bugreports staan, dus op de een of andere manier lukt het daar wel.

[Anonymoussaurus]

En N=1. Je vergelijkt nu Linux waar vele tientallen miljoenen mensen gebruik van maken met een password manager met veel minder gebruikers? Dat is een rare vergelijking natuurlijk. Bij een grootschalig en essentieel onderdeel als Linux kan je dat nog wel maken, om een SourceForge account te moeten aanmaken, maar bij iets als KeePass al veel minder. Dat ze zoveel bug reports hebben komt gewoonweg omdat er veel gebruikers zijn.

[DataGhost]

Je kent SF duidelijk niet want een aantal jaren geleden had het zeker minimaal de status die Github nu geniet. Dus ja, dat *ik* een account heb is n=1 maar zo ongeveer iedereen die vóór Github en consorten met open-source bezig was heeft een SF-account. Het was min of meer de enige plek waar je je source kon hosten als je dat zelf niet kon en het is daarmee ontzettend belangrijk geweest voor OS in het algemeen.

Maar ik vind de grootte van een project juist een beetje een rare vergelijking. Als je puur statistisch zou gaan kijken kan je jouw conclusie niet zomaar trekken zonder ook te moeten concluderen dat (nattevinger) 80+% van de bugreports voor Linux niet gemaakt wordt omdat het niet op Github staat. De kans dat iemand een bugreport maakt hangt namelijk niet af van het aantal gebruikers van het project, maar van de impact die de reporter ervaart.

[Anonymoussaurus]

Ok, leuk dat je zover terug in de tijd gaat, maar dat is niet relevant over hoe er NU wordt omgegaan met GitHub vs SourceForge. Feit is dat:

1. De kans groter is dat een dev een GitHub account heeft dan SourceForge account
2. De kans groter is dat een dev een GitHub account wil aanmaken ipv SourceForge

Anders zouden niet zoveel users/devs kritiek hebben op het feit dat ze nog steeds op SourceForge zitten (los nog van het feit dat je de broncode als ZIP moet downloaden ipv makkelijk in kan zien). Het is gewoon niet gebruiksvriendelijk, ook omdat de branches outdated zijn.

[DataGhost]

zoveel users/devs

Ik zie hier net zo hard n=1. Er zijn minstens "zoveel" users/devs die geen enkel probleem hebben met de keuze voor een ander platform, die keuze staat iedereen vrij.

(los nog van het feit dat je de broncode als ZIP moet downloaden ipv makkelijk in kan zien). Het is gewoon niet gebruiksvriendelijk, ook omdat de branches outdated zijn.

Er is helemaal niks wat je tegenhoudt om op Github precies hetzelfde te doen. Dat heeft niks met het platform te maken maar puur met hoe de devs hun eigen project hebben ingericht. Optimaal is het zeker niet, maar daar kan SF niks aan doen.

[Anonymoussaurus]

Ik zie hier net zo hard n=1

Moet ik daadwerkelijk met cijfers gaan bewijzen dat GitHub meer gebruikers en repo's heeften populairder is? Kom op, dat is gewoon common sense. Even een snelle zoekopdracht en je hebt het gevonden. Niks N=1 dus.

Dat heeft niks met het platform te maken maar puur met hoe de devs hun eigen project hebben ingericht. Optimaal is het zeker niet, maar daar kan SF niks aan doen.

Ik blame SF toch ook niet? Ik blame de developer en zijn (stomme) keus voor SF.

[DataGhost]

Kan je je eigen quote niet eens meer in je eigen context zetten?

Anders zouden niet zoveel users/devs kritiek hebben op het feit dat ze nog steeds op SourceForge zitten

Ik zie vooral jou kritiek hebben op dat ze op SF zitten, en niet "zoveel users/devs". n=1 dus. Daar reageerde ik op. En je lijkt dat punt grotendeels te onderbouwen met de matige inrichting van het project, alsof je op SF geen source repository en ticketsysteem hebt.

[Christoxz]

Je wordt geacht om maar een ZIP te downloaden en er maar vanuit te gaan dat dát de source code is die ook daadwerkelijk gecompileerd is.

Als je op Github je code published en een .exe released weet je ook niet of dat de compiled source code is?

Verder mee eens dat Github beter zou zijn voor dit soort software, omdat je makkelijker kan inzien wat er gecommit is, echter weet je alsnog niet of de releases identiek aan de code zijn.

[Anonymoussaurus]

Als je op Github je code published en een .exe released weet je ook niet of dat de compiled source code is?

Ik wachtte al op deze reactie, maar: niet per se. Een beetje developer heeft een workflow die automagisch jouw EXE build op basis van de repo code. Die workflow code is ook gewoon in te zien (in de .github folder). Moet je natuurlijk wel het geluk hebben dat ze dat doen.

[DataGhost]

Wat weerhoudt die developer ervan om zo'n workflow in de .github-folder te zetten zodat jij denkt dat het allemaal super-veilig is, en dan na het builden de gemaakte release te deleten en daar een andere executable voor in de plaats te zetten?

[Anonymoussaurus]

Dat is na te gaan, aangezien de publisher een bot (GitHub) is en niet de user zelf.

[Visgek82]

Idd. Als er iets vreselijks is is het wel github.

[Anonymoussaurus]

Leg uit?

[Cergorach]

Ik doe een wilde gok: CoPilot, specifiek het trainen van de LLM op de github gehoste code...

[Anonymoussaurus]

Nee, volgens mij geldt dat alleen voor public repositories, niet voor private repositories. Als de code al public is, wat boeit het dan nog? https://github.com/features/copilot/#faq

[DataGhost]

Er zijn zat licenties die wel "public" code toestaan maar die het niet prima vinden dat die code zonder vermelding wordt gebruikt in andere projecten (zoals voor het trainen van een copilot ofzo).

[VincentvdBergh]

Zelf gebruik ik al jaren KeepassXC vanwege de .Net afhankelijkheid die keepass heeft (specifiek in opensuse LEAP).

Heel fijn wachtwoord beheer programma dat volledig offline werkt. Het delen van een database kan via synchroniseren met een cliuddienst (Onedrive/ Google/ Dropbox/ etc) of zelfhosting (Nextcloud/ Owncloud/ rsync).


Zo jammer dat Keepass relatief laks is met het oplossen van bugs en nog op sourceforge gehost wordt.

[Aeternum]

Is er al een goede browser plugin, degene die ik heb geprobeerd vond ik persoonlijk niet heel fijn werken.

[VincentvdBergh]

Keepassxc heeft een goede browser plugin

https://addons.mozilla.or.../addon/keepassxc-browser/

[Gerard001a]

Blijft mijn paswoord kluis en dat al jaren.
Prima stukje software en zelf vind ik het heel fijn dat ze niet mee doen met het constant veranderen van het uiterlijk 👍
Mijn paswoorden staan gewoon als versleuteld bestand op mijn PC en ik vertrouw volledig op de encryptie van Keepass.
En met autotype zet Keepass, zowel mijn inlognaam alsook mijn wachtwoord neer op de site waar ik wil inloggen.
En dat allemaal gratis ( donatie is vrijwillig) en dat al jaren.
Ben een tevreden gebruiker en hou vertrouwen in Keepass 👍😊

[3raser]

Dus je hebt KeepassXC al jaren niet meer gebruikt maar je blijft wel lekker rondbazuinen dat het niet werkt? Probeer het gewoon nog eens opnieuw aangezien en er tientallen nieuwe versies zijn, of stop met klagen.