Portada
mis comunidades
otras secciones
![GitHub sufre un ataque automatizado de millones de repositorios clonados llenos de código malicioso [ENG]](https://cdn.mnmstatic.net/cache/3b/b9/media_thumb_2x-link-3914118.webp?1709367666)
#41:
#34 estamos en el punto que una librería de nodejs es un cuello de botella para software que está en producción.
Por comodidad de los desarrolladores que lo ven todo desde su mundo de Yupi, tenemos aplicaciones que se podrán escribir en 100 líneas sin , escritas en 20 pero con cientos de dependencias.
Porque? Porque solo miramos lo que tenemos inmediatamente delante de la nariz, y exclamamos -oh cielos, que código más elegante!- sin que importe lo más mínimo toda la basura que pueda haber detrás.
Gracias al gilipollismo corporativo, tenemos esto y toda una industria de expertos en seguridad que se dedican a despegar herramientas -refritos de nesus, y otros proyectos - con un panel de control con colorines y porcentajes, que te dicen que el problema esta en la versión de nginx.
En la industria del software hay una burbuja de tal magnitud con mil capas de abstracción, dependencias de nodejs, dependencia de servicios de nube, todos los datos en aws o azure (ya veréis que risas dentro de unos años), que cuando alguno de estos gordos reviente, la onda expansiva se llevará varias otras cosas gordas por delante.
Lo mismo que pasa ahora con los bancos, pronto pasará con el cloud, github, los repos públicos de docker, etc.
Todo tiene un precio, pero en general,contra más fácil es algo al principio, más alto es el precio a pagar por esa comodidad.
Por comodidad de los desarrolladores que lo ven todo desde su mundo de Yupi, tenemos aplicaciones que se podrán escribir en 100 líneas sin , escritas en 20 pero con cientos de dependencias.
Porque? Porque solo miramos lo que tenemos inmediatamente delante de la nariz, y exclamamos -oh cielos, que código más elegante!- sin que importe lo más mínimo toda la basura que pueda haber detrás.
Gracias al gilipollismo corporativo, tenemos esto y toda una industria de expertos en seguridad que se dedican a despegar herramientas -refritos de nesus, y otros proyectos - con un panel de control con colorines y porcentajes, que te dicen que el problema esta en la versión de nginx.
En la industria del software hay una burbuja de tal magnitud con mil capas de abstracción, dependencias de nodejs, dependencia de servicios de nube, todos los datos en aws o azure (ya veréis que risas dentro de unos años), que cuando alguno de estos gordos reviente, la onda expansiva se llevará varias otras cosas gordas por delante.
Lo mismo que pasa ahora con los bancos, pronto pasará con el cloud, github, los repos públicos de docker, etc.
Todo tiene un precio, pero en general,contra más fácil es algo al principio, más alto es el precio a pagar por esa comodidad.
#2:
Y esto es por lo que no podemos tener cosas bonitas...
#17:
#6 Siempre relevante: https://xkcd.com/2347/
#29:
Y espérate a que Copilot empiece a reproducir los trozos de código malicioso haciendo de asistente...
#22:
coño. Hoy mismo he visto uno que he reportado. Por lo general son pequeños repos que simplemente tienen un readme, con una url apuntando a que te bajes un exe. Intentan impersonar proyectos reales
#6:
La gran estrategia de usar todos el mismo servicio.
Me fascina como en esta industria en la que se supone que tenemos grandes mentes pensantes hay tanta dejadez.
Me fascina como en esta industria en la que se supone que tenemos grandes mentes pensantes hay tanta dejadez.
#7:
A mi plin, que yo uso Piko... Linux
Comentarios
Y esto es por lo que no podemos tener cosas bonitas...
El artículo original https://arstechnica.com/security/2024/02/github-besieged-by-millions-of-malicious-repositories-in-ongoing-attack/
#34 estamos en el punto que una librería de nodejs es un cuello de botella para software que está en producción.
Por comodidad de los desarrolladores que lo ven todo desde su mundo de Yupi, tenemos aplicaciones que se podrán escribir en 100 líneas sin , escritas en 20 pero con cientos de dependencias.
Porque? Porque solo miramos lo que tenemos inmediatamente delante de la nariz, y exclamamos -oh cielos, que código más elegante!- sin que importe lo más mínimo toda la basura que pueda haber detrás.
Gracias al gilipollismo corporativo, tenemos esto y toda una industria de expertos en seguridad que se dedican a despegar herramientas -refritos de nesus, y otros proyectos - con un panel de control con colorines y porcentajes, que te dicen que el problema esta en la versión de nginx.
En la industria del software hay una burbuja de tal magnitud con mil capas de abstracción, dependencias de nodejs, dependencia de servicios de nube, todos los datos en aws o azure (ya veréis que risas dentro de unos años), que cuando alguno de estos gordos reviente, la onda expansiva se llevará varias otras cosas gordas por delante.
Lo mismo que pasa ahora con los bancos, pronto pasará con el cloud, github, los repos públicos de docker, etc.
Todo tiene un precio, pero en general,contra más fácil es algo al principio, más alto es el precio a pagar por esa comodidad.
#41 A ver... Cuantos desarrolladores más y como de buenos necesitas para hacer esas 100 líneas sin librerias externas en vez de 20 con ellas? Cómo es la calidad del producto resultante? Qué coste tiene? Y el soporte? Me parece que el que vive en los mundos de Yupi eres tú. O bueno empieza tu en este plan y lo petaras si es que tienes razón.
#45 Muy bien, cuando ChatGPT llene de mierda los repos de proyectos robando licencias, cagándose por litigios y con vulnerabilidades por doquier, mas de uno bloqueara a todo devops que no sobreviva una semana con busybox, awk, links, libressl, ssh y tmux.
#41 Tiene toda la razon.
#51 Y qué impide usar chatgpt para defender los repos? La magia funciona para todos o es solamente para los agoreros?
#63 Magia, dice.
El problema será Copilot y marmolillos preguntando a ChatGPT sin saber que hace el codigo de un programa, libreria o script.
#64 Cuanto más potente es una tecnología mayores errores se pueden cometer, pero aun así prefiero una excavadora a una pala.
#65 Eso no es una excavadora a la hora de programar, es el equivalente al coche-desastre de Homer haciendo caso a los usuarios.
#66 Lo que tu digas. A mi me funciona.
Por cierto no se que tiene que ver chatgpt con copilot y con ataques que hacen forks de repos. Que todo lleva ai?
#67 1) que la gente que usa AI se va a volver aun mas vaga, no va a leer ni documentacion online
2) Preparate para futuras demandas como parte de tu codigo pertenezca a codigo BSD sin mencionar el origen o GPL/LGPL sin respetar licencias.
#68 No te preocupes, tu no haces esas cosas asi que estas a salvo. Los imprudentes que jugamos al aprendiz de brujo lo pagaremos caro. Coge palomitas y relájate.
#69 Pagar caro no se, pero que va a haber desastres por churros peores que mezclar VBA+VB6+OLE+ActiveX, eso tenlo claro.
#65 El problema es que uses unas excavadora para plantar un pino
#63 ChatGPT no puede defender nada
#51 Lo de ChatGPT puede llegar a ser una tragedia bíblica
#75 Ya hay tios de la gen-z con poca de idea de informatica aplicando comandos de un sistema en otro sin tener npi.
#45 Uno
#45 el problema es la velocidad a todo coste.
Puedes desplegar un clúster de kuberntes en aws EKS, meter una aplicación llena de dependencias.
Eso será muy efectivo los primeros a o 4 meses. Entonces el chavo al que le otorgan la explotación del servicio depende de as para casi el 100% de la infraestructura y tienes millones de dependencias con las que lidiar cuando haya actualizaciones. Y las hay constantemente.
Es MUCHO mejor a largo plazo, y más rentable, trabajar en una base solida que puedas mover independientemente de AWS o azure o GPC, y una aplicación con mínimas dependencias y bien documentada.
Es más trabajo? Por supuesto. Pero te aseguras poder tener soporte fuera de lo que hagan los terceros.
Todo depende de qué tipo de aplicación sea claro.
Pero en unos años vamos a ver una explosión de proyectos que se han quedado en nada gracias a la pereza.
Todo se destila en esto:
https://en.wikipedia.org/wiki/Move_fast_and_break_things?wprov=sfla1
Aquí empezó todo, con el capullo de Zuckerberg adorado como un dios.
#80 No lo veo. Todas estas cosas pasan desde hace más de 10 años y no veo que haya perjudicado a la facilidad de hacer cosas, al contrario. Tampoco conozco proyectos fracasados por esas razones y como digo tiempo ha habido. Pero bueno todos tenemos nuestras manías. Si a ti te parece mejor implementar todo desde 0 pues disfrútalo.
#80 En este aspecto yo he usado siempre una filosofía similar, y me ha ido muy bien. Me acusan de antiguo y de reinventar la rueda, pero mis únicas dependencias son para temas como pasarelas de bancos o servicios de terceros que se requieren. El core funciona en una tostadora de hace 30 años, y se conecta con cualquier cosa actual sin problemas.
Muchos me acusaron de que haciendo las cosas yo eran más inseguras. Aún no he sufrido nada por ello, y no es porque los sistemas los usen cuatro gatos. Simplemente me cansé de mandar correcciones a sistemas que se suponían "más seguros" y me di cuenta de que salvo algún genio aislado, los escribía gente con la misma idea o menos que la que tenía yo, y el 90% eran mucho menos paranoicos o cuidadosos con cosas elementales, no hablemos ya de cosas realmente chungas y profesionales.
Cada vez me cuesta más nadar contra corriente, y es una inercia imparable que me hace aborrecer muchos aspectos de mi profesión. Para mis proyectos sigo usando mis frameworks, pero en el trabajo cada vez tengo que usar cosas más deplorables y "actuales".
A veces creo que igual no es tan mala idea que la IA nos quite el trabajo, viendo lo que hacen los humanos con la tecnología últimamente.
Edito: cc/ #81
#87 No se, yo muchas veces he tenido que mirar dentro del código de dependencias para entender qué hacían exactamente y nunca he pensado "qué cosa más mal hecha", más bien al contrario y he aprendido de ellas. Si fuera asi pues esa dependencia en concreto no la usaria.
Creo que es fácil caer en la tentación de pensar que lo que no entendemos está mal y que nosotros lo hacemos mejor pero hay mucha gente muy muy buena por ahi y de hecho creo que la mayoría de librerías conocidas estan mantenidas por gente muy capaz.
#88 No es estrictamente que estén mal hechas, pero sí que no están hechas por genios diferentes al común de los mortales. Y a veces sí que hay carencias.
Se supone que cuanto más se usa esa librería más se revisará el código para estar al día de actualizaciones y problemas nuevos que surgen, pero la realidad es que gran parte del código es normal, y no estará más desactualizado de lo que pueda estar el código de cualquiera.
Todo esto unido a que cualquier dependencia te obliga a estar atento a posibles cambios, me genera la sensación de que prefiero añadir yo lo que sea necesario a mis librerías principales, y mantener las dependencias solamente allí donde realmente se necesitan, o donde esa actualización constante y revisión por pares pueda ser más beneficiosa.
Suma finalmente que la mayoría de los ataques son dirigidos a vulnerabilidades conocidas de librerías conocidas, y en mi caso la gran mayoría no hacen "match" por ninguna parte, con lo cual son vulnerabilidades que no van a explotar en mi código, incluso aunque por defecto fuera más inseguro ante un ataque dirigido ( que tampoco tiene por qué serlo, más vulnerable, quiero decir ).
#89 A mi me dice esto en una entrevista un candidato que tenga más de uno o dos años de experiencia y no la pasa.
#90 Yo he hecho entrevistas a docenas de candidatos en empresas distintas, algunas de las cuales se han hecho famosas, y las comencé yo desde cero. No puedo explicar cuáles no sólo por mi propia privacidad, sino porque me lo impiden varios NDAs.
Creo que tengo una experiencia bastante dilatada y variada, y sé por qué dices lo que dices, no eres el primero ni serás el último, pero creo que ganarías más pensando un poco sobre lo que exponemos varios de los compañeros, en lugar de ser tan taxativo.
Ahora, por curiosidad, me gustaría saber qué es lo que te parece tan descabellado de mi argumentación como para no pasar tu entrevista.
Si es la parte en la que considero el código de la mayoría de librerías como "normalito", te diré que he enviado correcciones a bastantes proyectos desde hace más de veinte años, y las correcciones no hacía falta ser un genio para verlas. Algunos proyectos eran más nuevos, pero otros llevaban décadas y eran usados masivamente. Y eso no impidió que arrastraran errores que no deberían haber estado ahí. Errores que en mis frameworks no estaban - y no soy ningún genio, créeme - y en esos proyectos de software libre duraron bastante tiempo.
Si es otro el argumento para desechar mi candidatura, me gustaría que me lo explicaras.
#41 se me ocurren tres escenarios poco deseables:
1. Una vez que casi todo esté en "la nube". Aws, azure y demás nos subirán los precios (Pero no lo suficiente para que salga la cuenta migrar a soluciones self hosted)
2. El pais dónde esta tu empresa deja de ser amigo de USA y te bloquean el acceso a github, aws, azure, etc
3. Ataque nuclear parcial, donde los principales objetivos son los datacenters de aws, azure, etc donde están desplegadas tus aplicaciones, datos, y sus backups
#48 Imagínate que mañana Google dice que hay un mes de carencia y que. Partir de ahí 20€ /mes por Gmail. Y 30 si usas Google docs, photos o Drive...
#48
Justamente parte de los argumentos que uso con mis clientes para usar soluciones híbridas y poner prácticamente todo dentro del paquete entregable, en la forma que sea, kuberntes, contenedores, maquinas virtuales, etc.
El momento que usas más servicios de los que te daría de forma nativa una DC, estás en sus manos.
Los tres escenarios son posibles, el 1 ya se da y el 2, bueno, tenemos la razón por la cuál existe Alibaba.
Al escenario 3 me suelo referir como guerra regional que llega a incapacitar la infraestructura de la región.
Pero bueno si hay una guerra nuclear probablemente la aplicación será lo de menos...
#79 Yo no me refiero a guerra nuclear total si mas bien algo parcial dónde solo se usarán misiles tácticos, a poco que se pase de ahí tal como dices seria el menor de nuestros problemas que no funcionara aws
#41 Yo para mis proyectos personales me lo curro todo a pelo, paso de dependencias, me gusta pensar que abandono un proyecto por ejemplo durante 5 años y tener la tranquilidad de que si me apetece recuperarlo para continuar trabajando en él todo va a seguir funcionando igual.
#41 aplicaciones que se podrán escribir en 100 líneas sin , escritas en 20 pero con cientos de dependencias.
En resumen, aplicaciones que podrían ocupar 100 líneas, ocupando 1000.
Y espérate a que Copilot empiece a reproducir los trozos de código malicioso haciendo de asistente...
#29 Creo que lo peor se daría el día en que alguien sin conocimientos de programación le pidiese a una IA que generase el código y esta lo copiase de un repositorio con código malicioso, porque ahí ya no tienes en ningún momento del proceso a alguien con conocimientos para saber que algo va mal.
#47 Exacto, en esa línea iba mi comentario.
#23 el problema es más serio que esto. Han logrado automatizar los procesos de creación de cuentas. Imagina que el proyecto malicioso tiene muchas más estrellas y forks que el original... a más de uno se la van a colar
#35 Y que tampoco es tan difícil eh. Tienes proyectos usados por miles de personas y empresas con apenas 200 estrellas. GitHub es puro leecher.
La gran estrategia de usar todos el mismo servicio.
Me fascina como en esta industria en la que se supone que tenemos grandes mentes pensantes hay tanta dejadez.
#6 Siempre relevante: https://xkcd.com/2347/
#17 tal cual
#17 Brillante como siempre.
#6 La realidad es que la centralización tiene muchas ventajas a nivel de UX. Y la mejor UX generalmente se impone a otro tipo de cuestiones técnicas.
#30
Me recuerdas a los Devs de ux de los proyectos en los que trabajo.
Centro del universo.
#6 Es el precio a pagar. Si en cambio todo el mindo tuviera que escribirse su propio software o comprarlo creo que estaríamos decadas por detras de donde estamos ahora y posiblemente con muchas más vulnerabilidades.
#34 recuerdas sasser ? En ese punto estaríamos
#36 Vale, y que se hizo? Desconectar el mundo de internet o desarrollar mejores antivirus parchear vulnerabilidades, migrar a sistemas más seguros...?
A mi plin, que yo uso Piko... Linux
coño. Hoy mismo he visto uno que he reportado. Por lo general son pequeños repos que simplemente tienen un readme, con una url apuntando a que te bajes un exe. Intentan impersonar proyectos reales
#9 De memoria /RAM
Buah! 7 capas de ofuscación!
Mientras no suplanté también los repos de npm, maven, etc…
#1 Lo harán... Algunos de ellos creo que se traen el código de Github...
Es un problema serio
#13 No pasa nada si se baja el original desde siempre, el problema es cuando buscas el código y das con el fork malo primero
#13 por si no le sabías hace poco (bueno unos pocos años) ya lo hicieron y creo que recordar que algo parecido con los repos CPAN hace muchos años.
Si lo que quieras es seguridad plena como devops, GNU Guix con paquetes reproducibles con hardware soportado. Intel de generaciones algo mas antiguas, Nouveau GTX o similares:
https://guix.gnu.org/es/
https://nouveau.freedesktop.org/VideoAcceleration.html
https://ryf.fsf.org/products/Talos-II-lite-Mainboard
Cara la Talos? Si, pero un thinkpad de GNU es relativamente barato y permite hacer muchisimas cosas con menos recursos de lo que piden otros sistemas. Un Guix con XFCE es perfectamente usable.
Guix es compleja? Ok, pero si trabajas en ciencia o entornos sensibles, tu entorno ha de ser 100% reproducible.
#19 ¿Y tú más?
OpenSSL es un software ajeno a Linux. Es como si incluyes las vulnerabilidades de Photoshop como vulnerabilidades de Windows
Y navegando contra un servidor con el OpenSSL vulnerable sería vulnerable tu edge en Windows
#26 no has contestado a la pregunta: ¿estaban los repos?
#32 repito no estaban los archivos. si los repositorios
hay que ser muy maligno para hacer algo así
#60 Bueno, este ataque es para corporaciones con bots ad-hoc y similares. Pero reconozco de conda y pypi es un desastre.
Ojala mas gente usase Guix, toda la instalacion y construccion se 'certifica' para que sea clonable por entero en cualquier maquina en identica salida.
#85 Sí ayuda con otras mitigaciones. Con malloc.conf por ejemplo, no aqui, en 'S' casca mucho software rerulero.
#19 Podía afectar a su máquina si hubiera usado alguna aplicación construida sobre OpenSSL que a su vez emplee el protocolo Hearthbeat. Así como los servidores están "obligados" a soportar el protocolo y responder a las peticiones, la mayoría de aplicaciones no hacen uso del mismo.
En particular, ninguno de los navegadores más habituales en Linux (Firefox y Chrome) hacen uso de OpenSSL. La aplicación más común que sí usaba OpenSSL y sí emplea hearthbeat es SSH, y sólo supone un problema si te conectas a servidores maliciosos de terceros (cosa rara).
Dicho eso, aunque las implementaciones de otros sistemas no eran vulnerables, las aplicaciones no siempre hacen uso de la implementación nativa. Por ejemplo, un servidor nginx o Apache corriendo en Windows también usaría OpenSSL y estaba totalmente expuesto.
#19 OpenSSL es usado hasta en videoconsolas. Tu comentario es una chorrada. Es como decir que hay una vulnerabilidad en FFMPEG, Cairo, Harfbuzz, Freetype, ImageMagick y demas echarle la culpa a Linux cuando esas librerias estan hasta en retretes japoneses. Y por supuesto muchas de esas librerias se usan en Windows. #46 OpenSSH creo que usaba y hoy usa un fork propio de OpenBSD.
#53 Las vulnerabilidades estaban en el sistema operativo del meneante que decía que su sistema era hiperseguro porque era Debian. Sí.
No me vengáis con películas que el hilo iba de otra cosa y sólo puse un ejemplo de vulnerabilidad crítica. CC #46
https://security-tracker.debian.org/tracker/status/release/stable
#54 Eso es la rama estable. Si usa SID o Testing se libra.
Es mas, si haces click en el paquete ves que muchos tienen el bug resuelto.
#56 Que sí que sí, que ninguna tiene vulnerabilidades en sus paquetes. https://security-tracker.debian.org/tracker/status/release/testing
Cierro que entramos en bucle.
#57 Unstable claro
, es su funcion, pero por lo general testing tiene un buen balance entre seguridad y novedad.
Pero yo no uso Debian, uso Hyperbola GNU con Dillo, Edbrowse, sacc para gopher, gplaces para Gemini, a veces Links y Iceweasel-UXP con Ublock Origin Legacy para emergencias. Pocos problemas tendre yo con el JS y/o anuncios, tengo hasta archivos de hosts con unos 200.000 dominios bloqueados. Pero para comentar en MNM via edbrowse me sobra.
Sobre el problema de Github, si el unico problema es meter un binario Win32 en vez del repo, pues cojonudo. La mayoria de devs hara caso omiso.
#58 A ver, no nos pongamos nerviosos, que el comentario al que he respondido desde el principio es #4
#53 El fork de OpenBSD es LibreSSL y lo crearon a partir de Hearthbleed. Hasta entonces usaban OpenSSL como la mayoría de aplicaciones.
#73 Pero OpenBSD tiene parches propios y mitigaciones distintas. De hecho hoy raro es que no tenga pledge y unveil tanto en el ejecutable de ssh como el de openssl.
#82 Nada de eso ayudaría con Hearthbleed. El problema no era de privilegios sino que que OpenSSL gestionaba por sí mismo la memoria.
No se si a alguien le ha pasado lo mismo que a mi. En dos ocasiones me abri cuenta gratuita en GitHub sin mostrar al publico. Subi algo de codigo y a los 3 meses fui a mirar y no habia codigo lo habian borrado.
#24 ¿Qué es lo que habían borrado, el repositorio, la cuenta, los archivos, los commits...?
#25 Tenia la cuenta pero no estaban los archivos
#24 he mirado 3 cuentas que llevo años sin usar y tienen todo de todo
#37 pues en mi caso me paso esto.
Una pregunta: ¿Si pego el enlace de un repositorio que contenga algún archivo malicioso en Virustotal (o cualquier sitio parecido) este lo detectaría?
#31 no
Yo uso GNU/Linux Debian y solamente instalo los programas que vienen en la distribución oficial. Hasta el momento cero problemas desde hace muchos años.
#4 [SECURITY] [DSA 5634-1] chromium security update in Debian.
Multiple security issues were discovered in Chromium, which could result
in the execution of arbitrary code, denial of service or information
disclosure.
Pero como yo uso Windows, no tengo ese problema.
#5 no te molestes, es un trol sin gracia…
#5 Yo uso edbrowse y tu maravilloso Edge tiene tanto vulns de Chrome como propias.
https://edbrowse.org
Y no troleo como dice #8, con quickjs se puede comentar perfectamente desde un netbook.
#5 Tú tienes otros problemas
#5 ¿Ah no?
https://www.tenable.com/plugins/nessus/191442
The version of Microsoft Edge installed on the remote Windows host is prior to 122.0.2365.63. It is, therefore, affected by multiple vulnerabilities as referenced in the February 29, 2024 advisory.
- Type Confusion in V8 in Google Chrome prior to 122.0.6261.94 allowed a remote attacker to potentially exploit object corruption via a crafted HTML page. (Chromium security severity: High) (CVE-2024-1938)
- Type Confusion in V8 in Google Chrome prior to 122.0.6261.94 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) (CVE-2024-1939)
#12 go to #16
#5 Pero como yo no uso Chromium no tengo ese problema
#5 En Linux el navegador por excelencia es Firefox, de Google nos fiamos lo mismo que de Microsoft.
#4 cuantos años?
A ver si este año me instalo el Linux en mi escritorio
#4 Ni tampoco estuvo 2 años vulnerable debido a Heartbleed, ¿verdad?: https://en.wikipedia.org/wiki/Heartbleed
#11 Hearthbleed ni afectaba a clientes ni era exclusivo de Linux.
#15 Un "y tú más" de libro.
En la wikipedia indica que afecta tanto a cliente como a servidor, e informa de que no afectaba a implementaciones TLS distintas a la de openssl, como por ejemplo la de Windows (que sí, que hay BSD, FortiOS, y miles de SO).
Por tanto, su máquina Debian, la que nos ocupa en este caso, de existir y ser usada en ese momento (de 2012 a 2014), podría ser vulnerable navegando contra un servidor malicioso.
#4 Esto es un problema para desarrolladores, no para usuarios.... de momento.
Al final puede que un desarrollador cuele código malicioso en los repos de Debían sin querer
#4 No nos engañes, tú aún usas cincel y martillo.