Futurebeat Darmowe nie oznacza dobre - przykładem programy open-source

Niestety nie widzę, żeby była możliwość poczytania sobie tego raportu. Te tezy są absurdalne. W dodatku cały tekst jest ubogi w szczegóły.

"oprogramowanie open source wiąże się z ryzykiem"
Dlatego właśnie w społeczności specjalistów od bezpieczeństwa praktycznie od zawsze istnieje konsensus, że najbezpieczniejsze są rozwiązania otwarte. Pozwólcie, że oddam głos ekspertowi:
"Jako specjalista od kryptografii i cyberbezpieczeństwa, nigdy nie rozumiałem, dlaczego ruch oprogramowania otwartoźródłowego jest taką sensacją. W świecie kryptografii od dziesięcioleci uważamy otwarte źródło za konieczne do osiągnięcia wysokiego bezpieczeństwa. Publicznie dostępne bezpieczeństwo jest zawsze lepsze, niż bezpieczeństwo własnościowe. To sprawdza się w algorytmach kryptograficznych, protokołach bezpieczeństwa i związanym z bezpieczeństwem kodem źródłowym. Dla nas otwarte źródło nie jest po prostu modelem biznesowym, tylko mądrą praktyką inżynieryjną." Bruce Schneier, 1999
https://www.schneier.com/crypto-gram/archives/1999/0915.html#OpenSourceandSecurity

I nic się w tej kwestii od tego czasu nie zmieniło.

"większość z nich [programistów] nie jest ekspertami ds. bezpieczeństwa i nie potrafiłoby wykryć ewentualnego zagrożenia."
No patrzcie, to dokładnie tak jak większość programistów pracujących przy programach o zamkniętym kodzie. Po to właśnie Bóg wymyślił audyty bezpieczeństwa i stworzył "bezpieczników" i programy "bug bounty", żeby sprawdzali, co programiści zepsuli. Popularne i związane z bezpieczeństwem otwartoźródłowe programy przechodzą takich audytów (oficjalnych i nieoficjalnych) więcej, niż własnościowe.

"Dotyczy to również popularnego serwera HTTP, który obsługuje obecnie znaczną część wszystkich witryn internetowych. Wykorzystano w nim około 320 projektów open source, które zawierają sporo luk"
Projekty open source często korzystają z innych projektów open source (a których mogą kryć się luki). Tak samo robią projekty własnościowe (chociaż nie mogą użyć każdego kodu OS, bo licencja nie zawsze pozwala). To normalne i ma sens, bo po co wyważać otwarte drzwi i pisać własną implementację np. pakowania i wypakowania zipów, jeśli można użyć istniejącej biblioteki? Oczywiście rozsądek nakazuje wybrać aktywnie rozwijaną, w której ewentualne błędy są łatane i ją sobie odpowiednio aktualizować.

"sprawdziła dziesiątki tysięcy projektów open source, odkrywając w nich masę luk bezpieczeństwa. Z badania wynika, że aż 82 procent programów open source, z których korzysta wielu z nas, ze względu na brak poprawek stwarza ryzyko dla użytkownika."
Jakich projektów? Oprócz Apahe, nic w tym tekście nie jest wymienione z nazwy. Co to konkretnie były za projekty i czego dotyczyły? Ile z nich było popularnych i rzeczywiście powodujących ryzyko? Jakie konkretnie były klasy podatności i jak poważne? Bo jak sobie napiszę otwartoźródlowy program graficzny, w którym zrobię podatność polegającą na tym, że odpowiednio spreparowany plik jpg mi zawiesi program, to żadna luka bezpieczeństwa, bo możliwe szkody są niewielkie (irytacja użytkownika) i (co ważniejsze) nikomu się w ogóle nie będzie chciało wyszukiwać i wykorzystywać podatności w moim programiku, który jest tak popularny, że używam go tylko ja i jeszcze 2 osoby z mojej najbliższej rodziny, bo nie chciały mi robić przykrości i powiedzieć, że program o kant tyłka rozbić.

Co ważniejsze programy otwartoźródlowe są dość dokładnie sprawdzane, zwłaszcza jeśli są związane z bezpieczeństwem (np. ProtonMail/VPN, Signal, KeePass, VeraCrypt) albo po prostu popularne (Notepad++, VLC).

Jakoś Linux i Mozilla pokazują, że większość błędów jest łatana w parę dni. Nie raz czytałem art o nowej, super podatności, na którą dzień wcześniej zainstalowałem poprawkę. Także dziękuję za uświadomienie. Każdy program zawiera błędy. Błąd można odkryć, nie analizując jego źródeł. Za to dostępność źródeł ułatwia jego naprawę. Trudno naprawić błąd, gdy producent programu nam tego zabrania.