Bij het nieuws van laatst over de keuze en de onenigheid erover was al door mijn hoofd geschoten dat dit een mogelijkheid zou kunnen zijn, maar ik wist niet zeker of ik goed op een rij had hoe ver de flexibiliteit van het pakketbeheersysteem van Debian gaat. Het kan dus en men doet het ook. Mooi.

Ik vermoed dat het argument over de impact op alle van Debian afgeleide distributies dan ook van de baan is. Als ze blind overnemen wat Debian doet krijgen de gebruikers de keuze, doen ze bewust iets anders dan Debian dan gaat het argument dat Debian dingen in andere distributies onderuit haalt hiermee om te beginnen al niet op.

Andersom. Debian dwingt deze keuze af, niet KeePassXC. Daar is men absoluut niet te spreken over deze stap.

Nah, alles is vrije software, men kan er zelf opzetten wat men wil, daarnaast is de broncode vrijelijk beschikbaar, als Keepass dit niet wou hadden ze geen vrije licentie moeten aannemen.
Men kan als gebruiker ook zelf een eigen versie maken, dat is de kracht van FLOSS.
Iedere distributie maakt haar eigen keuzes qua softwarepakketten, maar gebruikers kunnen alles deinstalleren en vervangen, inclusief de interface van het OS.

Hoewel ze er inderdaad niet over te spreken zijn is het helemaal niet zo zwart/wit. Er zijn best gekke dingen aan de hand.

Om te beginnen zijn er alleen maar build-opties toegepast die KeePassXC zelf ondersteunt. Als ze dit niet willen moeten ze die build-opties eruit halen en het onconditioneel op een bepaalde manier bouwen. Zolang die opties erin zitten is elke variant die daarmee gebouwd kan worden iets dat ze zelf actief ondersteunen en dat met recht KeePassXC genoemd kan worden. Het is heel raar dat ze bezwaar maken tegen een mogelijkheid die ze gewoon zelf bieden.

Maar het gaat nog verder in dit geval. De optie die bij Debian gebruikt is, dat is namelijk de default uit het configuratiebestand voor de build dat KeePassXC zelf levert. Laat dat even tot je doordringen: het is gewoon de default uit het configuratiebestand!

Maar KeePassXC geeft een build-instructie met op de commandline een optie om de default uit het configuratiebestand te overrulen. Je moet dus default niet gebruik maken van de default, zegt KeePassXC eigenlijk. Kan jij nog volgen wat je dan eigenlijk als default moet beschouwen? Waarom hebben ze wat ze als default willen niet als default in het configuratiebestand gezet? Snappen ze zelf wel wat ze willen?

Dan zijn er ook nog stemmen binnen het KeePassXC-project die vinden dat het een fout was om de add-ons default (volgens de commandline-instructie voor de build) te activeren. Die zijn het dus gewoon eens met de maintainer bij Debian dat dat niet de juiste keuze was. Ze willen alleen de fout in stand houden om te voorkomen dat er gebruikers zijn die features die ze gebruiken opeens uitgeschakeld zien worden. Er is dus een conflict tussen gebruiksgemak en veiligheid, en daarin kiest men bij KeePassXC voor gebruiksgemak en bij Debian voor veiligheid. En inmiddels geeft men bij Debian de gebruiker de keuze.

Je moet ook bedenken dat Debian nooit een distributie is geweest die ten koste van de veiligheid en robuustheid dingen zo makkelijk mogelijk voor de gebruiker wil maken. Niet dat gebruiksgemak niet telt bij Debian, maar niet ten koste van robuustheid, veiligheid en stabiliteit. Dat is precies waarom Debian zo populair is als basis (direct of indirect) voor andere distributies die gebruiksgemak wel meer prioriteit geven, zoals Ubuntu en Mint. En dat dingen niet onder je vingers anders gaan werken bij elke upgrade maar alleen bij een nieuwe major versie, en daartussen uiterst stabiel zijn, is op zijn eigen manier weer een vorm van gebruikersgemak. Daar heb ik als gebruiker inmiddels zowat een kwart eeuw geleden bewust voor gekozen en ik ben daar nog steeds heel blij mee, ik vind het een verademing in vergelijking met die rat race waar andere OS'en in meerennen.

Dit is dan ook een wijziging die bij zo'n major release ingaat, niet bij een tussentijdse security-update. De van Debian afgeleide distributies moeten daarmee om kunnen gaan. Die hebben zelf gekozen voor een stabiele basis met eigen wijzigingen daarop die een andere balans tussen gebruiksgemak en stabiliteit/veiligheid opleveren. Dat is prima, maar dan moeten ze die verschillen ook zelf onderhouden. Het vanuit KeePassXC gebruikte argument dat dit een risico voor (de gebruikers van) al die afgeleide distro's oplevert, qua gebruiksgemak, is een probleem van die afgeleide distro's. Het is onzin dat precies de reden dat Debian als basis wordt genomen aangetast zou moeten worden vanwege wat anderen dan Debian anders willen doen dan Debian. Wat hier gekozen wordt past bij hoe Debian software benadert en dat is nou juist precies waarom het zo'n robuuste basis is voor andere distro's.

Enable Ubuntu Pro for Dummies! :)

https://ubuntu.com/pro


https://ubuntu.com/security/certifications/docs/fips


https://ubuntu.com/security/certifications/docs/usg


According to Snyk Ltd. in Boston, partnered with SentinelOne Inc., organisations need 97.8 days on average to fix a vulnerability. With Ubuntu Pro, the currently measured average time to fix for Critical CVE vulnerabilities is less than 24h.

https://go.snyk.io/state-of-open-source-security-report-2022-dwn-typ.html


Desondanks geef ik persoonlijk de voorkeur aan Debian GNU/Linux met apparmor-profile-everything als verharding,

Het ziet er allemaal heel stoer uit op het eerste gezicht, maar ik kijk een beetje raar naar die claim die Canonical ook graag citeert dat de gemiddelde patch-tijd voor kritische CVE's van 98 dagen naar 1 dag terugloopt bij Ubuntu Pro. 98 dagen? Op Debian blijk ik meestal de gepatchte versie al te draaien als ik voor het eerst over een ernstige kwetsbaarheid lees. Als je Pro nodig hebt om goed bij te zijn bij Ubuntu, impliceren ze dan niet dat de gewone Ubuntu ruim drie maanden achterloopt met patches?

Ze beweren dat ze "1800+ additional high and critical patches only available with Ubuntu Pro" hebben. Hoezo is dat mogelijk met open source? Ze moeten broncode ter beschikking stellen en die mag verder verspreid worden. Ze lijken hier te impliceren dat ze open source-licenties schenden.

Een alternatieve verklaring is dat ze de broncode van hun patches wel beschikbaar stellen aan anderen maar dat de rest van de wereld andere patches voor dezelfde kwetsbaarheden beter van kwaliteit vindt dan die van Ubuntu Pro. En dat is dan inclusief de gewone Ubuntu, want die 1800+ zijn exclusief voor Ubuntu Pro.

Nog een andere mogelijkheid is dat die 1800+ patches betrekking hebben op software die je uitsluitend bij Ubuntu Pro krijgt, en die daarbuiten niet gebruikt mag worden (geen open source) of waar niemand interesse voor heeft. Dan pronken ze met het verhelpen van problemen in kennelijk behoorlijk buggy software die buiten hun wereldje niet gebruikt wordt.

Hoe dan ook doet Canonical hier aan marketing, en marketing staat vaak stijf van de misleiding. Geen al te handige misleiding in mijn ogen, want als ik me afvraag hoe wat ze beweren überhaupt kan kom ik uit op mogelijke verklaringen waarbij ze iets verkeerd doen. Is het behalve for Dummies misschien ook by Dummies?

;-)

Debian stable voldoet aan alle van de genoemde veiligheidseisen, zij het dat Ubuntu er formeel door onafhankelijke partijen voor is gecertificeerd. Canonical Ltd. moet dat wel doen, de papierwinkel regelen, want anders willen veel directies van grote ondernemingen, hun leger van bedrijfsjuristen en de verzekeringsmaatschappijen niet met open source in zee. In die wereld geldt nog altijd het dogma dat men het risico op mogelijke bugs, lekken en technisch falen op een andere partij moet kunnen afwentelen. Liever dat, redeneren ze, dan daarwerkelijk eigen ICT expertise in huis halen.