Bristande säkerhet i öppna källkod-projekt

Utifrån källan går det inte att dra den här slutsatsen, den visar bara råa siffror utan någon analys.

De senaste åren har det upptäcks många fler sårbarheter i Chrome än i Firefox. Att det historiskt har upptäckts fler sårbarheter i Firefox kan bl.a bero på att Chrome är mycket nyare och har undvikit vissa fallgropar som Firefox hade/har. Firefox har väl gått över till Rust i en del av koden, så mängden minnesrelaterade CVEs borde gått ner.
Firefox har historiskt varit mer öppen vad det gäller extensions och browserändringar, det ger en större attackyta.

Firefox kanske har haft ett bättre bug bounty program. Nu verkar det vara rätt så likt.

Osv.

Det blir ju dock lite galet att jämföra siffror för en distribution med *massor* av applikationer inräknade med t.ex. Windows där så ej är fallet (jag kan ha missuppfattat, men det lät så?).

Det som verkar driva på är väl främst vad det går att få pengar för. Och då är det ju saker som många använder, rent generellt.
Och i det läget så kan man ju kosta på sig att ha folk som kan läsa assembly...

Så nej, jag upplever inte heller att det är någon milsvid skillnad för de viktigaste projekten. Men det är olika dynamik, oavsett projektstorlek.

Ja, Chrome är *mestadels* open source, och fel i "Chrome" är oftast i praktiken fel i Chromium och då finns ju samma fel typiskt även i Edge, Brave, Vivaldi, Opera, etc...

Det kan jag förstå, min poäng var mer att det finns lägen där icke open-source är ett bättre alternativ.

Ja, men det är ett kompromissande. Man är typiskt medveten om att det är problematiskt att inte fler granskar koden, men det finns fler faktorer att beakta.

Jo tack, jag är själv utbildad spelprogrammerare.

Unity är i det här kontextet en intressant spelmotor, då den är byggd med C++ men har C# som ett scripting språk. Dock har Unity moduler som ger en åtkomst till direkt minneshantering, som t.ex Unity.Collections som har klasserna NativeArray och NativeList, vilka används flitigt inom Unity DOTS.

Bristande säkerhet handlar i det här fallet inte om att det måste ha hänt något, det handlar om att risken är påtaglig att någon säkerhetsincident kan inträffa. Anledningen till den förhöjda risken är användningen av minnesosäkra språk. Det är som när det sker en inspektion och det finns några saker att förbättra. Syftet är att förebygga, innan något allvarligt inträffar.

Just i fallet NativeArray/NativeList får man egentligen inte någon extra prestanda så länge man bara befinner sig i C# kontext jämfört med System.Collections.Generic. Är inte helt med på exakta detaljer kring NativeArray, men gissar att det primärt handlar om att man där allokerar en "vanligt C/C++ buffert" där den (virtuella) adressen är fixerad så länge man inte friar minne.

Det man slipper i hoppet mellan C# och C/C++ med NativeArray är att "låsa fast" minnet medan man befinner sig i C/C++ kontext (så inte GC får för sig att flytta data i virtuellt RAM space).

Ur det "säkerhetsperspektiv" denna artikel handlar om är det ingen skillnad, även NativeArray verifierar att man inte skriver utanför gränserna. Men en rätt trevlig sidoeffekt man typiskt får från de egenskaper man behöver i ett GC-språk är att en "pekare" inte är pekare i C/C++ mening, utan är mer det man i C/C++ kallar "handles", det trevliga är att sådant minne kan flyttas runt i (virtuellt) address-space utan att "pekare" till minnet blir ogiltiga.

Sen är Unitys användning av C++ också ett målande exempel på att användandet av C++ inte nödvändigtvis betyder bättre prestanda. Så länge man inte använder IP2CPP kör man ju en (mono-baserad) virtuell maskin, d.v.s. helt "normal" .NET/C# beteende.

Men prestandamässigt är VM:en Unity använder rätt kass ställd mot .NET-core ramverket (som är nästan helt skrivet i C# sedan övergången till Roslyn). Gjorde några snabbtester, .NET 8 är lika snabb eller snabbare än Unity med IL2CPP som i sin tur är nästan dubbelt så snabb som "vanliga" Unity maskineriet (som är C++ baserat under huven).

Det kändes rätt avlägset på 90-talet när man sa "det är teoretiskt möjligt att Java med JIT kommer kunna bli lika snabbt eller till och med snabbare än C/C++". Man var inte nära under många år, men det har hänt väldigt mycket inom det området under de snart 30 år det gått sedan Java lanserades. Idag är faktiskt de bästa JVM:erna och CLR:erna på den prestandanivå man pratade om.

Kanske inte super-relevant till just spel, men finns faktiskt en del optimeringar relaterade till multi-thread som är möjliga när man har en GC men som inte kan göras utan explicit synkronisering med avsaknad av GC (för att undvika ABA-problemet).

DOTS är ju ett annat exempel (utöver modern JIT) där man i praktiken kan få bättre prestanda i högre nivå ramverk jämfört med normal C/C++. Visst kan man hantera SOA och fördelning av data på ett säkert och optimalt sätt direkt i C/C++, men det är otroligt komplex och lätt att göra fel. DOTS, eller mer ECS, sätter en del krav på hur man skriver sitt program och p.g.a. av det kan man göra rätt coola optimeringar (inte helt olikt Nvidia CUDA kan köra skalär kod på tusentals "CUDA-kärnor").

Angående C++ så är det inte utdöende inom i princip allt där prestanda inte är superviktigt?

Alltså folk eftersträvar en lösning som är så billig som möjligt, det ska vara en lösning som folk lätt kan lära sig, många ska kunna koda den och bra säkerhet emot misstag ska finnas.
Ofta så är dessutom programmering bara en delkunskap man ska ha utan man behöver ha domänkunskap av det som man ska styra.

Företag brukar inte gilla detta att folk gör mer komplicerade lösningar i onödan så att de på något sätt blir outbytbar, tvärtom ska lösningen vara sådan så att fler personer har möjlighet att fortsätta med så kort uppstartssträcka som möjligt.
Skräckexemplet kan vara elektrikern som gör en c++ lösning och sedan ska de hitta en annan behörig elektriker som också kan c++.

Om du tycker det är acceptabelt att utgå från reaktivitet när det gäller säkerhet så säger det mer om dig än mig. Saker ändrar på sig, varesig du tycker jag är en dumsnut eller ej

Det är inget jag har påstått eller någonsin skulle påstå. Jag har bland annat utvecklat en säker remote access-lösning för ett världsledande bolag med miljontals kunder för referens. Dumsnuten är alltså ett användarnamn på en Swec-medlem. Så var det det här med läsförståelsen

Själv är jag inte utvecklare utan jobbar med nätverk och säkerhet.

Ska förtydliga min poäng då min retorik varit bristfällig hittills.

Open-source har absolut starka fördelar men tillika så svagheter. Beroende på vad det är som ska uppnås är det inte nödvändigtvis passande att utgå från open-source.

Vad man ska uppnå dikterar, likaså hur man hanterar utvecklingen. Ett uselt hanterat open-source projekt är garanterat mer osäkert än ett korrekt hanterat projekt som inte är open-source.

Om allt hanteras som det ska så är open-source rätt val i en majoritet av fall, dock inte alla. Men allt hanteras inte korrekt, misstag görs, genvägar tas. Det är människor vi pratar om. För att inte tala om hur organisationerna som bygger sin verksamhet på brottslighet blir allt duktigare på att nyttja sårbarheter (inte bara kodmässiga sådana).

Jag håller helt med dig i det du skriver ovan. Jag har jobbat med/mot open source-projekt både privat och professionellt de senaste 15-20 åren.

Huvudpoängen var att rubriken är dåligt formulerad som inte gör skillnad på faktum och risk. Det står jag fast vid.

Efter omläsning av både artikel och tråd så håller jag klart med om tvivelaktig presentation av redaktionen. Hoppas med att lågvattenmärket är uppnått, men vi får väl se hur det blir med det.

Jag hängde upp mig för mycket på detaljer, även om det jag fokuserade på är relevant till ämnet. Samt läste vissa inlägg/svar slarvigt vilket producerade några av mina mindre genomtänkta svar. Ibland blir det fel helt enkelt, ursäkta min låga nivå där ett tag.