Portada
mis comunidades
otras secciones
#6:
El sistema es vulnerable, la vulnerabilidad era conocida y no se le dio solución y ahora alguien está atacando al sistema vulnerable.
El error es centrar el foco en el atacante, el error fue dejar abierta esa vulnerabilidad en primer lugar.
Muy mal por el enfoque del análisis.
El error es centrar el foco en el atacante, el error fue dejar abierta esa vulnerabilidad en primer lugar.
Muy mal por el enfoque del análisis.
#29:
#8 Lo de siempre, cuatro personas humanas, con sus limitaciones y responsabilidades, comienzan con ilusión un proyecto y lo comparten con la comunidad. Lo hacen así, en lugar de cerrar el código, tratar de venderlo y sacar mayor beneficio propio. El open source no habla de talento ni habilidad, sino de dar, a cambio de lo que recibes. De mejorar entre todos lo que hay. Y aún así, hay personas pretenciosas que critican con sorna.
OpenPGP es la base de un ecosistema enorme y es un logro lo que han conseguido, aunque cayera hoy mismo bajo el flood y no hubiera remedio.
Hablas de hacer un fork menospreciando el conocimiento que es necesario y el trabajo que hay detrás, sobretodo para quien consigue que ese fork llegue a buen puerto.
Seguro que tus conocimientos, si es que los tienes, no provienen de la inspiración divina, sino de haber aprendido a hombros de gigantes del software y del open source. Por supuesto si tienes alguna propuesta para mejorar OpenPGP, adelante somos todo oídos. No olvides incluirte entre los colaboradores.
OpenPGP es la base de un ecosistema enorme y es un logro lo que han conseguido, aunque cayera hoy mismo bajo el flood y no hubiera remedio.
Hablas de hacer un fork menospreciando el conocimiento que es necesario y el trabajo que hay detrás, sobretodo para quien consigue que ese fork llegue a buen puerto.
Seguro que tus conocimientos, si es que los tienes, no provienen de la inspiración divina, sino de haber aprendido a hombros de gigantes del software y del open source. Por supuesto si tienes alguna propuesta para mejorar OpenPGP, adelante somos todo oídos. No olvides incluirte entre los colaboradores.
#14:
#12 Me parece fantástico que se ponga el foco en la dificultad, el reto, de encontrar un diseño no vulnerable. No así focalizarse en que siendo vulnerable esté siendo atacado.
Con todos los respetos es bastante ridículo confiar en la supuesta ética de la gente cuando publicas un servicio en Internet. Que eso ocurriera en los años 90 vale, pero a estas alturas es infantil.
Si pones en la red un servicio que sabes que es vulnerable tarde o temprano esa vulnerabilidad será utilizada. Y eso lo sabe cualquiera con unos mínimos conocimientos de seguridad.
El lloriqueo posterior sobra.
Con todos los respetos es bastante ridículo confiar en la supuesta ética de la gente cuando publicas un servicio en Internet. Que eso ocurriera en los años 90 vale, pero a estas alturas es infantil.
Si pones en la red un servicio que sabes que es vulnerable tarde o temprano esa vulnerabilidad será utilizada. Y eso lo sabe cualquiera con unos mínimos conocimientos de seguridad.
El lloriqueo posterior sobra.
#35:
#16 Ni blockchain ni leches. Aquí no se trata de hacer que "cueste" publicar certificados o firmas, el problema es un simple ataque de DoS porque terceros pueden añadir datos (firmas) irrelevantes a un certificado. La solución es tan simple como no incluir por defecto todas las firmas, solo las que prefiera el emisor del certificado, y mejorar los clientes para que no se les atragante el exceso de firmas.
#30:
#2 yo de eso llevo varios meses dandome cuenta. Decenas de aplicaciones que nos parecen la mar de populares son mantenidas por equipos que llegan a ser de UNA persona. Madre mia, la de empresas que ganan dinero con el opensource y no se preocupan una mierda de sentar unas bases solidas para esas comunidades. Y si no, te pongo un ejemplo muy potente: PHP.
Que bueno ver que desde la gran T se preocupan de dar cobertura a un tema tan interesante como desconocido.
Que bueno ver que desde la gran T se preocupan de dar cobertura a un tema tan interesante como desconocido.
#4:
#1 #2 #3
Le acabo de echar un vistazo al lenguaje OCaml (que no conocía) y desde luego meterse ahí, tiene tela
https://caml.inria.fr/pub/docs/manual-ocaml-4.08/
Le acabo de echar un vistazo al lenguaje OCaml (que no conocía) y desde luego meterse ahí, tiene tela
https://caml.inria.fr/pub/docs/manual-ocaml-4.08/
Comentarios
El sistema es vulnerable, la vulnerabilidad era conocida y no se le dio solución y ahora alguien está atacando al sistema vulnerable.
El error es centrar el foco en el atacante, el error fue dejar abierta esa vulnerabilidad en primer lugar.
Muy mal por el enfoque del análisis.
#6 el foco en el atacante es consecuencia intrínseca de la vulnerabilidad: el problema de diseño hacía que se confiase en la ética de los usuarios.
Si se tratase de un simple bug en el código pero el diseño fuese sólido no estarían insultando.
#12 Me parece fantástico que se ponga el foco en la dificultad, el reto, de encontrar un diseño no vulnerable. No así focalizarse en que siendo vulnerable esté siendo atacado.
Con todos los respetos es bastante ridículo confiar en la supuesta ética de la gente cuando publicas un servicio en Internet. Que eso ocurriera en los años 90 vale, pero a estas alturas es infantil.
Si pones en la red un servicio que sabes que es vulnerable tarde o temprano esa vulnerabilidad será utilizada. Y eso lo sabe cualquiera con unos mínimos conocimientos de seguridad.
El lloriqueo posterior sobra.
#14 claro que es ridículo, pero una vez la han cagado y se la lían, lo único que pueden hacer a corto plazo es patalear.
O callarse, pero han elegido patalear.
#15 Señalar con el dedo al atacante e insultarlo es infantil, hay formas mucho más serias de abordar el reto.
#17 Ya, no discrepo en eso. De hecho que sea infantil es problema suyo a nivel personal, pero además es contraproducente si lo que pretenden es que se reduzcan los ataques mientras rediseñan todo.
#14 no estoy del todo de acuerdo, mira el caso de Wikipedia, cualquiera puede vandalizar una o miles de páginas, de hecho pasa todos los días, pero es posible detectarlo por bots y usuarios de la comunidad.
Con gpg sería relativamente fácil evitar los bots en los servidores, e implementar pesos a las firmas y firmas negativas, con esto resuelves el problema mediante la revisión de los usuarios, el problema real, es que el código no está mantenido y hacer cambios parece muy difícil.
#23 porque no les ayudas a definir un plan de ataque, y con algo de suerte quizas incluso en el desarrollo del mismo. El opensource es lo que tiene.
#14 Y encima, tienes que confiar en la etica de los usuarios para una herramienta, que "toca los huevos" a gobiernos e instituciones, ya que no pueden espiarte...
¿Quien es el beneficiado de este ataque? Pues ya sabes de dónde sale el atacante....
#6 El sistema es vulnerable y hay que centrarse en el que vulnera en el sistema (aunque también haya que solventar el problema), porque si no te centras en el que vulnera el sistema podrían centrarse en ti cuando te atracan en una esquina en lugar de centrarse en el atracador.
#6 Pues sí, tienes toda la razón, ese "hijo de puta" en realidad es el niño diciendo que el rey está desnudo: tiene una vulnerabilidad del tamaño de una CATEDRAL, pero la culpa es del atacante que se ha aprovechado de ella porque los que la mantienen no han hecho NADA por solucionarla.
Y ese "hijo de puta" podría ser, fácilmente, un gobierno al que le interesa que el sistema deje de ser útil o práctico; o una empresa que quiere hundirlo para vender una solución propia…
Incluso si es sólo un "hijo de puta" suelto (me extraña MUCHO que un solo tipo haya creado 150.000 firmas PGP con las que, a su vez, verificar otras firmas PGP, es un currazo de la hostia), es una vulnerabilidad que tienes que solucionar en cuanto tienes conocimiento de ella. Y no lo han hecho.
En realidad, les han hecho el equivalente a un DOS o DDOS (sigo pensando que no ha sido un solo tío), y su respuesta sería la equivalente a decir "¡Jo, qué malos sois"!, en vez de poner un balanceador de red para mitigar el ataque, en vez de HACER ALGO.
En realidad, deberían darle las gracias: por fin alguien les va a obligar a hacer algo al respecto.
#52 "En realidad, deberían darle las gracias: por fin alguien les va a obligar a hacer algo al respecto."
Totalmente de acuerdo.
Correo seguro, correo encriptado, "Pretty Good Privacy"... pero al final, resulta que tenia un agujero del tamaño de un elefante, que no han querido tapar... bravo!
#16 Ni blockchain ni leches. Aquí no se trata de hacer que "cueste" publicar certificados o firmas, el problema es un simple ataque de DoS porque terceros pueden añadir datos (firmas) irrelevantes a un certificado. La solución es tan simple como no incluir por defecto todas las firmas, solo las que prefiera el emisor del certificado, y mejorar los clientes para que no se les atragante el exceso de firmas.
#35 Correcto: cuando tienes 10, 20, 30 firmas de personas que, a su vez, son de confianza verificable, ¿para qué necesitas 1.000, 10.000? No tiene sentido. Vale más la calidad y verificabilidad del grado confianza de las firmas que la cantidad.
Por ejemplo, si tú me envías algo firmado por PGP y tu firma viene avalada por 5 usuarios de Menéame que conozco, eso me vale más que si viniera firmada por 10.000 usuarios desconocidos para mí.
... Esperanza Aguirre?
#1 #2 #3
Le acabo de echar un vistazo al lenguaje OCaml (que no conocía) y desde luego meterse ahí, tiene tela
https://caml.inria.fr/pub/docs/manual-ocaml-4.08/
#4 parece diseñado por Satán
#32 #4 Si. Satan directo. Usar una librería de esas es para fastidiar.
MLDonkey... ponte a compilar en scratch para algo que no sea x86
#4 Una muestra de la inmensa capacidad de ofuscación que tiene la programación funcional.
#4 A mi lo que me ha parecido curioso es que tanto "OpenSource" y que se queda sin mantenimiento y viendo un problema en eso de "que pasa si algún día se rompe algo" no han hecho nada hasta que ha venido un HDP a dar por saco. Pues aunque suene mal les está bien por no haber migrado el sistema durante todo este tiempo (no veo en el artículo cuantos años lleva desatendido).
Al final va a parecer que la comunidad solo sirve para crear remixes de Ubuntus y algo más.
#1
No te lo vas a creer, pero esto es bastante serio.
#43 Sí, es jodidamente serio.
Con este ataque obligan a evolucionar o morir, la comunidad de software libre es experta en evolucionar, no se cómo lo hará, pero seguro que algunos genios sacarán el conejo de su chistera.
#16 Pero es que el problema no es que los certificados tengan peso. La base de datos está bien.
El problema es la verificación del archivo. Ese algoritmo es ineficiente y lento si el certificado con el que verificas el archivo está firmado demasiadas veces. Es que no tiene ni pies ni cabeza.
#18 También en las cadenas de bloques ha habido mucho desarrollo para mitigar la carga de verificar firmas criptográficas, y se han aplicado diseños en forma de árbol y otras modalidades que permiten mitigar esos efectos.
A su vez se ha creado una red de confianza en la que los nodos son quienes verifican las firmas y dado el diseño y los incentivos los usuarios finales no tienen una necesidad real de verificarlas todas si no solo la parte que necesitan, dando por hecho que el resto ya han sido verificadas (la competición por una recompensa hace que existan nodos compitiendo y dejando en evidencia a quienes incumplen las normas).
De nuevo, es un reto, hay que abordarlo.
Los lloriqueos con faltas de respeto están fuera de lugar.
#19 Es que no tiene nada que ver.
En blockchain solo se firma 1 vez el paquete de la cadena. La grácia está en encontrar quien lo firma y ahí entran los diferentes sistemas para seleccionar quien lo firma (quien soluciona el acertijo primero (precio) o quien es señalado a dedo, etc.) y el resto corroboran que la firma es válida porque el firmante cumple los requisitos propuestos y por eso se añade el eslabón a la blockchain.
En OpenPGP por su idiosincrasia no tiene sentido que únicamente 1 persona firme el certificado porque está pensado para funcionar sin un ente central que controle el sistema si no en un sistema ad-hoc.
Está pensado para que si tu me conoces me firmes mi certificado diciendo que soy quien digo ser sin que nadie tenga que dar su visto bueno. Cuanta más gente me firme más "seguridad" tendrá el que reciba un mensaje firmado por mi firma de que soy quien digo ser. Pero todas las firmas tienen el mismo "valor".
Entiendo que el no tener un límite máximo es un problema. "Encarecer" la firma del certificado, como los juegos de bitcoin para seleccionar el firmante, tampoco tienen sentido porque un maleante podría saturar las firmas "baratas" y el que quisiese firmar de manera legítima el certificado se encontraría con la barrera de que las firmas son "caras" y no podría firmar. Sería lo mismo que poner un límite máximo de firmas algo que inhabilitaría el sistema.
Lo de eliminar el servidor OpenPGP no me parece mal. Pero acabaríamos con una organización rollo SSL que es precisamente lo que no se quiere.
El ataque más que venga de un hijo de... huele a más a un gobierno que quería rebentar el sistema. Que son los que tienen más motivos.
#22 Está pensado para que si tu me conoces me firmes mi certificado diciendo que soy quien digo ser sin que nadie tenga que dar su visto bueno. Cuanta más gente me firme más "seguridad" tendrá el que reciba un mensaje firmado por mi firma de que soy quien digo ser. Pero todas las firmas tienen el mismo "valor".
Es un diseño que parece más manual que automatizable, en el sentido que verificar todas las firmas que tiene alguien sin saber de donde vienen esas firmas no te aporta ninguna seguridad, necesitas de alguna forma seguir una cadena de confianza. De ser así no tiene sentido perder el tiempo verificando firmas de quienes no forman parte de la cadena de confianza. No veo motivo entonces para tener que verificar todas esas firmas del ataque.
Si verificas cualquier firma de cualquiera que decida firmar es como si no estuvieras verificando nada por que no sabes quién son ni que fiabilidad te aportan.
Da la sensación que se ha querido utilizar de forma automatizada un sistema que solo tiene sentido de forma manual, es decir, solo verificar las firmas que realmente te interesan haya diez o haya diez millones disponibles para esa identidad.
En cualquier caso hacer un diseño que no sea vulnerable a ataques de fuerza bruta como el del meneo es lo esperable en un servicio publicado en Internet que aspira a ser de uso generalizado. La dificultad del reto no es excusa.
#22 Habría una forma: que las firmas de confianza fueran en un fichero aparte, ligado al primero criptográficamente, y que la firma original contuviera, además de ese enlace y la suma de comprobación, el número de firmas que contiene aquel. El fichero no se alargaría mucho, y seguiría siendo confiable. Del usuario final dependería descargar o no el fichero de firmas, como seguridad extra.
Otra alternativa sería que la firma sí incluyera las "firmas de confianza" en el mismo fichero (por seguridad, entiendo que un segundo archivo puede suponer una posible brecha), pero que el sistema sólo descargue la firma original para la verificación de mensajes/ficheros/etc., introduciendo un punto de corte en la descarga ("descargar hasta ahí", coincidiendo con el inicio de las firmas de confianza), de modo que no se descargue firma original + firmas de confianza (se podría hacer opcionalmente).
#59 Es que la verificación de OpenPGP va a pares.
El programa compara los certificados con la gente que tu tienes en tu lista de confianza, así que el programa cruza todas esas firmas con tu propia base de datos para ver si la firma es de confianza.
No es un sistema SSL centralizado con un ente que da validez al certificado y/o que tiene más autoridad que otras firmas. La validez se la da cada persona de manera ad-hoc. Por eso es tan complicado de solucionar este problema.
Está pensado para que yo te de mi clave y tu en tu casa sepas que ese mensaje te lo he enviado yo y nadie más. O si tu y yo no nos conocemos pero tenemos 1 amigo en común que ha firmado mi certificado y tu confías en tu amigo, como nuestro amigo en común ha firmado mi certificado automáticamente yo paso a ser "confiable" en tu sistema porque tu amigo así lo dice. Por eso hay que comparar todas las firmas 1 a 1 y es donde explota todo.
#65 Hmmm… ¿Y por qué no comparar sólo las firmas de las personas en común? Incluso, las X primeras personas en común, en caso de personalidades con muchos conocidos. Si tú me envías algo, pero no te conozco de nada ni conozco a los que han firmado tu certificado, esas firmas para mi son inútiles, sólo me queda confiar en que me estás diciendo la verdad.
#66 Precisamente es encontrar las comunes el problema. La manera de encontrar esos certificados firmado por alguien de confianza es precisamente comparando entrada por entrada.
Para encontrarlas has de compararlas. Sí, se puede hacer de que a la que el algoritmo seleccione las entradas a comparar de manera escalada, o de alguna manera más inteligente para "minimizar" el camino a ver si hay suerte, pero si no das con coincidencias pronto las puedes acabar comparando todas igualmente en el peor de los casos.
Lo de siempre, empiezan cuatro mataos, la cosa crece, se les va de las manos, no dan abasto y todo manga por hombro hasta que peta. Cuando peta hacen un fork. Y vuelta a empezar. Es el ciclo del software libre.
#8 cuatro cuatro mataos si no se lo han reventado antes no serán tan pocos. Y lo digo porque siempre ha habido intentos de romper el proyecto por parte de paises y corporaciones. Hasta hace dos días era un protocolo altamente seguro.
#11 y sigue siendo altamente seguro. Por lo que veo no te has molestado ni en leer de que va el tema.
#21 llevo años usando pgp en mis diferentes clientes de correo . Incluso tengo en Gmail mailenvelope. Que sea altamente confiable no quiere decir sea infalible ( que ya pasó en su día con OpenSSH ) y está vez les han atacado por la puerta trasera. Que no puedo contra la encriptacion les saturo los keyservers . Esa infraestructura no está preparada para los tiempos que corren .
#8 Eso que cuentas suena bastante a casi todas las empresas en las que he trabajado, picando código propietario y cerrado
Qué coño a "casi todas"... TODAS funcionaban así, joder
#20 mejor nos montamos una granja... de servidores!
#8 Lo de siempre, cuatro personas humanas, con sus limitaciones y responsabilidades, comienzan con ilusión un proyecto y lo comparten con la comunidad. Lo hacen así, en lugar de cerrar el código, tratar de venderlo y sacar mayor beneficio propio. El open source no habla de talento ni habilidad, sino de dar, a cambio de lo que recibes. De mejorar entre todos lo que hay. Y aún así, hay personas pretenciosas que critican con sorna.
OpenPGP es la base de un ecosistema enorme y es un logro lo que han conseguido, aunque cayera hoy mismo bajo el flood y no hubiera remedio.
Hablas de hacer un fork menospreciando el conocimiento que es necesario y el trabajo que hay detrás, sobretodo para quien consigue que ese fork llegue a buen puerto.
Seguro que tus conocimientos, si es que los tienes, no provienen de la inspiración divina, sino de haber aprendido a hombros de gigantes del software y del open source. Por supuesto si tienes alguna propuesta para mejorar OpenPGP, adelante somos todo oídos. No olvides incluirte entre los colaboradores.
#29 Es cierto, un fork escort cuesta mucho que llegue a buen puerto y si no lo pintas se corroe. Es una pena que solo haya una persona que lo sepa pintar, eso si se acuerda, y que no lo haga gratis.
#29 El típico "esto es una mierda, hay que tirarlo y hacerlo de nuevo" de cualquier programador sin experiencia.
¿No tienen ningún backup en ningún servidor de antes del ataque?
Se podría seguir trabajando evitando añadir un número importante de firmas en cada certificado... y que cada día se escaneara que firmas son validas y cuales no (un programilla en ML para marcar los ciertos y los falsos podría solucionar el problema en un 19 de cada 20 casos) hasta que encuentren alguna solución.
La vulnerabilidad afecta a todas las distros de Linux a la hora de verificar los paquetes a instalar/actualizar
#33 Eso que dices me suena muy raro. En todas las distribuciones con las que he trabajado las claves públicas vienen incluidas de fábrica, no tienes que descargaraos de ningún servidor. Básicamente porque si no sería imposible verificar la instalación.
Otra cosa es cuando añades repositorios de terceros, ahí sí que tienes que importar la clave pública. Puedes importarla de los servidores de OpenPGP, en cuyo caso estarías expuesto a este ataque, o dejar que tu gestor de paquetes te pregunte si quieres añadirla, en cuyo caso la tienes que verificar a mano, pero el ataque no te afecta.
#38 Tan sencillo como añadir firmas en el servidor validando una clave pública determinada para que pase a ser inutilizable
Hansen warned that the verifying signatures could make GnuPG attempt to deal with spammed certificates, even though they are not imported, causing people's installations to break.
https://www.itnews.com.au/news/poison-certs-imperils-gnupg-checking-of-linux-software-527505
#40 Pero a ver, espamear el servidor de claves te afecta en el momento de importar una clave, porque tienes que procesar chorrocientas mil firmas, pero una vez que has importado la clave en tu almacén ya te resbala. Y por otra parte, en las distribuciones que yo uso (OpenSuse en casa, CentOS en el trabajo) las claves las tienes que validar tú a mano.
#48 La verificación no es de la clave en sino de las firmas que lleva el certificado. Va a hacer la validación igualmente aunque ya la tengas importada
#57 O estoy muy confundido, o creo que no entiendes cómo funciona el sistema.
Yo genero mi par de claves (RSA, ECC, o lo que sea), utilizo mi clave privada para firmar un documento, y tú teniendo mi clave pública puedes verificar que efectivamente yo soy el creador de dicho documento. El problema es cómo distribuir esas claves públicas. Hay básicamente tres soluciones:
- De manera manual, la primera vez que ves una clave pública el sistema de pregunta si confías en ella o no. Es lo que hacen SSH y muchos gestores de paquetes.
- Mediante una autoridad certificadora (CA), que utiliza su clave privada para firmar las claves públicas de terceros. Para poder validar dichos certificados (clave pública mas datos del propietario mas firma) necesitas tener la clave pública de la CA. Este es el sistema que utilizan los navegadores web con HTTPS.
- Cualquier firma las claves de cualquier otro. Si tú firmas mi clave, tus amigos podrán confiar en mi, porque se fían de ti. Por lo tanto se crea una "red de confianza" (https://en.wikipedia.org/wiki/Web_of_trust).
Este ataque sólo afecta al tercer caso, pero sólo al proceso en sí de importación de una clave pública (o certificado, según el caso) en tu almacén de claves. Una vez que está importada, ya te da igual.
#58 Las claves no son eternas, caducan por diseño. En algún momento tendrán que renovarlas.
#61 Las clases sí pueden ser eternas. Ahora mismo tengo en mi sistema el repositorio de Microsoft, para el VS Code, y su clave no caduca nunca.
Y entre las que sí caducan, la nueva clave se puede distribuir e importar unos meses antes de que caduque la actual, y venir firmada por ésta. Y lo vuelvo a repetir, no necesitas los servidores de OpenPGP, porque las distribuciones ya tienen su propia infraestructura. De hecho, en 15 años no recuerdo haber añadido jamás un repo que importara las claves desde la red de OpenGPG.
#38 en Manjaro actualizas las claves de vez en cuando.
#42 En ese caso sí te puede afectar, pero dependerá de como se distribuyan las nuevas claves, no hay porqué usar los servidores de OpenPGP.
#49 supongo que no usarán los de openpgp aunque no lo sé.
Hay que decirlo más.
"... como dice el propio Hansen: no cree que la red actual sea salvable."
¿Veremos pronto un GooglePGP?
Se meten en un block chain y mano de santo. Las bases de datos centralizadas son muy fácilmente saturables.
#10 El problema no es la base de datos. ¿Has leído si quiera el artículo?
#13 Sí está en la base de datos, que ahora contiene muchas más firmas de las previas por el ataque.
Las cadenas de bloques ya han abordado ese reto y las principales como Bitcoin tienen sistemas de protección que hacen inviables ese tipo de ataques de forma continuada. Una de las herramientas es que cada entrada en la base de datos supone un coste, por lo que el atacante se acaba arruinando si continúa con su actividad.
#10 O algún sistema Cloud con DevOps 3.0 y kubernetes on rails. También podrían dar conciertos.
#25 #10 Lo que no se es si entendéis el problema. Los keyrings son bases de datos centralizadas de certificados que se validan mediante la firma de pares y cualquiera puede firmarlos por ser un sistema abierto. Exigir proof of work que valide cada firma evitaría el problema en curso y la descentralización del blockchain daría resiliencia a todo tipo de ataques.
#39 Me has metido un montón de palabras de moda, falta empoderar el cifrado y darle un toque feminista.
#47 Ha, tu comentario es simple y burdo trolleo, gracias por aclararlo.
#53 Era una apreciación con toques humorísticos, aludiendo a la terminología de startup que usas. Si lo ves claro te puedes hacer un fork y mejorarlo, o vender el humo con un montón de palabras exhuberantes de moda y sacar cacho....
#55 Burdo trolleo
Ahora es cuando alguien dice eso de no es un error, es una feature. Y lo peor, que es verdad.
Salu2
Pues llamar hijoputa al atacante no va a resolver el problema. quiza podria probar la via penal
pero...
En serio hay codigo importante que ya no se mantiene?
#2 Dicen que va excepcionalmente bien. No hay necesidad de añadir ni quitar nada, ¿para qué tocarlo? Ahora viene la historia, que nadie sabe como va...
#3 Joder, me recuerda a la peli "City of Ember"…
#2 Está claro que el tío Linus ha sentado cátedra con sus metáforas floridas...
#2 yo de eso llevo varios meses dandome cuenta. Decenas de aplicaciones que nos parecen la mar de populares son mantenidas por equipos que llegan a ser de UNA persona. Madre mia, la de empresas que ganan dinero con el opensource y no se preocupan una mierda de sentar unas bases solidas para esas comunidades. Y si no, te pongo un ejemplo muy potente: PHP.
Que bueno ver que desde la gran T se preocupan de dar cobertura a un tema tan interesante como desconocido.
Pero en tu analogía, ponle que el maletin de billetes está abierto de par en par y que te quedas en la esquina gritándo y protestando sin poderlo cerrar.
Con tanto grito lo que haces es atraer la atención y que venga más gente a llevarse billetes.