Bezpieczne języki programowania

Mam takie pytanie: o co chodzi z bezpieczeństwem pamięci (memory safe) w językach programowania?
Rząd Stanów Zjedn. uznaje następujące języki za bezpieczne:

Go
Rust
C#
Swift
Java
Ruby
Python
Delphi/Object Pascal
Ada

(źródło https://readwrite.com/the-nsa-list-of-memory-safe-programming-languages-has-been-updated/
https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY_V1.1.PDF)

Dlaczego C/C++ są niebezpieczne a Python (czyli w zasadzie język skryptowy a nie klasyczny język programowania) jest podobno napisany w C już jest bezpieczny?
Z kolei Java to mi jako użytkownikowi kojarzy się z niebezpieczeństwem i grami Java na zabytkowe Nokie, wyłudzającymi SMS-y
Jak widzę że program na PC wymaga wgrywania Javy to unikam jak ognia.

Python jest w napisany w C, ale jest warstwą nad C, i nie zrobisz w nim przepełnienia bufora.

Z kolei Java to mi jako użytkownikowi kojarzy się z niebezpieczeństwem i grami Java na zabytkowe Nokie, wyłudzającymi SMS-y

W bezpieczeństwie języka nie chodzi o to, czy można w nim napisać wirusa, tylko o to, jak łatwo można w nim zrobić błąd ułatwiający shakowanie systemu który piszemy.

@Manna5: Tutaj chodzi też o problemy z zarządzaniem pamięcią, co prowadzi do crashy i innych nieprzewidzianych sytuacji.

Bezpieczne języki pamięci pomagają minimalizować ryzyko błędów zarządzania pamięcią i związanych z nimi luk bezpieczeństwa, które stanowią poważne zagrożenie w aplikacjach produkcyjnych i systemach krytycznych. Wybór języka bezpiecznego pamięciowo zmniejsza ryzyko błędów i ułatwia tworzenie niezawodnego, odpornego na ataki oprogramowania.

A tak spytam z ciekawości, które z tych bezpiecznych języków są warte nauki, mają dobrą dokumentację i kompilują się do Windowsowego EXE (oraz dla Linuxa), jednocześnie nie wymagają potem dogrywania od użytkowników dodatków?

Bo ja jako użytkownik różnych programów nigdy nie lubiłem gdy trzeba dograć np. Javę.

Python to inna sprawa bo to to przydatne na co dzie narzędzie i na pewno uważam że Pythona warto się uczyć i mieć go zainstalowany, tylko zmieniam domyślne skojarzenie dla plików py na edytor żeby przypadkiem czegoś dziwnego nie uruchomić.

Crash programu to tam pikus. Taki niepozorny stack/buffer overflow moze(* mogl) doprowadzic do przejecia stosu wywolan i zmienic flow programu

https://en.wikipedia.org/wiki/Return-oriented_programming

@SiedemBoleści Warto, w jakim sensie? Dla przyjemności, biznesowo?

SiedemBoleści napisał(a):

A tak spytam z ciekawości, które z tych bezpiecznych języków są warte nauki, mają dobrą dokumentację i kompilują się do Windowsowego EXE (oraz dla Linuxa), jednocześnie nie wymagają potem dogrywania od użytkowników dodatków?

Praktycznie wszystko. Golang to największy pewniak, który pójdzie na wszystkim. Rust podobnie, możliwe, że wymagane jest doinstalowanie vc++ runtime redistributable (co jest wymagane też dla C++). C# chyba też pozwala na kompliację w trybie AOT tak, że wynikiem jest .exe/binarka

Dodaj cytat.. Warto, w jakim sensie? Dla przyjemności, biznesowo?.

Ja zawodowym programistą to nie jestem i nie planuję być ale mam różne pomysły znam trochę Pythona i niewiele C++ ale Python bardziej mi się podoba.
Ale skoro to jest polskie forum to chyba "biznesowa" opcja też by wielu
zainteresowała żeby tworzyć większą konkurencje dla programistów z USA i Chin

SiedemBoleści napisał(a):

A tak spytam z ciekawości, które z tych bezpiecznych języków są warte nauki, mają dobrą dokumentację i kompilują się do Windowsowego EXE (oraz dla Linuxa), jednocześnie nie wymagają potem dogrywania od użytkowników dodatków?

Bo ja jako użytkownik różnych programów nigdy nie lubiłem gdy trzeba dograć np. Javę.

od dawna preferowaną opcją jest dystrybuowanie javy wraz z aplikacją. wybierasz dystrybucję javy darmową do użytku komercyjnego (np. https://adoptium.net/ ) i instalujesz oraz aktualizujesz wraz z własną apką. tak działają np. ide od jetbrainsów (aczkolwiek oni idą dalej i mają własny friendly fork javy).

javę możesz skompilować do natywnej apki (czyli np. bez kompilacji jit) za pomocą https://www.graalvm.org/latest/reference-manual/native-image/ ale to raczej przygoda dla znawców javy.

slsy napisał(a):

chyba też pozwala na kompliację w trybie AOT tak, że wynikiem jest .exe/binarka

JITowa wersja to też .exe, a na dodatek możesz zrobić single file publish który będzie zawierał w sobie dotnet runtime :P

SiedemBoleści napisał(a):

Bo ja jako użytkownik różnych programów nigdy nie lubiłem gdy trzeba dograć np. Javę.

Wgrywania Javy do odpalenia aplikacji desktopowej też nie lubię (patrz Minecraft). Ale jest masa aplikacji które nie są takimi programikami, które ty jako użytkownik końcowy, bezpośrednio odpalasz u siebie. Np. backend dla aplikacji webowej.

Przy wdrażaniu takiego backendu dogrywanie Javy to nie problem, bo albo robisz to raz na dany serwer, albo wdrażasz aplikację skonteneryzowaną. No i robią to deweloperzy, a ty jako użytkownik końcowy nie musisz nic robić poza uruchomieniem swojej przeglądarki.

SiedemBoleści napisał(a):

Mam takie pytanie: o co chodzi z bezpieczeństwem pamięci (memory safe) w językach programowania?
Rząd Stanów Zjedn. uznaje następujące języki za bezpieczne:

Go
Rust
C#
Swift
Java
Ruby
Python
Delphi/Object Pascal
Ada

(źródło https://readwrite.com/the-nsa-list-of-memory-safe-programming-languages-has-been-updated/
https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY_V1.1.PDF)

Dlaczego C/C++ są niebezpieczne a Python (czyli w zasadzie język skryptowy a nie klasyczny język programowania) jest podobno napisany w C już jest bezpieczny?
Z kolei Java to mi jako użytkownikowi kojarzy się z niebezpieczeństwem i grami Java na zabytkowe Nokie, wyłudzającymi SMS-y
Jak widzę że program na PC wymaga wgrywania Javy to unikam jak ognia.

irytujace sa bardzo sugestie negatywne na temat Java wsrod osob, ktore nie maja pojecia o Java

Java's Safety Aspects
Java is considered one of the safer languages and was designed with security in mind from the start. Here’s how it stacks up:

Memory Safety: Java uses an automatic garbage collector, reducing risks of memory leaks and pointer-related vulnerabilities, such as buffer overflows. It also doesn’t allow direct memory access (like C/C++), which eliminates many risks.
Type Safety: Java’s static typing catches many potential errors at compile time. Type safety is enhanced by strong type-checking.
Sandboxing: Java runs code within the Java Virtual Machine (JVM), isolating applications in a sandbox, which restricts unauthorized access to the system.
Concurrency Safety: Java’s concurrency features (like synchronized blocks and the java.util.concurrent package) provide tools for writing concurrent code safely. However, they require proper use, as concurrency issues are still possible if not carefully managed.
Security Updates: Java has an extensive history of updates focused on security, particularly in the corporate and web application domains.

pvw napisał(a):

Sandboxing: Java runs code within the Java Virtual Machine (JVM), isolating applications in a sandbox, which restricts unauthorized access to the system.

to powinno wylecieć z materiałów o javie. ten sandboxing nigdy nie działał dobrze, a dodatkowo w przygotowaniu jest wywalenie sandboksa:
https://openjdk.org/jeps/486 JEP 486: Permanently Disable the Security Manager

Non-Goals
It is not a goal to provide a replacement for any of the Security Manager's functionality, in particular the ability to sandbox Java code.

https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024-9632/

jarekr000000 napisał(a):

https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024-9632/

fresh:

https://old.reddit.com/r/cpp_questions/comments/1getghf/us_state_told_our_company_to_not_develop_in_c/

I am working for a US cyber security company and the state told our company to change our application's language which already has been developed by C++, because it's an unsafe language. This is a 3-years requirement.

This decision made me think about my career. Is C++ considered a bad language now?!

Note: Our team says we should pick Rust but it's not confirmed

WeiXiao napisał(a):

This decision made me think about my career. Is C++ considered a bad language now?!

a kiedyś nie był? Tylko szaleńcy i hobbiści w nim piszą, trzeba być zwariowańcem żeby pisać w c++ cokolwiek innego niż program rysujący choinkę. Zwłaszcza odkąd są bezpieczniejsze alternatywy z tym samym performancem

A comparison of Rust’s borrow checker to the one in C#

WeiXiao napisał(a):

A comparison of Rust’s borrow checker to the one in C#

nie czytałem całości jakoś uważnie, ale odnosząc się do https://em-tg.github.io/csborrow/#why-does-nobody-seem-to-be-talking-about-this

Why does nobody seem to be talking about this?

Maybe I’m bad at searching for these things, but these changes to C# seem to have gone completely under the radar in places where you read about memory safety and performance. Maybe it’s just because the language additions have happened super slowly, or maybe the C# and Rust communities have so little overlap that there aren’t enough people who program in both languages to notice the similarities. Maybe there’s something that makes C#’s ref subset so unusable that people just ignore it (I’ll admit to only having played around with it a bit, so far).

Here’s my theory: C# already had an equivalent to all of these things in its “unsafe” subset, so when introduced, ref-safety changes were typically framed as “bringing the performance of safe code closer to that of unsafe code,” which is arguably the opposite perspective of Rust’s “bringing the safety of high-performance code closer to that of high-level languages.” Perhaps that framing makes people miss that although the two languages are pushing in opposite directions, they might actually be getting closer together.

jak z samego artykułu wynika, refy z c# są biedne w porównaniu do rusta jeśli chodzi o możliwość wyrażania lifetime'ów. borrow checker w ruście jest po to, żeby móc całkowicie zrezygnować z gc, a tymczasem w c# refy mają ustawione lifetime'y na sztywno (co je mocno ogranicza) i integrują się z gc, co zwiększa ich możliwości (przybliża do możliwości rusta). ograniczeniem refów w c# jest np. to, że nie da się ich użyć w kodzie typu async.

największą praktyczną różnicą między refami z c#, a borrow checkerem z rusta jest to, że refy w c# to nisza, a borrow checker w ruście to podstawa całego kodu. jedynym sposobem, żeby wyłączyć borrow checkera w ruście jest kod unsafe. tak czy siak, mimo niszowości, refy z c# wyglądają na ciekawy bajer.

Wibowit napisał(a):

ograniczeniem refów w c# jest np. to, że nie da się ich użyć w kodzie typu async.

od c# 13 można używać refów w async i asynchronicznych iteratorach

obscurity napisał(a):

Wibowit napisał(a):

ograniczeniem refów w c# jest np. to, że nie da się ich użyć w kodzie typu async.

od c# 13 można używać refów w async i asynchronicznych iteratorach

ale tylko lokalnie, więc przerzucanie danych poprzez yield i async boundary musi się odbyć bez refów:
https://devblogs.microsoft.com/dotnet/csharp-13-explore-preview-features/#ref-and-unsafe-in-async-methods-and-iterators

ref and unsafe in async methods and iterators

Prior to C# 13, iterator methods (methods that use yield return) and async methods couldn’t declare local ref variables, nor could they have an unsafe context.

In C# 13, async methods can declare ref local variables, or local variables of a ref struct type. These variables can’t be preserved across an await boundary or a yield return boundary.

In the same fashion, C# 13 allows unsafe contexts in iterator methods. However, all yield return and await statements must be in safe contexts. These relaxed restrictions let you use ref local variables and ref struct types in more places.

Wibowit napisał(a):

ale tylko lokalnie, więc przerzucanie danych poprzez yield i async boundary musi się odbyć bez refów

racja, jednak wydaje mi się że to było / jest głównym powodem braku zainteresowania refami w C#, jednak większość kodu w c# jest / staje się asynchroniczna bo async szerzy się wirusowo i tego refa praktycznie nigdzie się nie dało używać co wydaje mi się że jest odpowiedzią na pytanie autora artykułu