Proteger los sistemas tecnológicos críticos de posibles amenazas es una preocupación cada vez mayor para los gobiernos. Y un ejemplo de ello es el reciente llamamiento dirigido a la industria del desarrollo de software y realizado por la Casa Blanca a través de la Oficina de su Director Nacional de Ciberseguridad (ONCD) para que adopten lenguajes "seguros para la memoria"...
|
etiquetas: memoria , c , seguridad informática , lenguajes de programación , actualidad , oncd 
...
No hablan ni catalán ni castellano ni inglés, hablan "consulto". El lenguaje de los lamebotas, copypasteros de PowerPoints y Excels qué viven de call en call, gathereando informacion de tus equipos para luego hacerte el reporting.
Todo muy corporativo y profesional.
Programar punteros en C es como hacer malabares con el jabón en la ducha de la carcerl: todo es diversión hasta que cometes un fallo.
Otra cosa es la mala gestion de memoria, que viene del modelo de usar la memoria para tener datos y codigo, y el heap y la stack. De hecho, lo logico, que no ha hecho nadie hasta ahora, seria cambiar el paradigma de los compiladores y de la gestion de la memoria.
Precisamente eso es lo que ha hecho Rust. Incorporando, por una parte, el concepto de "propiedad" a los valores almacenados en memoria (liberando ésta cuando el propietario sale del scope) y el de "borrowing" (que permite acceder a los datos sin cambiar la propiedad) y, por otra parte, incorporando un montón de reglas al compilador (que evitan buffer overflows, race conditions, referencias nulas...), que C/C++ incluye, en el mejor de los casos, en analizadores estáticos.
el uso de punteros es necesario
Tanto Rust como C/C++ incluyen raw pointers, smart pointers, referencias... La diferencia es que Rust desaconseja los raw pointers (obligando a marcar el código como "unsafe").
C++ tiene más de 40 años y, aunque ha ido incorporando muchas mejoras a lo largo de los años, tiene serias carencias en cuanto a seguridad. En los últimos años se desarrollaron varios lenguajes que intentaban resolver estas carencias. A día de hoy, parece bastante claro que Rust ganó esa batalla y que acabe sustituyendo a C++ por completo será sólo cuestión de tiempo. Microsoft era el gran valedor de C++ y Linux el de C, y ambos están empezando a darles la espalda.
Ya no se puede secularizar.
Pero eso solo alivia algunos de los problemas, no resuelve el problema. Por qué el problema es el modelo de gestión de memoria y la forma en la que el programador se relaciona con el.
De hecho, por eso existe rust. Si fuese como tú dices, no haría falta rust para nada.
Para quién le intentese, mandé el otro día el comunicado de la Casa Blanca citado en el envio:
- www.meneame.net/m/tecnología/comunidado-prensa-casa-blanca-software-f
Especialmente en desarrollo de drivers y código que necesita alto rendimiento, el programador está muy tentado a saltarse todas las buenas prácticas. En Rust o Go, el riesgo está mucho más acotado y con un rendimiento similar.
Se algo de Rust y estoy haciendo cosillas y ya incluso mirando de usarlo pa un modulo relativamente grande en un futuro cercano, pero mientras le veo muy buenas maneras para como hacer ciertas cosas como programacion de tipos genericos ( para un sistema de GUI donde los componentes tengan propiedades adheribles dinamicamente y demas ) y mientras le veo cosas muy chulas y bien pensadas, ese memory safety con el tema de las move semantics forzadas, el borrowing y demas... me recuerda un poco al dobleprogramar del TDD.
Claro que, a traves de forzar ese "asignar es mover ownership" y algunas cosas mas ( boundary checking ) puedes conseguir evitar overflows, use after frees, etc., pero hombre... a cuesta de que, por mucho que aprendas y te hagas a programar asi, perder bastante tiempo y flexibilidad. No es, para nada, gratis, por muy experto que seas en Rust.
Y se que suena a cliche, pero segun que tipo de programacion hagas, los bugs y el tiempo depurando no suele ser por cagarla con estos problemas ( ya digo, ese 70% que dicen... nanai, en software de sistemas, si llega a un 30%... ) y en C ( C++ no sabria decir porque para proyectos propios uso C y ensamblador ) no haces apenas gambas en eso.
En fin, ya digo, voy a hacer un sistema GUI para un proyecto que tengo que tiene ya una libreria de interfaz en modo texto bastante potente ( tiene ya abstracciones de paneles, editores, y muchos gadgets mas ) con ciertas caracteristicas y puede que lo haga en Rust por lo que ofrecen los Traits y demas. Va a ser Rust sin runtime ( esa es otra, por mucho que use musl o mi propio runtime que tengo hecho para ejecucion en UEFI/NT, a ver como hago para tener el control de todo eso... ) o, digamos, como el proyecto que tendo no depende de nada, de nada nada, es todo a pelo usando memoria y registros, a ver como me toca los cojones Rust en eso... va a ser un problema, por mucho que digan que Rust bien pa embedded... no es C.
En fin, amor odio con Rust... hay cosas de Rust que molan pero no es la panacea y no, no esta al nivel de versatilidad, flexibilidad y agilidad de C, ni de lejos. C es dios. Es mas que un lenguaje, es un jodido standard de la industria y, por cierto, lo es sin comites, core teams o pollas woke en vinagre. Todo el tema CoC, el Core Team y sus politicas y parte de la comunidad de Rust ( repito, parte, y es facil de imaginar a quienes si y a quienes no me refiero ) es BASURA que echa mucho para atras.
Nota: yo está como "sistemas" en las reuniones en las que daban caña al equipo de producto... No soy programador.
¿Lenguajes "artesanales" ?
donde el programador se encarga de gestionar la memoria a mano.
He programado en C durante años y jamás he "gestionado la memoria a mano". He cogido memoria cuando la he necesitado y la he liberado cuando ya no me hacía falta.
No es tan difícil.
Los problemas de seguridad se derivan de una mala programación. Y mientras haya esas malas praxis habrá problemas. Uses Javascript, PHP, Rust o lo que quieras.
Hoy en día los problemas de buffer-overflows que es lo más típico debido a la falta de control en el almacenamiento en memoria en C no son los peores problemas de seguridad ni de lejos.
Por favor, que alguien me explique esto. No entiendo como la vulnerabilidad de una librería de Java puede tener como consecuencia un llamamiento a dejar de utilizar C/C++ y ofrecer Java como una de las alternativas.
Lo que hace es prohibir/impedir (salvo que te emperres usando métodos unsafe) que se pueda hacer algo mal, para que no haga falta comprobar si se hace algo mal.
Así te ahorras el esfuerzo mental de programarlo sin vulnerabilidades y las comprobaciones en tiempo de ejecución.
Y te lo dice un programador de C a pelo con toda la gestión de memoria manual y que Rust lo ha tocado bien poco pero las ventajas saltan a la vista.
Por cierto, no me parece bien que te pongas a decir que los que hablan de las ventajas de Rust sobre C tengan una "obsesión". En ese caso, ¿tú tienes una obsesión con C/C++? Pero encima si lo estás haciendo sin saber nada de Rust ni documentarte sienta peor.
Pero sé que no hay mala intención en lo de obsesión, te lo digo solo para que lo sepas.
Saludos.
Habiendo lenguajes equivalentes, empezar un proyecto nuevo en C/C++ tiene poco sentido en la inmensa mayoría de casos. Y te lo dice un ex programador de C.
Ya se que confiar en este comentario sin más pruebas es una estupidez pero confío plenamente en su criterio.
Asi que lo mejor es usar C++ y de vez en cuando, cuando sea estrictamente necesario usar C o ensamblador: tienes std enterito con maps, list, deque, vector; tienes string para no tener que estar todo el rato con char* y snprint o strcpy y su puta madre de funciones para hacer un simple:
std::string str = "Hola";
std::string str2 = str;
str.append(", ¿que tal?);
En C esta cosa tan simple es insufrible...
ademas desde C++11 tienes std::thread para no tener que usar mil historias para hacer un thread, tienes std::shared_ptr, std::uique_ptr, para no tener que usar directamente "new" ni malloc ni "delete" ni free que puede dejar en un codigo o proyecto complejo memory leaks, porque escribas tantas lineas que se te pase un delete o un free cuando debe... Tienes std::function, tienes funciones lambda, tienes std:.pair, tienes Orientacion a Objetos y clases (aparte de los struct y union de C).
Y todo eso tambien es cross platform... no tiene ningun sentido usar solo C puro hoy en dia.
Otra cosa es la mala gestion de memoria, que viene del modelo de usar la memoria para tener datos y codigo, y el heap y la stack. De hecho, lo logico, que no ha hecho nadie hasta ahora, seria cambiar el paradigma de los compiladores y de la gestion de la memoria.
El propio creador de C++ decía algo parecido. Él sugiere el uso de analizadores de código estático. Supongo que habría que meterle a estos analizadores algo más. Por ejemplo, la notación:
github.com/selairi/memory_notation.h
Por cierto, si tenéis algún segment fault o memory leak, recomiendo leer:
github.com/selairi/memory_notation.h/blob/main/PROBLEMS.md
Para los memory leaks lo mejor es Valgrind:
cartaslinux.wordpress.com/2020/04/05/valgrind-buscando-errores-de-memo
"Para qué quieres hace eso jaja saludos"
De acuerdo con lo que dices, solo que secularizar si existe aunque no tiene mucho que vez con la seguridad informatica. Yo odio el "encriptar" cuando no se habla de criptas.
Se me ha ido la.olla y en vez de darte a responder te he dado negativo, te doy otro par de positivos luego
Aparte que desde c11 y posteriores la cosa ha ido mejorando.
te voy a instalar la máquina virtual de Java.
Ah, pues no cabe.
Oh, wait...
Si necesitas hacer algo crítico en lo que no te fies del GC, por supuesto que Rust es un candidato ideal.
Para montar una API decentilla, o crear un CLI, o cualquier cosa medianamente compleja que tampoco sea súper crítica, Go es una maravilla. Ya vale la pena solo por la cantidad de herramientas que te da la librería estándar sin tener que bajarte paquetes de otros.
C / C++ son leguajes potentísimos que mal usados te vuela el pie, una buena analogía puede ser un bazooka.
Es un lenguaje que de potente que es, te puedes llevar un buen disgusto. Sobre todo perfiles que no tengan un buen y largo bagaje de programación.
Y claro, el legacy de C++ es como el legacy estándar solo que con nuevos superpoderes: memory leaks, punteros inválidos ...
El ilustrador aquí no es un empleado básico.
www.youtube.com/watch?v=BKorP55Aqvg
Sólo apuntaba que ese razonamiento lleva a la conclusión de que no merece la pena invertir en herramientas más seguras, porque el problema son los malos conductores/programadores (que casualmente siempre son otros y no uno mismo).
Creer eso es lo estúpido
Tener un Linux en Rust no aportaría nada de nada
Muchos de esos problemas con C se han arreglado con las mitigaciones de OpenBSD, opciones de malloc, y pledge y unveil en Firefox y Chromium.
Del nivel de los que piden esa estupidez.
Encriptar es ocultar la información cifrándola mediante el uso de clave/s.
Si lo prefieres puedes usar el sinónimo cifrar, pero encriptar aparte de ampliamente utilizado esta admitido.
dle.rae.es/encriptar
En serio, no hay que hacer caso a burócratas de mierda que no tienen ni puta idea de nada, y menos de informática.
Yo si he programado extensamente en C y no es tan difícil. Solo hay que saber lo que se hace y ser un poco cuidadoso.
Y si no eres cuidadoso o no sabes exactamente lo que haces la cagarás también en C#, Java, PHP, Python o JavaScript.
Las páginas web no están hechas en C y sus historiales de vulnerabilidades es insuperable.
Piensan prohibir la programación web ?
Es que a los mayores de 40 no nos han prohibido todavia volver a la universidad.
Y ademas ahora existe Internet y puedes sacarte una carrera en universidades en otro continente.
En mi caso estoy intentando una segunda carrera en Ciencia de Datos y estoy pegandome con las asignaturas de matematicas porque hace mas 25 anios que me hice las de la carrera.
Soy mas bien calvo, que cuando empece usabamos el Turbo Pascal y el Turbo C, y OWL era un adelanto de la polla en vez de programar windows con la API en C a pelo,... y teniendo que cargar las entradas de las dll mirando los segmentos de memoria porque era win32 y en mi memoria de persono mayor me acuerdo de que habia un pollo bien montado con los puntos de entrada de las dll si tenias win32 en vez de 16 bits... pero hace mucho de eso.
Una cosa que no queda clara es si la estela que deja el sable de luz también repele. ¿Hay algún tipo de atracción entre el sable y los láseres?
Luego si hay alguien que usa pólvora pues se le tira el sable de luz haciendo el molinillo a la cara y ya está
#33 A mí me confundía la forma en que usaban los sables de luz en las nuevas películas. Sale el llorón cortando árboles de un tajo, pero luego a los buenos les roza un poquito haciéndoles una quemadura de primer grado, que parece sanarse en cuestión de segundos y se mueven con total normalidad. Cuando mata a Han Solo, lo empala atravesándole el vientre en una escena que ya de por sí no tiene ningún sentido. En el grupo de frikiamigos todos pensamos que lo coherente con lo mostrado hasta el momento es que el cuerpo se hubiera partido en dos, cayendo por su propio peso. Nadie se queda completamente quieto cuando siente algún dolor en la zona abdominal y a poco que se mueva con un sable láser dentro...
En las tres primeras el movimiento del sable al estilo kendo tiene más sentido porque la prioridad en cualquier estilo de combate es no hacerte daño a ti mismo. Precisamente el entrenamiento de Luke es en su mayor parte defensivo. En las demás películas, cuando están todo el rato haciendo el molinillo como una majorette resulta ridículo.