edición general
208 meneos
5751 clics
Breve historia de Rust, el lenguaje de programación que ha destronado a C

Breve historia de Rust, el lenguaje de programación que ha destronado a C

Durante décadas, los programadores han escrito sistemas críticos en C y C++. Ahora, recurren a Rust .Muchos proyectos de software surgen porque, en algún lugar, un programador tenía un problema personal que resolver. Eso, más o menos, le ocurrió a Graydon Hoare. En el año 2006, Hoare era un programador informático de 29 años que trabajaba para Mozilla, la empresa de navegadores de código abierto. Al volver a su apartamento de Vancouver, descubrió que el ascensor no funcionaba: su software se había bloqueado. Y no era la primera vez que le ocur

| etiquetas: historia de rust , lenguaje de programación , c , graydon hoare
«12
  1. #21 tu me estas hablando de un sistema operativo que usas tu ... yo te estoy hablando de los chips que regulan semáforos , lavadoras, coches , silos de agua , camiones , puentes , barcos , maquínas sencillas que llevan años , no creo que estés entiendo lo que digo ... estas pensando en un cojunto muy pequeño. Yo te hablo de todas las máquinas que tienen microcontroladores , no se de que otra forma decírtelo . Tu solo me hablas de BSD que se parchean en horas cuando aparecen bugs..

    Yo te hablo del chip que controla el motor de un barco que tiene 40 años , y está encapsulado dentro de un motor y el jefe del barco no tiene un dongle para actualizarlo...

    Te hablo del chip de un semáforo de un pueblo remoto , que lleva funcionando 20 años....

    Te hablo de todo eso , ....

    Insisto que internet hay varios experimentos cambiado la hora a varios sistemas operativos de 32 bits y cascan de lo lindo

    Te hablo de los problemas que ya hemos tenido, mira youtube.

    Te l,o he explicado de varias formas diferentes , no insito mas :-)

    www.youtube.com/watch?v=jrGWMaUOSvk


    Ese es el reloj , lo lógico es que todo estuviera actualizado para entonces, pero ya lo veremos..
    www.epochalypse.today/

    The signed 32-bit integer that is historically used to keep unix epoch time has already exhausted 89.07% of all possible values.

    0
    1100100
    00000010

    10000011

    10101100

    Only 5435 days (14 years) until it's finally 20:45:52 UTC on 13 December 1901 again!



    Only 5435 days (14 years) until it's finally 20:45:52 UTC on 13 December 1901 again!
  2. #29 Creo que eres tú el que no entiende lo que es un overflow de pila :-) Ni lo que hace Rust. Ya te he puesto un código trivial que te demuestra un programa en Rust que el compilador se traga sin problemas y que en ejecución casca con un stack overflow.

    Aquí lo dejo que no vamos a llegar a nada.
  3. #1 Cobol va a durar muchos años , pero es un lenguaje para un propósito diferente que C y C++ , preparo entornos de entrenamiento de Cobol para "estudiantes" , conozco la tecnología Mainframe y z/os , por desgracia por contrato de confidencialidad no puedo especificar mas. Cobol es un lenguaje vital , practicamente cualquier transacción económica implica COBOL . Es muy sencillo el 80% de las empresas del S&p 500 usan tecnología Mainframe y aunque en z/os tienes varios lenguajes , COBOL suele ser el mas usado . Cobol se sigue actualizando por ser vital para el funcionamiento del mundo . Así que viejo no eres .

    Rust viene por un motivo diferente "overflow" de ahí vino el nombre de la página tan famosa Stack Overflow , desbordamiento de pila... de esos desbordamientos se aprovechaban antiguamente los virus y actualmente es un vector de ataque para un porcentaje muy alto de software. Rust no te deja compilar si hay desbordamientos de ese tipo , aunque tengas bien escrito todo , etc...
  4. #25 ¡Hola!, que conversación tan interesante. He trabajado más de 20 años en programación de RTS y embebidos, os cuento mi visión por si a alguien le fuera de interés.

    Para la sincronización y creación de temporizadores se emplea el reloj monotónico, que se reinicia junto al dispositivo, sobre todo en microcontroladores como los que comentas que ni siquiera suelen disponer de reloj de tiempo real (RTC). Además, estos dispositivos suelen sincronizarse con el entorno mediante E/S vía sensores y no mediante reloj.

    La mayoría, por no decir la totalidad de los dispositivos que comentas no tienen ni siquiera conectividad a internet, donde es importante tener el RTC sincronizado exclusivamente por temas de cifrado de canal (SSL/TLS), que es donde interviene el reloj de tiempo real ya sea en HTTPS o túneles SSH. En TCP existe una cabecera timestamp que emplea el RTC, pero es opcional y la gran mayoría de sistemas hace caso omiso de esta, o la cumplimenta por dar compatibilidad pero no la revisa.

    A mi sinceramente se me ocurren pocos sistemas críticos que dependan de un RTC y no puedan ser actualizados. Si algún sistema de 32 bits está haciendo de servidor NAS, SQL o HTTP, o incluso empleado como switch de red, tiene pinta de que va a ser un embebido cutre doméstico de mediados de 2010, con lo que en 2035 deberían estar más que muertos.

    Desde 2020 cualquier linux tiene time_t de 64 bits, por lo tanto, el gran problema no parece que vaya a ser tan grande, más bien un problema de algunos gadgets a domésticos.
  5. #2 En Rust puedes tener desbordamientos de pila sin ningún problema.

    fn overflow() {
    overflow();
    }

    fn main() {
    overflow();
    }

    thread 'main' has overflowed its stack
    fatal runtime error: stack overflow
    Aborted (core dumped)
  6. #22 A ver: El error me sale al ejecutar el programa compilado con Rust.

    Es un coredump como cualquier otro. Y el error es diciendo que es un desbordamiento de pila me ha salido porque está compilado en modo debug, nada más.

    Los desbordamientos de pila son inevitables si hay recursividad, es imposible que el compilador pueda saber de antemano el nivel de profundidad de las llamadas.
  7. #23 tu me estas hablando de BSD y yo no te estoy hablando nada de BSD hablamos de cosas diferentes, es como si me pones de ejemplo mi windows .... obviamente yo tehablo de máquinas de 32 bits ... cualquier cosa que lleve un microcontrolador... incluso un coche con 15 años .... yo que sé como explicartelo ya !! disculpame , pero no hablamos de lo mismo.
  8. Que a qué? OpenBSD, OpenSSH, LibreSSL, NetBSD, FreeBSD, Linux, GNU C, GCC, Emacs...

    Todos en C. A C le queda cuerda para rato.

    De hecho Rust está bien para reemplazar a C++.

    Sobre overflows, las mitigaciones de OpenBSD junto con pledge y unveil machacan el 99% de ataques.
  9. #13 ojalá tuvieras razón. Solo te voy a poner un ejemplo , todas las raspberri pi con so de 32 bits... hay un experimento de alguien en internet qye le cambia la hora a una y casca por todas partes.

    Nadie sabe que sucederá , se espera que esté todo a 64 para entonces... pero....

    ¿Tienes tu la censados todos los sistemas de 32 bits del planeta?

    Chips, microcontroladores , .... quien sabe ...

    En internet hay un reloj de cuenta atras.
  10. #12 Pero si ese error es en ejecución...
  11. #4 exacto . Te añado algo ahora viene el efecto 32bits , en 14 años los contadores de 32 bits se reinician y habrá problemas muchos mas gordos que con el efecto 2000. Todo lo que sea de 32 bits y use un calendario se tuene que actualizar . En el canal derivando de youtube puedes ver varios problemas. Mis respetos a un programador de COBOL. Un abrazo gracias!!!
  12. #39 Los casos más triviales los detecta el compilador a tiempo:

    fn main() {
    let mut ar = [0; 1000];
    ar[1049] = 1;
    }

    Al compilar te dice

    error: this operation will panic at runtime
    --> src/main.rs:4:5
    |
    4 | ar[1049] = 1;
    | ^^^^^^^^ index out of bounds: the length is 1000 but the index is 1049

    Si el índice es dinámico:

    fn main() {
    let mut ar = [0; 1000];
    for i in 1..2000 {
    ar[i] = 1;
    }
    }
    ✦ ❯ RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
    Running `target/debug/overflow`
    thread 'main' panicked at 'index out of bounds: the len is 1000 but the index is 1000', src/main.rs:5:9
    stack backtrace:
    0: rust_begin_unwind
    at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:575:5
    1: core::panicking::panic_fmt
    at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:64:14
    2: core::panicking::panic_bounds_check
    at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:147:5
    3: overflow::main
    at ./src/main.rs:5:9
    4: core::ops::function::FnOnce::call_once
    at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ops/function.rs:507:5
    note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

    Las garantías estáticas de Rust no van de que tu programa nunca vaya a cascar - cualquiera puede hacer un programa que casque. Lo que no vas a poder hacer, al menos sin meter a propósito código que sea inseguro (y esté declarado como tal) es tener carreras (races) entre hilos, ni utilizar memoria una vez liberada, por ejemplo.
  13. #32 y así, con un simple comentario, te acabas de marcar como objetivo ante cualquiera de la comunidad que pueda tener interés en "datos especialmente sensibles"... en una página poco segura (no es la primera vez que las bases de datos de mnm caen) y aumentado tus posibilidades de que te hagan un doxxing guapo para ver quien eres, a que te dedicas y si puedes ser un vector de acceso a lo que quiera que haces/tocas :troll: :-D
  14. #29
    Rust no te deja compilar si hay desbordamientos

    #24 procede a demostrar que ha compilado un código que provoca desbordamiento



    No entiendes que es desbordamiento, los ingenieros tampoco lo comprenden, solo yo lo entiendoxD xD

    entre esto y el rollo espía de la KGB que traés con tu curro no se puede ser más patético jajajaj reconozco que me has alegrado la mañana ehhh
  15. Quedan al menos un par de décadas para que todo lo que hoy se hace en C++ se haga en Rust. Y no tengo claro que vaya a pasar.

    Rust está guapísimo, es un lenguaje cojonudo, pero el mundo entero está hecho en C y C++ y eso no se cambia de la noche a la mañana. Por otro lado, C++ está viviendo una segunda juventud: el lenguaje ha mejorado muchísimo con respecto a hace 15 años, no digamos ya 25. Sigue siendo el lenguaje premier para videojuegos, sistemas de IA, ML, etcétera.

    Igual que Python destronó a Java para muchísimas aplicaciones, Rust quizá termine destronando a C++ que es su objetivo real. Pero seguramente muchos estemos ya jubilados cuando eso suceda.

    (*) Y Python es más antiguo que Java
  16. #26 Dejale, su sistema operativo está parcheado xD xD
  17. #29 Rust evita el buffer over y underflow, no el stack overflow.
    El caso que expone el compañero es una función recursiva sin caso base, cosa que Rust no es capaz de identificar.
    Según las condiciones del sistema y problema puede producirse stack overflow incluso con la definición de un caso base, si como dice el compañero, la profundidad es grande ya que no se puede conocer de antemano. Por ejemplo en un gran grafo, o incluso en uno pequeño con un bucle (A-B-A-B...) si la función no ha sido pensada adecuadamente.
  18. #2 Gracias por echarme un cable frente a mi senecto-complejo. :-D Entiendo esa pervivencia claro, Cobol es como los chasis, llegan nuevos motores, nuevas direcciones, nuevas funcionalidades... y ahí siguen tan simples, robustos y funcionales. Fíjate si hará tiempo que lo último que hice fue un sinfín de adaptaciones (y nuevos programas y procedimientos de comandos) para el "efecto 2000". Ahora mi nieto me da sopas con honda. Un saludo y suerte en lo tuyo.
  19. #41 yo estoy flipando, llevo pensando lo mismo cada vez que leo un comentario suyo.

    Hago cosas muy importantes, muy sensibles, vuestra vida depende de mi, se más que todos vosotros juntos pero eh, no puedo decir nada, acuerdo de confidencialidad.

    O es un invento o es un inconsciente
  20. #30 No, no se lía. Pledge lo va a mandar a ATPC si intenta abrir una syscall. Pledge es implícito, no es explícito com Selinux en Linux. En OpenBSD si un programa compilado con pledge intenta acceder a una syscall el kernel le va a mandar un sigabrt bien guapo.

    Con unveil no vas a ver desde el VFS nada que no se te haya indicado. Ni patrás. No es que que el exploit no intente un open o fopen, es que literalmente el proceso y subproceso los ficheros no existen para el, el kernel no los expone.
  21. #11 python y java compilan en C y C++

    No es cierto. Tanto Python como Java suelen compilarse a bytecode. Java también se compila a código máquina en algunos entornos.

    El que sí compila a C es Cython, un superset de Python.
  22. #10 #12 Se comprueba en dos segundos, y Koji tiene razón.  media
  23. #2 bien pero… confundes Stack Overflow (el que da nombre a la página) con Buffer Overflow (el problema de seguridad habitual en C).
  24. #6 Te equivocas. Los sistemas de 32 bits usan un time_t de 64 desde hace eones. Más de 10 años mínimo. Al menos OpenBSD y creo que NetBSD desde una década como digo.
  25. #5 python y java compilan en C y C++.

    Ten en cuenta los niveles de los lenguajes.

    Maquina
    Ensamblador
    C , C++ , Rust ...etc
    Python , java etc
    Lenguajes de muy alto nivel , yo uso uno que no puedo nombrar por confidencialidad.



    Rust es un lenguaje de bajo nivel , entra en contacto con el hardware directamente.


    Hoy en dia sl usar c y c++ hay que usar programas auxiliares para verificsr el código.

    Por eso el tema es bastante gordo , pero se tardará décadas como tu dices.
  26. #3 con Rust no tienes que mitigar mucho , ni si quiera tiene recolector de basura. OpenBsd de base es cojonudo , el problema es cuando se instala programas compilados en C y C++.

    Ese 1% que dejas al aire es suficiente para que te ataquen y te roben todos los datos.

    Un sistema es tan fuerte como su parte mas debíl.
  27. #32 Pues no lo iría explicando por ahí. Creo que el propio comentario ya da pistas
  28. #16 El que no conoce las mitigaciones de OpenBSD eres tu. Se aplican a cada port, es una CFLAG y CXXFLAG. Y por supuesto las LDFLAGS inseguras para usar un JIT como por ejemplo WXNEEDED en emuladores como PPSSPP han de establecerse explícitamente, si no el emulador al abrir un juego te va a cascar maravillosamente al intentar un W^X o ir horrorosamente lento.
  29. Joder qué viejo soy, yo era de Cobol. {0x1f5ff}
  30. #27 no lo puedo decir , disculpame de verdad :-( , un saludo . Me dan miles de ganas de decir lo que hago , pero por seguridad no puedo ser preciso , lo siento. Los datos que movemos son muy sensibles .
  31. #89 no tengo ni idea, ni ganas de mirarlo ahora, pero básicamente todos los compiladores empiezan escribiéndose en otro lenguaje ya existente hasta que llegan a un punto de desarrollo en el que son capaces de compilarse a si mismos.
  32. #152 Ok. Gracias.
    Lo siento no tengo ni idea.
  33. #18 ¿pero tienes el error no? Pues eso....

    ¿Para ejecutar usas el compilador dd Rust no?

    Pregunto porque a lo mejor me pierdo algo.

    En mi trabajo diario si me da un error de ejecución no puedo seguir y tengo que arreglarlo...
  34. #16 Sobre CHrome, el Chromium de OpenBSD usa pledge y unveil por defecto, y no tiene WASM activado de serie. /etc/login.conf tiene limites de procesos y uso de memoria que o se aumentan o el software casca que da gusto.

    Por lo general, en el 99% de los casos, si encima usas UBo, Chromium ni se va a enterar. En el resto antes de que pase algo Chromium casca pero de pleno al intentar usar alguna syscall que no este visibilizada desde pledge. Con unveil impides que se accedan a cosas como ~/.ssh y no salga de ~/Downloads y ~/.local/share/chromium (y otras rutas del sistema) para operar.

    En Firefox para OpenBSD era mágico. En el cuadro de descargas y subidas de GTK+ no salía ni $HOME como ruta a entrar, no te dejaba. ~/Downloads como ruta absoluta y gracias. No, tampoco ibas a ".." . O directo a ~/Descargas, o no entrabas.
  35. #34 OpenBSD es una pasada lo sé , pero también lo es es sistema de seguridad de un banco , pero si te abre la puerta el dueño del banco hasta el dinero ... .no se si me explico , OpenBSD es tremendamente seguro con el mayor porcentaje que te puedas esperar , pasa igual con los Mainframe de IBM que z/os que es unix .

    Practicamente todo lo que es Unix es muy seguro , por suerte para todos nosotros , nuestros datos vitales descansan sobre BBDD que están en sistemas Unix. Imaginate que se descargan nuestros datos de la seguridad social , del banco o algo así directamente desde la BBDD , sería problema muy serio.

    Por eso no se debe instalar cualquier mierda de programa , mira lo que les ha pasado a los de Lastpass , a un ingeniero de DEVOps le atacaron un programa de reproducion multimedia ... y a través de eso entraron en su nuve de amazón.... es decir les abrió la puerta hasta la cocina...
  36. #62 genial ejemplo, me lo guardo para futuras ocasiones
  37. #88 En el caso general, no.

    es.m.wikipedia.org/wiki/Problema_de_la_parada

    En concreto, este párrafo:

    _Lo que se afirma es que no existe una manera automática computable de saber si todos los programas posibles terminan. No se niega que exista la prueba para programas concretos. De hecho, la construcción de pruebas para programas concretos es un paso obligatorio para demostrar su correctitud._

    Con lo que, o limitas los programas que se pueden escribir (en el caso de Rust mediante reglas sobre qué código es el propietario de qué regiones de memoria, y qué referencias pueden existir a esa memoria en un momento dado), o, post-facto, sólo podrás eliminar un porcentaje (mayor o menor) de los problemas.
  38. #2 sencillo?
    Perdona, se que las comparaciones son odiosas - pero el Cobol es como jugar al Mario Bros en su conceptualización
    www.archdaily.com.br/br/782588/papel-quadriculado-a-origem-de-super-ma
  39. #88 hay herramientas de análisis estático (a partir el código fuente) y dinámico (usan el programa compilado). Son muy útiles y se podrían utilizar mucho más, la verdad.
  40. #20 Cuando trabajé para Banca Catalana era todo en PL1, más algo de assembler. El PL/1 es muy superior al COBOL. Puedes traducir un programa de COBOL línea a línea a PL/1, pero PL/1 puede hacer mucho mas. Por ejemplo les escribí un analizador sintáctico de PL/1 usando apuntadores a memoria para construir el árbol.

    ¿Deutsche? Crecieron mucho en sistemas medios, usando Java, C, y hasta COBOL, que sólo atacan al mainframe (Frankfurt) a base de CICS. El batch sigue siendo el de siempre, que lo van manteniendo a base de sustos y lloros.

    Cuando aparecí por Deutsche había mucha gente que me conocía, algunos de Catalana, pero también otros de haber pasado por Caixa, y aún a algunos les sonaba de verme en la máquina de cerveza en el edificio de Sant Cugat. Este es un mundo pequeño.
  41. #105 No me refería a eso, me refería a que la recursividad dependa de alguna variable cuyo valor el compilador no pueda determinar que es lo normal, vamos.
  42. #49 Ver un mensaje de stack overflow es una advertencia del compilador

    ¿Qué? No.
  43. #76 ya está demostrado, no tengo nada más que añadir
  44. #4 Los coches de ahora y desde hace decadas, no llevan un chasis en si, sino que son monocasco. Lo mas parecido la chasis seria la plataforma, sobre la que se montan el techo, puertas, laterales.
    Todoterrennos verdaderos eran los ultimos que llevaban chasis y carroceria separada, pero hasta el defender se ha pasado al monocasco.

    #6 Creo que los F-35 tuvieron un problema de cambio de hora al sobrevolar la zona del pacifico donde se pasa de un dia a otro. Yo pienso que seria facil evitar esto usando UTC, para las cosas que necesitan una hora consistente y luego la represetancion la adaptas a la zona horaria.

    #13 Yo entiendo que el problema es la implementacion en sofware y que el SO sea de 32bit deberia ser poco relevante. Es un problema previsible y añadir otro byte, no cuesta nada.
    El hardware creaba el problema de que la bios no sabia representar al 2k. Pero por sofware, se puede suplir sabiendo que el punto de partida ya no es 1980, por ejemplo.
    HAbia programas que lo hacian en el arranque, cuando no habia internet permanente ni NTP estaba extendido.

    #25 OK, entiendo que aunque el problema puede ser facil de solucionar, hay muchos sistema que pueden haberse olvidado de un problema que dará la cara dentro de decadas.
  45. #7 #20 #109 Conoceis a mackuskey? es tambien un abuelo informatico que cuenta historias de informatica del año catapum.
    eltamiz.com/elcedazo/author/macluskey/
    Creo que tiene un libro de Historia de un Viejo informatico.
    eltamiz.com/elcedazo/2009/03/31/historia-de-un-viejo-informatico-la-ir

    #68 #66 Eso entiendo yo que las gestion de memoria en C no tiene "topes" y si te sales, puede acabar en otra zona de memoria y si puede elegir donde, meterte en otras zonas y hacer cosas no previstas.
    En pascal, creo que el BIt 0 tiene la longitud del array y en Rust, no se como evitar salirte de la memoria asignada.

    #45 No responte tu pregunta. Pero Qmail tiene un diseño en dos partes. Una pequeña y sencilla y facil de vigilar conectada a internet y el resto de programa que se conecta a internet a traves de la anterior y solo le va a dejar acciones concretas. Ofrecen recompensa a quien encuentre un bug que les de acceso.
    en.wikipedia.org/wiki/Qmail
    Por otra parte yo seria partidario de limitar los permisos al minimo a los programas, no solo a todo el usuario.
    Un word, necesita aceso a ficheros temporales y un sitema de guardar los archivos que se puede delegar en otro programa asegurado.
    Un firefox parecido y se podria limitar lo que puede tocar en el disco duro y las acciones que pueda hacer por internet.
  46. #149 Pero a que cuela?
    Seria interesante una recopilacion de mentiras de ChatGPT.

    #102 En trading de alta velocidad la latencia es muy importante, contrataron a un desarrollador del nucleo de linux.
    Puede que Rush podria tener alguna utilidad.
    Hay aplicaciones forenses para el Rush, como una aplicacion que gana por ejemplo a Python.
    yewtu.be/watch?v=hhRM-D5xn60

    #107 A que te refieres?
    Rust se compila a un pseudo-ASM/esperanto LLVM y de ahi se compila al ASM/codigo maquina de cada arquitectura( x86, arm, microcontroladorres, etc) .



    Parece que Rust es un lenguaje para nenanzas, lo que puede generar una cooperacion positiva. Tal vez se estudia poco la sociologia del desarrollo de sofware.

    Mientras tanto, la comunidad de Rust también fue construyendo una cultura conocida por ser amistosa y abierta a los recién llegados. "Nadie te llama nunca novato. Ninguna pregunta se considera estúpida", dice Nell Shamrell-Harrington, ingeniera principal de Microsoft que, por aquel entonces trabajaba en Rust en Mozilla.

    Shamrell-Harrington explica que esto, en parte, se debe a que Hoare publicó muy pronto un "código de conducta", que prohibía el acoso, y se esperaba que cumpliera cualquiera que contribuyera a Rust. La comunidad lo aceptó y, según los miembros más veteranos de la comunidad Rust, por ello los programadores queer y trans se involucraron en Rust en mayor proporción que en otros lenguajes. Incluso los mensajes de error que crea el compilador cuando el programador erra son cuidadosos: describen el error, y sugieren amablemente cómo solucionarlo.

    "Cuando cometo errores, los compiladores de C y C++ me hacen sentir como una persona terrible. El compilador de Rust es como si te guiara para escribir un código muy seguro", admite Shamrell-Harrington riendo.
  47. #150 A que te refieres?

    Cuando trabajas con alguna placa de evaluación o un SoC de algún fabricante, este te ofrece un SDK (compilador, librerías para ese HW, etc...), y en entornos empresariales no se suele usar gcc/clang para producto final. ¿Existe algún SDK de algún fabricante que ofrezca Rust? A eso me refiero.
  48. #10 esa es la historia , el compilador no te deja seguir , fatal error...
  49. #14 pues estas muy equivocado , te lo dice alguien aficionado al pentesting. Pregutales a los de lastpass . Por tu afirmación no debes saber nada de programacion. El 60% de los ataques a chrome es por overflow.... busca em google o estudia pentesting... a diario se rompen programas , claves , etc...hay demasiados agujeros...
  50. #17 mitigaciones , tu lo dices . Tambien has dicho 99% ... es decir que un 1% queda expuesto , tu lo que lo conoces lo has dicho muy bien .
    Ese 1% es suficiente para que se lie bien gorda.

    Tampoco Rust lo va a solucionar todo , eso esta claro .
  51. #31 Google lo sabe , busca en meneame y verás que han ordenado usar Rust... . Microsoft lo mismo ha ordenado usar rust , Github esta usando rust en su motor de búsqueda experimental .. Creo que también usan Go pero desconozco ese lenguaje .. ni idea como va. ...
  52. #15 Te estaba buscando un artículo de un programador de C y creo que dice lo contrario , pero como guardo tantos links favoritos , necesito un buscador para buscar entre mis links favoritos jejejejej

    Luego si lo encuentro te lo paso .

    Rompo un lanza en tu favor diciendo que yo pensaba igual que tu.
  53. #9 Todos los programas están compilados con opciones de seguridad y que hacen que sea bastante chungo por no decir imposible operar exploits. Todos.
  54. #19 OpenBSD undeadly.org/cgi?action=article&sid=20130813072244

    Si hablamos de parches no oficiales para el y2k38 s los hay hasta para BSD 4.3 bajo SIMH en una VAX ;)

    Como ejercicio es cojonudo, y el código en C no es precisamente difícil de retocar.
  55. #24 Entonces no entiendes como funciona el overflow :-)

    No estás entendido como hace Rust para evitar el overflow y no entiendes bien el overflow .

    Haz pentesting y lo verás con tus ojos.

    Me paso el día explicandoselo a compañeros , ingenieros , y no lo entienden.

    Para entenderlo te recomiendo que veas un poquito de ensamblador y lo entenderás mejor.

    Y la esctructura de un PE , portable ejecutable y como son los registros de una CPU . Te recomiendo empezar con un chip pequeño del tipo ESP32.
  56. #60 Nada de eso tiene que ver con que Java y Python compilen a C.

    Tanto el intérprete de python como la máquina virtual de Java están hechos en C++.

    La implementación oficial de Python, CPython, está escrita en C, no en C++, pero también existen implementaciones en otros lenguajes, como PyPy (escrita en RPython, un subset de Python). Por otra parte, existen compiladores y máquinas virtuales de Java escritos en diferentes lenguajes: C, C++, Java, Smalltalk...

    Otra cosa es que ambos sean JIT que convierten Java/Python a código máquina sobre la marcha.

    Nope. Lo que se convierte a código máquina sobre la marcha es el bytecode, no el código fuente. Y CPython no incluye JIT, otras implementaciones como PyPy o Jython sí.
  57. #2 COBOL is a domain specific language {0x1f609}
  58. #31 Una pregunta desde el desconocimiento vuestro:
    Si usas OpenBSD y chromium y a este último le hacen un overflow, ¿no podrían acceder a los datos guardados en el propio chromium sin acceder al sistema?

    ¿Con esto te podrían robar cookies de sesión, o contraseñas guardadas (si no tienes habilitado algo que proteja esas contraseñas con otra contraseña) o incluso manipular tu navegador para que haga alguna acción desde tu navegador (crear una cuenta en alguna interfaz web, usar tu sesión para robar datos, por ejemplo del repositorio)?


    Como os veo metidos en esto de la seguridad, a ver si me podéis ayudar con una duda estúpida:

    El otro día hablaba con un amigo sobre si cifrar el .env de un proyecto de django y yo argumenté que si alguien te entra por la propia instancia de django, será capaz de leer la clave de descifrado almacenada en un archivo del propio proyecto (manage.py), con lo que el único motivo para cifrar eso es que alguien pueda desde tu sistema operativo leer ese archivo, pero de nuevo, si pueden leer ese archivo podrán leer manage.py y decifrar el .env.

    Solo te sirve para poder subir el .env a un repositorio público, y para que sea eficaz tienes que poner el manage.py en el git ignore para que no suba la clave de decifrado. Con lo cual seria mejor poner el .env en el git ignore y dejar el manage.py ya que contiene una información más útil para el proyecto (como qué fuentes de datos usas, que pueden ser varias) y sin exponer ningún dato crítico (ip, puerto, usuario y contraseña).

    Vamos, que no sirve de nada cifrar un archivo cuando quien pueda leer el archivo también va a poder leer el que lo decifra.

    Perdonad el offtopic pero me he puesto a pensar, OpenBSD puede ser todo lo robusto que quiera, pero al final, solo hace falta permisos de ejecución de la propia aplicación para hackear los datos de esa aplicación, los permisos del sistema sería más para tema de ramsonware o virus.

    Es que no entiendo como funciona el overflow, pensaba que era básicamente "colgar" un software para "prácticamente" permitirte lanzar código "no autorizado" en un sistema, aunque sean con permisos del mismo software.
  59. #2 mr programmer, los signos de puntuación solo llevan espacio despues, no antes. Te lo digo buenrrollerísimamente, que tu redacción es bastante impecable y sin duda tienes que corregir eso.
  60. #145 En pascal, creo que el BIt 0 tiene la longitud del array

    Los dos primeros bytes
  61. #25 Que lo entiendo de sobra. El firmware de muchas maquinas usa variantes de QNX y empotrados similares. Lo sé.
  62. Rust is C with a straight jacket.
  63. #9 OpenBsd de base es cojonudo , el problema es cuando se instala programas compilados en C y C++.

    Jamás adivinarías en qué está desarrollado BSD... xD xD xD
  64. #1 Aqui otro, que estuvo trabajando en AS-400 por el tema del efecto 2000.
  65. #126 Sí, mejor que en la tuya. Como va GNU LSH? Se come algo en conexiones cifradas vs OpenSSH? Qué tal OpenSSL vs LibreSSL? Aguanta dos días sin ser la risión?

    Si no llega a ser por los BSD a ver qué tendríais de pila de red, de conexiones seguras, de ciertas implementaciones de seguridad pioneras en OpenBSD y muchas cosas más.

    Sobre GNU GCC vs Clang, no he visto cosa que devore más RAM y CPU salvo Chrome. Compilar algo en equipos modestos usando GCC es imposible. Luego normal, han probado compilaciones cruzadas pero no nativas y todo casca que da gusto.

    No hay más que ver los bugs gordos que estoy viendo en algunos equipos con GNU/Linux X86 (y sin GNU) vs su contraparte en OpenBSD donde todo funciona sin tener segfaullts porque a esos desarrolladores Rockstar se la sudan los equipos usándo código de 32 bit totalmente funcional. Y hablo de algunos Celeron aún usados, y muchos Atom de 32 bits, no algo verdaderamente básico como un Pentium 4 con SSE2.
  66. #104 La pregunta y respuesta que he hecho en chatgpt:
    P: ¿en qué lenguaje de programación se comenzó a desarrollar Rust?
    R: El lenguaje de programación Rust fue inicialmente desarrollado en el lenguaje de programación C++, aunque luego se reescribió en Rust a medida que el lenguaje se fue desarrollando. Rust se inició como un proyecto interno de Mozilla Research en 2006 y fue presentado públicamente en 2010. Desde entonces, Rust ha sido desarrollado de forma abierta y colaborativa por una comunidad global de desarrolladores.
  67. #4 Cobol fue creado con la idea de que los oficinistas fueran capaces de escribir código, de ahí las instrucciones que parecen frases.

    Ahora Microsoft vuelve a las andadas con Power FX, que será programar usando las fórmulas de Excel.
  68. Se le estropea el ascensor y crea un nuevo lenguaje tela... Lo barato q sería haber arreglado el ascensor
  69. #1 Viejo no, desactualizado, yo desde que uso Rust ganó más dinero haciendo mucho menos.

    Pasate a Rust, cada vez somos más.
  70. #88 Ya se hace. El problema es que hay errores de programación que son indetectables hasta que se da la circunstancia exacta en la ejecución.
  71. #3 Linux ya acepta Rust en nuevos desarrollos del kernel. No van a migrar lo que ya hay, obviamente, pero Linus ya dio el visto bueno a Rust y se están añadiendo cosillas.
  72. #60 Eso no tiene nada que ver. El propio SO está hecho en C, y ahí compilas programas Rust.

    Es posible que se pueda "compilar" a C Java, Python, Rust o lo que te dé la gana..... Si tienes un "compilador" que lo haga.

    Java en Linux por ejemplo tiene un compilador a código máquina nativo (no a C)
  73. #74 Le da vergüenza decir que usa Visual Basic.
  74. #19 Repito, se usa un time_t de 64 desde hace bastante, al menos en los BSD. No hablo de 5 ni 10 años, ya en el 2007 creo que tuve OpenBSD y el límite estaba más que adaptado.
    Ahora bien, si tienes una Debian Lenny o Squeeze de la época, pues allá tu.
  75. #5 Ya está pasando ;) Dentro de Microsoft, uno de los principales valedores de C++, hay muchos proyectos en curso de migración a Rust. Sobre todo en las áreas de Azure y Windows 11.

    Hay que tener en cuenta el 70% de los parches de seguridad de Windows provienen de errores de memoria que se habrían evitado con Rust.

    Y, en el otro extremo, el de los haters de C++, también hay movimientos importantes. Rust se va a convertir en el segundo lenguaje oficial para el kernel de Linux. Hasta ahora sólo C tenía ese privilegio.
  76. #41 Suena a la típica vecina: "me han contado una cosa mu mala de la Puri la del 5° A, pero no me preguntes que no te lo puedo contar"
  77. #10 me interesa, cuando en C hay un arreglo de 1000 posiciones por ejemplo y asignó en la posición 1050, puede que haya un error o puede que no y se caiga más adelante. En Java, el programa se detiene y me muestra en que línea hubo la mala asignación. ¿Rust es como Java?
  78. #45 No tiene sentido cifrar el .env por los problemas que expones. Y tampoco subirlo al repo salvo que tenga valores de ejemplo.

    La buena práctica es cargar la configuración a partir de variables de entorno. Los archivos no les gustan mucho a los sysadmins.

    Aquí hablan, entre otras cosas, sobre cómo configurar un server.

    12factor.net/
  79. #38 Porque es un código trivial, supongo que a la que metes una variable ya se lo traga.
  80. #73 No le des muchas vueltas. Mi comentario sobre Prolog solo es un reflejo de un trauma laboral personal durante décadas.
  81. #63 Creo que ese mensaje era para #59 Y estoy de acuerdo

    Es un código muy simple y por eso sale el warning.
  82. #3 C es incluso peor que C++ en este aspecto
  83. #7 Yo igual, trabajé hace años para el de Deutsche Bank y también se usaba mucho PL/1 y COBOL, aunque no sé como estarán de actualizados hoy en día.
  84. #33 De lo que entiendo el resultado de un error de stack o overflow es un crash real de la máquina que acaba sin memoria donde escribir.

    Ver un mensaje de stack overflow es una advertencia del compilador o del entorno de ejecución que no deja seguir el stack overflow.

    En ese sentido se para el stack overflow, que sino resultaría en un crash irrecuperable, y no una ventanita que para el programa y te dice porque. Rust y C se pueden ejecutar en un OS que no tenga protección contra el stack overflow.


    En Rust te ha salido una advertencia por lo menos :

    warning: function cannot return without recursing
    --> src/main.rs:1:1
    |
    1 | fn overflow() {
    | ^^^^^^^^^^^^^ cannot return without recursing
    2 | overflow();
    | ---------- recursive call site
    |
    = help: a `loop` may express intention better if this is on purpose
    = note: `#[warn(unconditional_recursion)]` on by default

    warning: `playground` (bin "playground") generated 1 warning


    play.rust-lang.org/?version=stable&mode=debug&edition=2018&
  85. #22 Eso también da error en C.

    No es ese el problema de la vulnerabilidad de desbordamiento de buffer.

    Ahí lo único que ocurre es que llenas la pila. La vulnerabilidad consiste en desbordarla para sobreescribir datos guardados aprovechando variables creadas en la pila
  86. #29 Joder, no es tan complicado. Creas una variable local char[10] y escribes en ella 74 bytes....

    Tachán!!
  87. #49 Eso lo hacen TODOS los lenguajes, no solo rust.
  88. #27 Prolog está enfocado a su uso en inteligencia artificial.
  89. #11 Joder debes trabajar en la CIA para no poder decir el lenguaje de muy alto nivel que usais en el curro... o_o :shit:
  90. #84 Eso es lo que acabo de decir.
  91. ¿Alguien sabe de algún fabricante de HW que ofrezca soporte Rust en sus productos?
  92. #2 En el año 9900 los programadores de cobol estarán angustiados porque se acerca el año 10000 y habrá trillones de líneas por revisar.
  93. #112 Tu no eres consciente de la cantidad de líneas de código que se escribirán de aquí al 9900, 100 años estarán justitos, una pesadilla va a ser.
«12
comentarios cerrados

menéame