Si me haces perder el tiempo con reportes inútiles, te voy a banear y me voy a burlar de ti públicamente

• En el /.well-known/security.txt del proyecto open source curl se indica lo siguiente
• Reciben reportes sobre problemas de seguridad encontrados en productos propios, pero no ofrecen recompensas monetarias ni beneficios de ningún tipo por los problemas reportados
• En cambio, para los problemas confirmados, indican agradecimiento y reconocimiento de mérito en la documentación
• Advierten que, si alguien les hace perder el tiempo con reportes deficientes o sin sentido, aplicarán burla pública y bloqueo
• Usan el formato estándar security.txt para resumir de forma concisa los puntos clave de su política de reportes de seguridad

---

Política de reportes de seguridad del proyecto curl

• El proyecto open source curl recibe reportes sobre problemas de seguridad en productos creados por el proyecto curl
  • Los reportes pueden enviarse por correo electrónico ([e-mail]) o a través de la página de avisos de seguridad de GitHub
• Dejan claramente establecido que no existe una política de recompensas, y no ofrecen compensación monetaria ni de otro tipo
  • En su lugar, para los problemas confirmados, ofrecen agradecimiento y reconocimiento de mérito en la documentación correspondiente

Advertencia sobre reportes inapropiados

• El proyecto indica explícitamente: “Si nos haces perder el tiempo con reportes inútiles, te prohibiremos el acceso y nos burlaremos de ti públicamente”
  • Se trata de una advertencia contundente para evitar reportes poco profesionales o sin fundamento
  • Enfatiza la calidad de los reportes y una cultura de divulgación responsable

Procedimiento de reporte de seguridad e información oficial

• Medios de contacto: correo electrónico ([e-mail]) y página de avisos de seguridad de GitHub
• Documento de política: publicado en https://curl.se/dev/vuln-disclosure.html
• Página de agradecimientos: disponible en https://curl.se/docs/security.html
• Idioma preferido: inglés (en)
• Fecha de vencimiento de la política: indicada como 22 de octubre de 2026
• URL oficial: https://curl.se/.well-known/security.txt

[slowandsnow]

Parece que la respuesta es cerrar la página de issues de GitHub por los reportes abiertos indiscriminadamente

[skageektp]

Me hace pensar que la burla pública podría no ser ilegal según la ley coreana jajaja

[GN⁺]

Opiniones de Hacker News

• Hace poco vi que cURL eliminó su programa de bug bounty porque se estaba llenando de reportes falsos de bugs generados por IA
  Artículos relacionados: hilo de Hacker News, nota de ETN

  • Si el reporte viene bien armado, con parche y hasta caso de prueba, creo que vale la pena recompensarlo aunque haya sido generado con IA

• Se siente como si por fin hubiera arrancado de verdad la era de la IA

  • Todos esperábamos que esto pasara, y más bien sorprende que haya tardado tanto

• Creo que el modelo de distribución del software de código abierto se volvió una estructura insostenible
  El movimiento del software libre originalmente buscaba garantizar que los usuarios tuvieran la libertad de modificar y mejorar el software por su cuenta
  Pero ahora se creó una cultura donde se espera gratis seguimiento de issues, revisión de PR, soporte por correo y hasta parches de seguridad
  En realidad, todo eso es trabajo de soporte pago, y salvo que sea un hobby, necesita compensación

  • Hace tiempo hice un generador sencillo de sitios estáticos con HapiJS y lo subí a GitHub, pero cuando se difundió en Reddit me llegaron avalanchas de PR, reportes de bugs e insultos
    Aunque dejé claro que “no pensaba dar soporte”, siguieron cayendo críticas, y ese fue mi primer y último proyecto OSS
  • Me imagino un sistema donde los usuarios puedan poner pequeñas recompensas por las funciones que quieren
    Si varios usuarios quieren la misma función, el fondo crece, y el desarrollador puede elegir ese trabajo y hacerlo
    El project manager y los testers también se llevan una parte, así todos tienen incentivos
  • No estoy de acuerdo con la idea de que los fundadores del open source no pretendían un modelo así
    El modelo Bazaar de Eric S. Raymond y la “ley de Linus” (con suficientes ojos, todos los bugs son superficiales) justamente parten de la colaboración abierta
  • No comparto la visión de los desarrolladores FOSS como víctimas
    Ellos mismos pueden fijar límites y reglas, y bloquear a la gente grosera
  • La colaboración a través de issue trackers públicos como GitHub ya se volvió parte de la cultura básica del código abierto a lo largo de dos generaciones

• Últimamente estoy ayudando con un proyecto de documentación de OWASP, y estudiantes de India están subiendo en masa PR e issues absurdos generados con LLM
  Propongo una estructura como la de Ghostty, donde primero todo empiece como “Discussion” y solo los issues aprobados por los maintainers puedan convertirse en PR

  • He visto entre desarrolladores indios una cultura de ‘fake it till you make it’ donde evitan hacer preguntas y simplemente siguen adelante
  • Muchos estudiantes mandan PR con código generado por LLM para tener actividad en GitHub para el currículum, pero cuando les pides cambios no entienden nada
    Como dijo Torvalds, por culpa de los LLM el mantenimiento de código parece que se va a volver una pesadilla
  • Si este tipo de PR sin sentido sigue aumentando, va a ser cada vez más difícil encontrar los issues reales
  • Creo que una de las razones de la caída de Stack Overflow también fue la explosión de preguntas de baja calidad

• Una vez subí un bug report y, porque faltaba información para reproducirlo, me cayó una crítica durísima en Reddit
  Después de eso casi dejé por completo las redes sociales

  • El equipo de curl normalmente pide información adicional con cortesía, así que si no respondiste bien, es natural que lo cierren
  • Los maintainers la pasan mal tratando de encontrar bugs reales entre montones de reportes erróneos
    Hay que recordar que la crítica va dirigida al reporte, no a la persona
  • El equipo de curl más bien es bastante generoso, y las agresiones en Reddit no tienen nada que ver con la comunidad oficial
  • Irónicamente, incluso las reacciones de este mismo hilo tratan sobre una experiencia “imposible de reproducir”

• Para resolver el problema de las contribuciones de baja calidad causadas por el Eternal September y los LLM, creo que más bien hace falta más fricción elevando la barrera de entrada
  Por ejemplo, que un primer contribuyente tenga que mandar su reporte en una postal con código QR o algo así

  • Pero esa fricción podría no servir, porque a menudo los que mejor la soportan son justamente los contribuyentes spam, no los reales

• Si un proyecto se ahoga entre PR llenos de emojis y errores, el modelo Bazaar deja de funcionar

  • Me hace pensar en la ley de Brandolini
    El exceso de información no verificada no es solo un problema del open source, sino de toda la sociedad
    La cultura todavía no tiene un sistema inmunológico contra la información falsa

• Me hizo recordar la época en que The Pirate Bay publicaba los correos de amenazas legales de la MPAA
  Todavía puede verse ese rastro en la página de respuestas legales de TPB (Web Archive)
  Su forma de actuar no fue realmente efectiva, pero quedó como una especie de símbolo de resistencia

• En un proyecto open source famoso que mantiene un amigo, estudiantes universitarios chinos mandan reportes falsos de vulnerabilidades de seguridad como tarea
  La mayoría no se puede reproducir, así que solo hacen perder tiempo a los maintainers
  Además, por diferencias de configuración entre distribuciones, a veces una vulnerabilidad real aparece en la configuración del paquete y no en el código upstream
  En el subreddit de Kryptos K4 también sobran publicaciones tipo “¡lo resolví!” hechas con LLM, y al primer incumplimiento los banean de inmediato
  Preocupa que esta trampa de tareas con IA ya se haya extendido a todos los ámbitos

  • Como humanos, no deberíamos perder el placer de aprender y crecer
    Por más que avance la IA, el valor del aprendizaje propio sigue siendo irremplazable
  • En Kryptos K4, aunque el LLM conozca todos los datos, no logra aportar ni una sola idea nueva
    Al final, un LLM no es pensamiento creativo, sino apenas una versión mejorada del autocompletado
  • En China es común que estudiantes de medicina no escriban sus artículos ellos mismos y contaminen las revistas académicas con textos por encargo
  • Al final, el fraude académico termina llegando al mercado, y mientras haya incentivos económicos, esto no se va a detener

• Creo que estaría bien que GitHub les diera a los usuarios algún puntaje de confianza o sistema de reputación

  • Pero como GitHub pertenece al departamento de IA (Microsoft CoreAI), es muy posible que más bien fomente este tipo de comportamiento
    Artículo relacionado: nota de GeekWire
  • La idea de que Microsoft les ponga una puntuación social a los desarrolladores es terrible
  • Más bien creo que sería mejor anonimizar a los usuarios para reducir la motivación de buscar fama
  • Incluso en plataformas como HackerOne existe un sistema de reputación, pero los reportes de baja calidad siguen desbordándose
    Al final las empresas terminan pagando servicios de triage intermedio
    En ese proceso, a veces responde primero alguien que no es un experto real, y los reportes legítimos terminan demorándose
    La situación actual es una estructura mala para todos y sigue empeorando