Znaczy sie przestaną korzystać z Linux'a w router'ach? Chyba jakiś urzędas nie wiedział co pisał...

@99xmarcin: zabawne jest to, że akurat w tym przypadku to zalecenie wydaje się być bardzo zasadne i to "głupi urzędas" musi wymusić na inżynierach aby zaczęli bardziej myśleć o security

The development of new product lines for use in service of critical infrastructure or NCFs in a memory-unsafe language (e.g., C or C++) where there are readily available alternative memory-safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.

oraz

Recommended action: Software manufacturers should build products in a manner that systematically prevents the introduction of memory safety vulnerabilities, such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities. Additionally, software manufacturers should publish a memory safety roadmap by January 1, 2026.

jeżeli będziesz chociaż trochę szczery sam ze sobą, to powinieneś dojść do wniosku że ta rekomendacja jest rozsądna.

Zawsze przy takich zaleceniach trzeba też mieć olej w głowie. Nikt nie będzie przepisywał Linuxa i Windows'a na Rust'a bo tak urzędnik powiedział. W C/C++ zainwestowano miliardy man-daysow, tego nie da się zmienić w 2 lata. Ja rozumiem pozbądźmy się C++ w dekadę ale na pewno nie w rok.

Na koniec koszta, może się okazać że JVM na routerze to zły pomysł, trzeba będzie wymieniać tony sprzętu. Ktoś będzie musiał za to zapłacić. Jakoś tego nie widzę zwłaszcza gdy Elon Musk będzie odpowiadał za wydatki urzędnicze w administracji Trumpa ;)

@tBane: A weź podeślij primary source, bo to co wkleiłeś z android.com.pl to tak nie do końca.

@Riddle: przecież masz tam wyraźnie Raport CISA „Product Security Bad Practices”

@99xmarcin: ale do czego ty się odnosisz? przecież w zacytowanych przeze mnie fragmentach tego raportu nikt nie pisze że mają łindołsa czy linóksa przepisywać na Rusta czy C#, a The development of new product lines for use in service of critical infrastructure or NCFs in a memory-unsafe language (e.g., C or C++) where there are readily available alternative memory-safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.

@99xmarcin: ja nawet nie rozumiem z czym ty próbujesz dyskutować - wystarczy spojrzeć na raporty typu: https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/ Figure 1: ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues czy https://www.chromium.org/Home/chromium-security/memory-safety/ Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.. Więc rekomendacja aby przestać pisać krytyczny soft w tym jest zasadna i nie są to jakieś urojenia urzędników

@99xmarcin: W C/C++ zainwestowano miliardy man-daysow, tego nie da się zmienić w 2 lata z tego co ja rozumiem, to w dwa lata masz przygotować plan walki z mem. issues For existing products that are written in memory-unsafe languages, not having a published memory safety roadmap by January 1, 2026 is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety. The memory safety roadmap should outline the manufacturer’s prioritized approach to eliminating memory safety vulnerabilities in priority code components (e.g., network-facing code or code that handles sensitive functions like cryptographic operations). Manufacturers should demonstrate that the memory safety roadmap will lead to a significant, prioritized reduction of memory safety vulnerabilities in the manufacturer’s products and demonstrate they are making a reasonable effort to follow the memory safety roadmap. This does not apply to products that have an announced end-of-support date that is prior to January 1, 2030.

@WeiXiao: czyli bronisz obwiniania technologii za brak umiejętności jej używania.

@Malowanie_Kostki_Rubika: 1) Poleganie na ludziach się nie skaluje. Nieskończenie ciężej jest nauczyć czegoś miliony programistów aniżeli zbanować w kompilatorze. 2) Technologia może być słabo zaprojektowana, np. może bardziej "zachęcać" do zrobienia sobie krzywdy niż powinna jest to konieczne.

@WeiXiao: przecież filozofia niskopoziomowych technologii jak C to wykręcanie jak największej wydajności poprzez danie dostępu do wszystkiego, do czego można dać dostęp. Aplikacje krytyczne nie kojarzą mi się z brakiem priorytetyzacji wydajności.

@Malowanie_Kostki_Rubika: Aplikacje krytyczne nie kojarzą mi się z brakiem priorytetyzacji wydajności. ok, to o ile Rust jest wolniejszy od C? Podaj wartość - 3%? 10%? 20%? Oczywiście upraszczamy tutaj, ale weźmy jakiś punkt odniesienia aby móc iść dalej.

@WeiXiao: zakładając, że dałoby się wyeliminować w 100% błędy związane z memory leakami w jakimś języku programowania. A jak wiadomo w Javie też są memory leaki. To jaki jest drugi najczęstszy powód zgłaszania błędów w oprogramowaniu? I czy ustawa będzie go w stanie podobnie wyeliminować?

@twoj_stary_pijany: 1) Ograniczenie z np. 100 do 10 memory issues CVE to nadal ogromna poprawa, szczególnie w sofcie na którym polegają miliony osób. 2) przecież jakbyś zaczął czytać ten raport to byś zauważył że tam omawiane są również inne rzeczy typu Inclusion of User-Provided Input in SQL Query Strings, Inclusion of User-Provided Input in Operating System Command Strings i więcej :D I czemu używasz słowa "ustawa"?

@WeiXiao: bo CISA to są przecież urzędasy.

@WeiXiao: ale skąd wiadomo, że tyle memory issues, które jest teraz to jest dużo albo mało? Czy to jest do czegoś porównywane? Przez analogię, czy da się wyeliminować wszystkie wypadki drogowe? Czym jest dokładnie to memory roadmap, którego chcą?

@twoj_stary_pijany: bierzesz sobie listę CVE w twoim sofcie, patrzysz że 70% to memory issues które są fixowalne (no bo dostają fixy) i zastanawiasz się zastanawiać gdzie jest problem. Patrzysz że np. w innej tech tych memory issues to jest 7% i dalej się zastanawiasz, aż może dochodzisz do wniosku że coś tu trzeba poprawić :D

@WeiXiao: ok, a mógłbyś podać jakieś dwa przykłady technologii które porównujesz? Tzn. ja myślę, że jeżeli np. w C++ jest zwykle pisany jakiś konkretny soft, a w JS apki webowe to można się spodziewać, że profil CVE będzie trochę inny.

@twoj_stary_pijany: mogę cię jedynie przekierować do tych raportów od Microsofti i Googla które podlinkowałem wyzej.

@99xmarcin: Znaczy sie przestaną korzystać z Linux'a w router'ach? - teraz będą robić "rótery z interpreterem Pytonga" :-) Może troszkę sieć spowolni ale co tam... Chyba, że kupisz router z prockiem co ma TDP 1200W to wtedy będzie ok:-)

Bardzo by chcieli abyśmy przenieśli się na te gówna jak rust etc. Ale my nie chcemy ;-)))))))

Czyli jak rozumiem z komentarzy - rząd rezygnuje z języków C z powodu słabego skilla programistów ?

Ja tam mogę pisać w Rust day one, ale tu chodzi o tony softu już napisanego, przetestowanego, wygrzanego na produkcji. Przepisanie tego na Rust zajmie dekady... ale co tam niech będzie popieram, będzie znów praca dla programistów jak przy problemie 2000, zacierajmy ręce i czekajmy na szekle...

A rust już ma to swoje stabilne ABI, czy nadal w lesie ? ha ha ha ha ha

@99xmarcin: ale tu chodzi o tony softu już napisanego, przetestowanego, wygrzanego na produkcji. Przepisanie tego na Rust zajmie dekady... ???????????????????????????? ty w ogóle przeczytałeś o co chodzi? :D Serio, zamiast klepać 10 komentarzy na podstawie wyimaginowanych wyobrażeń można po prostu przeczytać te rekomendacje i zobaczyć o co chodzi :D

@ksh: a jakie języki mają stabilne ABI w standardzie?

@tBane: tak, jeśli język jest tak słaby, że mimo 50 lat istnienia dalej nie mamy dobrych programistów w nim, to coś jest chyba nie tak z językiem, a nie z programistami.

@ksh: jedyne abi jakie znam, które jest używane do integracji wielu języków to abi języka c i z tego powodu zarówno c++ jak i rust (oraz java, c# itd w zasadzie wszystkie inne aktualnie używane języki) używają abi języka c do ffi (integracji z innymi językami).

@twoj_stary_pijany: wycieki pamięci są w każdym języku, ale cve raczej nie są związane z wyciekami pamięci (czyli marnowaniem zasobów, które w skrajnym przypadku doprowadza do ubicia apki), a wyciekami danych (czyli naruszeniem bezpieczeństwa) czy nadpisaniem wrażliwych obszarów pamięci.

A tym już było chyba nawet kilka razy.

@hauleth: @tBane być może po prostu jak ktoś staje się dobrym programistą to przestaje pisać w C, całkiem zrozumiałe zresztą.

@Wibowit: przy czym C technicznie nie ma stabilnego ABI, tylko tak wszyscy przyjęli, że będzie stabilne, przez co C obecnie jest bardziej IDL (Interface Definition Language) niż językiem programowania. Rozdzielenie tych dwóch rzeczy wyszło by na plus zarówno C jak i interfejsom.

@twoj_stary_pijany: wycieki pamięci nie są problemem bezpieczeństwa. Rust nawet explicite definiuje, że wyciek pamięci jest bezpieczny, std::mem::forget jest jak najbardziej bezpiecznym Rustem. Ogólnie nie da się napisać języka programowania, w którym nie ma wycieków pamięci, bo zawsze możesz zadeklarować jakąś wartość, obliczyć ją, a potem nigdy więcej jej nie użyć, a tylko trzymać gdzieś w pamięci bo zapomniałeś o niej. Rust nie chroni przed wyciekami pamięci, a przed używaniem zwolnionej pamięci, race conditions i innymi błędami pamięci.

no to nas załatwili :(

@johnny_Be_good: spokojnie, wszystkich nas nie zwolnią. Muszą mieć tych Cpp Developerów politycznych czy jak się ta k... będzie nazywać :)

@twoj_stary_pijany: tak terry davisa nie zwolnili, po prostu po zakończeniu kontraktu rozjechali pociągiem xD

Trochę dupny ten artykuł. utrata pamięci czyli zapewne koślawo przetłumaczone memory leak nie koniecznie a nawet rzadko kiedy powoduje problem bezpieczeństwa. Są nawet systemy, które ciekną "by design" w kontrolowany sposób, żeby paradoksalnie robić z pamięci jak najlepszy użytek. (edit) aa @hauleth już pisał coś w ten deseń

ale po co właściwie czytać ten polski artykuł i dyskutować na podstawie czyjejś interpretacji, gdy można wejść w oryginał?

@WeiXiao: w dziadowie mówimy "na podstawie czyjejś"

@WeiXiao: a co wyczytałeś takiego ciekawego w tym artykule skoro tam jest co najwyżej memory safety vulnerabilities, co w praktyce może oznaczać bardzo dużo rzeczy?

@twoj_stary_pijany: no właśnie w tym artykule nie ma nic sensownego i już lepiej przeczytać oryginalną rekomendacje zamiast pisać dziwne komentarze :D

Ruściarze nie ślińcie się, ja wiem że nie ma. Ha ha ha.

https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF - oryginalny raport jakby się ludziom nie chciało szukać

@hauleth: raport jak by komuś zależało na tym, żeby go ukryć!

@johnny_Be_good: czyli jednak spisek reptilian i wolnomularstwa.

Pewnie 100x lepiej wyszli by gdyby wprowadzili esperanto zamiast angielskiego. Jakby nie mogli tych luk bezpieczeństwa naprawić i zostawić składnie to tak jakby powiedzieć że jakiś samochód jest kiepski trzeba zacząć produkować nowy model a przy okazji zastąpić miejscami sprzęgło gas i hamulec. Tylko że IT łatwiej ludźmi manipulować niż w innych branżach bo nikt nikomu nie wciśnie że krzywa ściana to nowa technologia kładzenia ścian

@kamil kowalski przecież dane popierają ich wnioski, więc jaka manipulacja?

@kamil kowalski: nie ma krzywych ścian, tylko czasem wina brak

@WeiXiao: Jakie dane?

Największe kłamstwo tego raportu to:
It is worth noting that languages like C and C++ can help students understand how the computer works at lower levels. Jedyne co C robi to buduje fałszywe przekonanie, że się wie jak komputer działa na niskim poziomie.

@WeiXiao: Ale ludzie to leniwe buły, sporo osób pewnie nie przeczytało więcej niż nagłówek.

@jarekr000000: no nie do końca się zgodzę. Obecne komputery trochę działają jak C, bo C tego oczekuje. Więc trochę tak jest, ale to przez C, a nie dlatego, że C dobrze to pokazuje.