18. Maj 2024

Vildt site med selfhosting-løsninger

Hvis du driver din egen server eller har ønsker om at gøre det, så må du simpelthen ikke snyde dig selv for sitet selfh.st. Det er en søgemaskine, der har alt hvad hjertet kan begære indenfor selfhosting.

Genialt!

Links

https://selfh.st/apps

3. Maj 2024

Ubuntu Linux 24.04 LTS udgivet

Lidt “late to the game”, men bedre sent end aldrig, ik’? ;-)

En af de ting, der undrede mig mest, da jeg var ny Ubuntu-bruger var, at jeg aldrig fik besked med det samme om opgraderingen via app’en “Softwareopdatering”, når der kom en ny Long Term Support-udgave. Det er der en årsag til:

LTS-udgaverne er til dem, der vægter stabilitet over nye features.

Hvis du har sat “Softwareopdatering” til kun at gøre dig opmærksom på nye udgaver ved hver LTS-udgivelse, og du sidder med den gamle Ubuntu 22.04 LTS, så vil du først blive gjort opmærksom på den nye udgave, når det første bugfix-release 24.04.1 LTS kommer d. 15. august 2024. Det giver Canonical tid til at luge ud i de fejl, der evt. har været ved udgivelsen i april 2024.

Bruger du Ubuntu 23.10 (Mantic Minotaur), skulle du gerne have fået besked om opgraderingen allerede nu, evt. kan du skrive

sudo do-release-upgrade

i terminalen, for at igangsætte installationen manuelt (husk som altid backup).

Update: Opgraderingen gik fint. Men jeg skulle faktisk bruge

sudo do-release-upgrade -d

for at tvinge en opgradering frem. ‘-d’ bruges normalt til udviklingsudgivelser, men downloaden identificerer sig som den fulde 24.04 LTS, så den skulle være god nok :) Under opgraderingen vil updateren spørge, om den skal erstatte nogle eksisterende konfigurationsfiler. Har du lavet manuelle ændringer i de pågældende filer, er det en god idé at kigge dem igennem, ellers kan du roligt lade updateren overskrive de eksisterende.

Links

Ubuntu: Noble Numbat Release Notes

2. April 2024

CVE-2024-3094

Link: English autotranslation (Google translate)

Bag overskriftens kryptiske talrække gemmer der sig den sikkerhedsadvisering, der har været genstand for megen omtale, de sidste mange dage. Det viser sig nemlig, at nogen har sneget en bagdør ind i bestemte udgaver af sourcekoden til xz-utils, der findes på mange Unix-varianter (Linux, BSD’erne m.fl.). Bagdøren findes i version 5.6.0 og 5.6.1 - tarball-udgaven, men ikke i selve Git-repository’et (se opslag på Open Wall, link nederst)

Et lumsk angreb

Det er et rigtig nasty supply-chain-attack, fordi det består af to dele. Dels bruges xz i pakkebygningsfasen til at patche funktionsbiblioteket liblzma med ondsindet kode. Men det går skridtet videre… For når liblzma efter patchingen bliver linket sammen med andre softwarepakker, så vil sårbarheden også eksistere i de pakker, der bygges efterfølgende, og som trækker på funktioner fra liblzma.

Ifølge Hackaday, som jeg linker til nedenunder, gik koden som bagdøren udløser specifikt efter at modificere virkningen af funktionen RSA_public_decrypt.

Funktionen RSA_public_decrypt bruges bl.a. til at validere ssh-nøgler, så som Hackaday også nævner, så kunne det for en person med ondsindede intentioner være en mulighed for at gøre OpenSSH’s auth-proces svagere, og dermed nemmere forbigå de normale sikkerhedsprocedurer, når man logger ind på en server via SSH.

Opdaget ved et tilfælde

For open source-miljøet er det en rigtig ærgerlig situation. Først og fremmest godt at det blev opdaget af en årvågen udvikler. Men også en brat opvågning, fordi der måske har været en naivistisk tilgang til kodedeling, ift. til koderevision, ansvarsfordeling og tillid i Open Source-miljøet helt generelt. Særligt med tanke på, hvordan verden udenfor Open Source-miljøet på bedrøvelig vis tager sig ud i disse tider.

Der er endnu ingen, der med 100% sikkerhed ved, om det ondsindede kode er bestilt arbejde af en stat eller en enkelt persons komplot, men uanset hvad resultatet af undersøgelsen bliver, så bør det give det anledning til ændringer i sikkerhedsprocedurene hos de Linux/Unix-distributioner, der hiver pakker ind udefra.

De pakker udgør fundamentet for f.eks en Linux-distribution, som distribueres til millioner af brugere - erhverv og hobbyister - som dagligt bruger Linux på deres computere - servere-, IoT- eller desktopsystemer. Derfor er Linux-distributionernes udgivere også sidste sidste bastion overfor sikkerhedshuller, og bør give pakkerne det sidste tjek inden udgivelse. Det er måske netop nu, at der skal et skævt magisk AI-sovs ind over arbejdsgangene. Det er ikke sikkert, AI kan løse problemet, men det kan udpege problemområder og lette arbejdsbyrden.

Vi kan sagtens blive enige om, at det på papiret er de enkelte upstream-projekter, der selv skal sørge for, at deres kode er testet for sikkerhedshuller og clean. Men det ville forudsætte, at alle er sikkerhedseksperter, og det kan på ingen måde forventes. Det, der mudrer sagen yderligere til her, er jo, at den person der - tilsyneladende - har injiceret malwaren i projektet har været en betroet bidragsyder på xz-projektet i en del år.

Forskellige tilgange til test

Alle projekter har forskellige test-metoder, nogle mere strukturerede og tilbundsgående end andre. Men bottomline er, at pakkerne, der ender ude hos slutbrugerne skal efterprøves bedre. Hvis det betyder, at mængden af nyudviklede funktioner i en distribution bliver færre og at antallet af udgivelser falder, så må det være sådan, det er.

Måske er det på tide at samle kræfterne et formaliseret samarbejde imellem distributionerne, der tester pakker, som kommer ind upstream? De enkelte distributioner kan ikke overkomme den byrde isoleret set. Der er immervæk tusindvls af pakker i f.eks en Linux-distribution, der skal testes, og det - ideelt set - hver gang, der lander en opdatering til en pakke.

Nogle af de community-baserede Linux-distributioners release- og sikkerhedsteams består af få personer, mens det forholder sig anderledes hos de erhvervsrettede. Men selv de har brug for en håndsrækning fra fællesskabet. Om sikkerhedsbristen, der ligger bag CVE-2024-3094 ville blive opdaget nemmere i et sådan samarbejde, må stå hen i det uvisse - men det må alt andet lige give blod på tanden ift. at få skabt bedre systemer, der kan trawle kode igennem for brister - automatiserede såvel som manuelle.

Tornhøj tillid

Min tillid til Open Source-økosystemet er dog ikke svækket - tværtimod. Man kan aldrig undgå sådanne brister, den her var en af de ubehageligt lumske.

Havde det været et operativsystem baseret på proprietær, lukket kode, så kunne sådan en sikkerhedsbrist givetvis få lov at eksistere et stykke tid. Det er og bliver en illusion, at fordi man ikke offentliggør sin kode, så er man bedre sikret. I bedste fald giver det måske arbejdsro.

Det er sket før, at sikkerhedsbrister ikke er blevet patchet tidsnok i closed-source systemer, som Ars Technicas artikel her nævner.

Debatten omkring dette sikkerhedshul afslører også, hvor hårde folk kan være ved hinanden, og vi skal for alt i verden undgå at folk brænder ud. Netop debatkulturen ift. open source og dette sikkerhedsbrud, vil jeg prøve at behandle i et kommende blogindlæg, for det er et studie for sig.

Links

Tråd fra OpenWall
NISTs CVE-beskrivelse med referencer
Hackadays artikel
Low Level Learning: et kig på sagen fra en sikkerhedseksperts perspektiv

4. December 2023

Nem Open Source indholdsadministration med PHP

Jeg tror endelig, jeg har fundet et Open Source PHP content management system, der kan matche Umbraco på Microsoft.NET-platformen bare lidt.

Jeg har arbejdet med Umbraco i snart 20 år, og det har altid været en absolut favorit, der har haft stor indflydelse på, hvordan jeg synes CMS’er skal bygges op. Jeg har prøvet ret mange af de åbne systemer - startede med TYPO3 i en årrække, fik enkelte Mambo/Joomla-opgaver, Wordpress, Orchard og Composite C1 (som vist hedder C1 CMS nu).

Det, jeg har manglet på PHP-platformen, har været at kunne skræddersy backenden lige så hurtigt og nemt, som man kan med Umbraco. Det kan godt lyde som en god gang salgsgas fra en hærdet Umbraco-discipel, men det giver sig f.eks udslag i væsentligt kortere oplæringstid, når man skal lære nye website-administratorer op.

Når noget fungerer intuitivt, så løser selv uerfarne brugere hurtigt en arbejdsopgave, og der har mange CMS’er på PHP-platformen efter min mening traditionelt døjet med “feature bloat”. Der har simpelthen været for mange knapper, og måder at gøre tingene på. Det mest optimale er, at designe brugerfladen efter brugernes ønsker, så de føler sig godt tilpas. Ikke, at de skal bruge for meget tid på at lære at navigere i systemet. Less is more.

Enter… Bolt CMS

Bolt CMS bygger på PHP Symphony-platformen, der er et modent framework efterhånden. Jeg kan godt huske, jeg hørte om Symphony tilbage i 00′erne, da jeg begyndte at bruge PHP professionelt, så det er fedt at se, at det stadig findes.

Jeg vil ikke gå så meget i detaljer med grafiske opbygning af administrationen, for den er, som med de fleste CMS’er.

På overfladen, for det smarte ligger i måden, en websiteløsning opbygges på:

Ligesom Umbraco, så definerer du i BoltCMS også din backend med en række felttyper, f.eks et tekstfelt eller et billedfelt på en Content Type, og det danner tilsammen en slags dokumentskabelon for, hvilke felter CMS-brugeren ser i sin backend, når vedkommende f.eks opretter en nyhed.

Bolt CMS kalder kontrollerne ‘Field Types’, og Umbraco kalder dem ‘Data Types’, men det er praktisk talt det samme.

Det smarte er så, at når du har samlet dine felter i f.eks en content type af typen ‘Nyhed’, så oprettes et menupunkt automagisk i venstre side af administrationen, det er så her, CMS-administratoren og brugerne foretager alle redigeringsfunktioner. Du behøver med andre ord ikke lære dine brugere, hvad en Content Type rent teknisk er, du kan bare pege dem over nyhedsektionen og så vil oprettede nyheder have de felter, der definerede din content type: “Overskrift”, “Forfatter” etc.

– “Jamen, det findes også i andre systemer?”, tænker du måske. Korrekt, men oftest som fasttømrede elementer, og så skal man installere ekstra plugins eller måske endda selv have fingrene i kodegryden, hvis man skal udvide funktionaliteten. Det er jo et valg man tager, om man vil det. Her skal du ikke lave alle forbindelserne mellem dine datamodeller og din backend selv. Det klarer CMS’et.

Derfor kan jeg godt lide, at featuren med den fleksible backendopbygning findes som en indbygget del af et CMS, for så ved du, hvad du har, når du skal udforme din løsning - og et godt stykke ud i fremtiden. Det sker yderst sjældent, at en CMS-producent fjerner grundelementerne, for så er det ikke længere samme produkt.

Den samme sikkerhed har du ikke altid med eksterne moduler: Eksterne udvikleres plugins dør indimellem bare ud, når de enten mister interessen eller laver noget nyt. Det sker for alle CMS’er mellem versionsspring, og så er det, at man kan blive tvunget ud i at forsinke en opdatering af et CMS, indtil man har en erstatning klar.

For at opsummere et allerede langt blogindlæg: Jeg synes umiddelbart, at Bolt er et fedt, gennemarbejdet produkt til mindre og mellemstore sites. Når vi over 50 sider i enkelte kategorier, så tror jeg det begynder at knibe med overskueligheden. Men prøv at lege med det, inden du laver dit næste projekt, for at du kan danne dig dit eget indtryk.

Link:
https://boltcms.io/

PS. Du skal være varsom med at rette Bolts alias for en content type, når først det er sat, og folk tilføjer data i CMS’et. Hvis du retter forsvinder det data, der er skrevet i felterne i Bolts administration. Du kan dog altid hoppe i databasen og lave sammenkædningen igen manuelt med en sneaky SQL-sætning, som folkene bag systemet viser her –> https://bolt.tips/en … enaming-contenttypes

2. December 2023

Paperless - Open Source dokumenthåndtering

Jeg følger #opensource-hashtagget på det sociale medie Mastodon, og derfor får jeg dybest set alt, der handler om Free and Open Source Software op på min væg, og det har været fantastisk. En bruger smed et link til Paperless - et open source dokumenthåndteringssystem (DMS). Det har jeg aldrig hørt om før, så det vakte straks min interesse.

Hvad er et DMS? Måske har du brugt et CMS - Content Management System - til dine websider? Et dokumenthåndteringssystem er mere eller mindre det samme, her er fokuset bare på filopbevaringen og intern kategorisering/indeksering, og ikke på ekstern visning.

Efter at have prøvet demo’en som jeg tror var i stykker, så installerede jeg selv softwaren på min server. Selve softwaren er en backend skrevet i Python og så med en Typescript-frontend.

Der er gjort en masse ud af selve “feel’et”, når du bruger systemet, det føles rart at bruge. Det er naturligvis en subjektiv vurdering fra min side, men navigation og brug af produktet føles generelt flydende og solidt. Jeg har endnu ikke kunnet fremprovokere fejlmeddelelser, selvom jeg har uploadet mange forskellige filtyper til systemet. Oversigtsvisningen kan både være baseret på ruder/kort og listebaseret, og kan ses på billedet herunder - klik evt. for at forstørre.

Paperless'

Selve installationen kan du gøre manuelt eller via Docker Compose. Jeg valgte Docker, fordi det er nemt at rydde op igen, men jeg tror dette produkt er en keeper, for jeg tror det er noget, der kan udvikle sig i spændende retninger.

Installationen var tekstbaseret, og jeg følte mig godt guidet. Du downloader blot en enkelt installationsfil (bash-script) og så klarer Paperless-installationen resten med enkelte spørgsmål til brugernavn/password, tillægspakkevalg osv.

OCR-genkendelse

Det første, jeg satte mig for at teste var Paperless’ OCR-genkendelse. OCR står for Optical Character Recognition, eller optisk karaktergenkendelse, og dens funktion er automatisk konvertering af grafik til tekst. Herunder ser du et eksempel på en indscanning. I visningen til højre er der en bogside, i tekstfeltet til venstre, den OCR-genkendte tekst.

screenshot-2023-12-02-at-15-08-46-ocr-test-paperless-ngx.png

Under installationen havde jeg installeret Tesseracts OCR-moduler på dansk, tysk og engelsk. Tesseract blev udviklet af Hewlett-Packard i 1980′erne, som udgav det som Open Source i 2005 sammen med universitetet i Nevada, Las Vegas, USA. Året efter startede Google med at sponsorere udviklingen, og har gjort det lige siden.

Den engelske OCR fungerede rimelig godt, selv på bogsider, der var en smule skæve. Der var enkelte ord, der ikke blev genkendt korrekt, men det skal man forvente, når man bruger OCR-software.

Den danske del af Tesseract OCR har problemer med ø og å, der bliver genkendt som o og a, men sjovt nok ikke med ‘æ’, det kan være fonten, som er “tynd” på bestemte steder. Lige der kunne jeg godt tænke mig bedre muligheder for at man kunne se og finjustere indstillingerne inde i Paperless. Jeg prøvede at gemme kildematerialet som sort/hvid i 1200 ppi med en fed (bold) skrifttype, men det gjorde ingen forskel.

Udover OCR-integrationen, som må siges at være den feature, der “sælger” systemet, så fremstår brugerfladen nem og lige til… Jeg kan generelt godt lide brugerflader, hvor opsætningen er holdt minimalistisk og simpel - sekundært placerede knapper, der ikke er i brug, vises kun når du skal bruge dem. Less is more, simpelthen.

Dokumenttyper og emails

Du kan bede Paperless om at indklassere dokumenter efter bestemte ord (tags, eller etiketter på dansk). Så hvis du bruger ordet “Årsrapport”, så vil den kyle alle rapporter i en bestemt mappe med bestemte etiketter. Men det forudsat, at OCR’en er fejlfri på dansk. Jeg har ikke nået at teste denne del gennemgående, men jeg opdaterer opslaget her i så fald.

Paperless kan ligeledes indstilles til at overvåge indkomne emails fra bestemte konti og så klassificere dokumenterne efterfølgende.

Til sidst - ønsker

Jeg kunne som nævnt godt tænke mig flere muligheder for at justere importindstillinger på OCR’en i selve Paperless. Konverteringsmessigt er der intet at klage over, generelt genkendte systemet alt, jeg smed efter det. Den insisterede på at køre OCR på det hele, sikkert pga. klassificeringsfunktionen, og det er superfedt at se OCR-genkendte ord dukke op i søgeindekset af sig selv. En upload kan godt tage noget tid, når det skal scannes under import. Et billed på 3000×3000 pixel (1200 ppi) tog mig ca. 15-20 sekunder.

Den danske oversættelse af Paperless backenden er ikke helt komplet, men absolut brugbar. Mulighed for at installere ekstra plugins er der ikke. Derved ville man f.eks kunne tilpasse systemet til bestemte arbejdsmønstre eller bestemte brancher. Parrede man f.eks systemet med Python PIL eller Pillow, ville systemet blive en temmelig kapabel backend til grafiske virksomheder. Desværre skriver udviklerne i dokumentationen at plugins næppe bliver en realitet. Det synes jeg er en skam, men okay, at koncentrere sig om kernefunktionaliten er også en mulighed at undgå, at systemet bliver for bredt.

Manglen på pluginudvidelser kompenseres dog af, at man kan tilføje specielle felter til sine dokumenttyper, og af muligheden for at bruge et REST API for at få Paperless til at arbejde sammen med andre typer software. Dermed altså stadig rige muligheder for integration med systemer udefra.

Alt i alt et solidt opensource produkt, som jeg sagtens kan anbefale at afprøve.

Installation og screenshots:
https://docs.paperless-ngx.com/setup/
https://docs.paperle … #paperless-a-history