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.

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++.