"Nuestros clientes de pago necesitan X; ¿cuándo lo van a arreglar?"
(twitter.com/maximilianhils)- Un usuario corporativo de una empresa con clientes en industrias reguladas (bancos, agencias federales, etc.) presionó en un issue público para que se revelara el calendario de la próxima versión de la herramienta open source mitmproxy, alegando que sus clientes no podían usar el software debido a vulnerabilidades High y Critical conocidas
- La vulnerabilidad estaba en una parte de una biblioteca que mitmproxy no utiliza, por lo que en la práctica no afectaba a los usuarios reales
- El maintainer no rechazó la solicitud y respondió que, si necesitaban una versión de parche oportuna, podían firmar un contrato de soporte (support contract), indicando el correo electrónico de su perfil
- El usuario corporativo interpretó esta respuesta como una "broma o un intento de extorsión apenas disimulado" y envió un correo de protesta
- La clave no es que preguntar por el calendario de lanzamiento sea ilegítimo, sino que hace falta una actitud de colaboración del tipo "¿cómo podemos ayudar con contribuciones o financiamiento?"; posteriormente, el autor original del comentario envió una disculpa sincera
Contexto del incidente
- Según la explicación de contexto adjunta, existe una vulnerabilidad en una biblioteca distribuida junto con mitmproxy, pero en una parte que mitmproxy no usa, así que no afecta a los usuarios reales
- Tras volverse viral afuera, se añadió contexto adicional sobre el caso
Exigencia inicial del usuario corporativo (issue de GitHub)
- Hace 16 horas, un usuario mencionó a otro miembro del proyecto, @Prinzhorn, para preguntar por la fecha objetivo (target date) de la próxima versión
- Explicó que sus clientes en industrias reguladas (regulated industries), como bancos y agencias federales, tienen prohibido por normativa usar software con vulnerabilidades conocidas de severidad High o Critical
- Quieren definir su postura sobre si esperar, pero insisten en que necesitan algún tipo de fecha objetivo
Respuesta del maintainer mhils
- El miembro mhils respondió hace 15 horas que, si les interesaba una versión de parche oportuna para cumplir los requisitos de compliance de su empresa, estaba dispuesto a establecer un contrato de soporte
- Indicó que sus datos de contacto están en el correo electrónico de su perfil (incluyendo la marca ":-)")
Correo de protesta ("Concerning response")
- Después, se envió a github@hi.ls un correo desde un dominio us.ibm.com con el asunto "Concerning response" (marcado como Jul 14, 2023)
- Comienza con "Mr. Hils" y señala que, más que escalar el asunto o llenar el issue tracker de GitHub con palabras innecesarias, la intención era explicar mejor la solicitud de una fecha objetivo para obtener una respuesta directa
- También aclara que espera que este mensaje de seguimiento no se tome a mal y que no era esa su intención
- En la parte resaltada, afirma que asume que la respuesta del maintainer no era una respuesta oficial del proyecto sino una broma, o peor aún, un intento de extorsión apenas disimulado (thinly veiled extortion attempt) (la frase se corta mientras revisaba la documentación oficial del proyecto)
Postura del maintainer
- Aclara explícitamente que su respuesta no era una broma
- Señala que un enfoque del tipo "nuestro cliente de pago necesita X; ¿cuándo lo van a arreglar?" quizá no sea la mejor manera de presentarse ante un proyecto open source
- Reconoce que preguntar por el calendario de lanzamiento no le molesta y que es una pregunta válida (valid)
- Pero subraya que el contexto debería ser "nos interesa que esto ocurra; ¿cómo podemos ayudar a hacerlo posible?" (con contribuciones o financiamiento) y no "ustedes están causando un problema a nuestros clientes"
Cierre
- El autor original del comentario envió una disculpa sincera (genuine apology), y el maintainer dice apreciarla de verdad
- Pide a todos asumir buenas intenciones (assume good intentions) y tratarse con amabilidad
1 comentarios
Comentarios de Hacker News
Si lees este issuehttps://github.com/mitmproxy/mitmproxy/issues/6051, la solicitud de IBM parece mucho más razonable de lo que se ve en el tuit.
El problema es que hay un CVE en una dependencia de mitmproxy, mitmproxy actualizó esa dependencia en marzo, pero todavía no ha sacado una versión estable que incluya esa actualización. Del lado de IBM están preguntando: “¿cuándo planean poner una etiqueta de lanzamiento y si hay un calendario que podamos comunicar a los clientes?”
En particular, no están preguntando “¿cuándo lo van a arreglar?”. Ya no hay nada que arreglar; más bien están preguntando algo como “¿cuándo planean hacer un nuevo release que incluya esta actualización de dependencia?”.
No me parece que esa pregunta en sí sea injustificada. Claro, si quieren que este tipo de cambio se distribuya dentro de un plazo específico, tampoco es injusto pedir un contrato de soporte, pero responder de inmediato “consulten por correo sobre un contrato de soporte” sí se ve un poco excesivo.
Maximilian no tiene obligación de dar un calendario de releases a alguien que no paga, y si IBM de verdad necesita una hoja de ruta, tampoco tiene nada de raro sugerirles que paguen. Si para IBM fuera tan importante, incluso podrían hacer hoy mismo su propio release interno de mitmproxy.
Dije “consulten por correo sobre un contrato de soporte” porque 1) ya había explicado en ese hilo que no iba a sacar un patch release por este tema y 2) la otra parte había enfatizado el impacto que esto tenía en sus clientes de pago.
Así que realmente eso era lo único que quedaba por decir ahí. Estoy de acuerdo en que pude haberlo expresado mejor, pero no siento que mi respuesta haya sido totalmente desmedida.
El CVE en sí también es una tontería, y nosotros no usamos esa parte de la dependencia.
Mientras quien hace la solicitud obtiene un beneficio del trabajo gratuito, ¿por qué el mantenedor tendría que trabajar gratis?
Lo injustificado es la actitud de superioridad de FrugalGuy. Hay que ser un hipócrita bastante especial para exigirle a un mantenedor de código abierto que trabaje gratis y luego acusarlo de extorsión. No se puede imponer exigencias a voluntarios que llevan un proyecto libre y de código abierto en su tiempo parcial.
Soy el OP. Para dejarlo claro, la pregunta sobre el release en sí no tiene absolutamente nada de malo y es válida.
Pero el contexto debería ser “nos importa esto, ¿cómo podemos ayudar a que pase?”, ya sea con contribuciones o con dinero. No debería ser “por tu culpa esto le causa problemas a nuestros clientes”.
No es que quiera que quien hizo la solicitud quede mal por una mala elección de palabras, sino que me gustaría que las grandes empresas tuvieran una relación sana con el software libre y de código abierto.
El simple hecho de haber ofrecido ese contrato ya fue bastante amable. FrugalGuy también podría haber recibido una respuesta tipo “manda un pull request”, y no sé si eso le habría gustado.
Pero si el problema es que no hay un release para un arreglo ya hecho, no tengo claro cómo se solucionaría eso con contribuciones o dinero.
Esto suena al típico idiota de seguridad informática que ni siquiera sabe qué es lo que está “corrigiendo”. Si un sistema automatizado le avisa que hay un CVE, asume que hay que “parcharlo” sí o sí
No revisa qué afirma realmente el CVE ni si su caso de uso concreto es vulnerable. No lo sabe, no le importa y no es programador. Solo sabe que tiene que quitar una casilla de verificación
Pasó algo parecido con h2database. Un “investigador de seguridad” descubrió que si haces algo que te dicen explícitamente que no hagas, pueden pasar cosas malas, y aun así pidió un CVE y se lo dieron. Si lo miras de cerca, es una tontería, pero para esta gente lo único importante es que exista un CVE
Lo que dijo el desarrollador de h2database: https://github.com/h2database/h2database/issues/3686#issueco...
“Me cuesta entender por qué debería sentir la más mínima simpatía por una ‘gran empresa’ que usa un proyecto open source desarrollado por voluntarios. Que contraten a alguien con dinero de la empresa para resolverlo, o que paguen por una biblioteca comercial similar”
Incluso si tienen autoridad para conceder excepciones en situaciones concretas, puede que necesiten llenar más documentación para justificar esa decisión. Esa documentación extra los retrasa y les juega en contra en sus métricas de desempeño
“Si pasas una contraseña por la línea de comandos, otros procesos del sistema pueden verla con
ps”Pues claro. Si eso es un CVE de “alta gravedad”, entonces yo también puedo llamarme investigador de seguridad. Se me ocurren al menos media docena de aplicaciones que permiten exactamente lo mismo mientras te advierten “no hagas esto”
El equipo de seguridad informática reporta una vulnerabilidad que apareció en un informe, y el gerente entra en pánico
Los desarrolladores tienen que seguir actualizando. Incluso dependencias que no son de producción. Se pueden pedir excepciones, pero eso ya es otro dolor de cabeza completamente aparte
Y luego el gerente se pregunta por qué se ralentizó el trabajo de desarrollo
Incluso dudo que alguien revise de verdad el resto de las respuestas
En uno de mis proyectos también hubo un momento en que de repente empezaron a llegar muchos comentarios de “¿cuándo lo van a arreglar?”, “yo también estoy afectado y esto es importante”. Ese interés tan repentino fue bastante raro
Pero por una época parecida recibí un correo de disculpa diciendo que el jefe de cierta empresa había instruido a sus empleados para que me presionaran fingiendo que mucha más gente estaba afectada de lo que realmente era
Parece que alguien aprendió en su trabajo que un tono agresivo o amenazante es muy efectivo, pero no entendió que aquí la posición de negociación es totalmente distinta
Hay una diferencia sutil entre “necesito saber cuándo estará listo para poder planificar” y “yo gano dinero con tu trabajo, así que tienes que hacer esto, apúrate”
Si quien lo pidió hubiera preguntado sin omitir el contexto, el tono habría estado más cerca de lo primero y menos de lo segundo
Si esa razón también parece importante para muchos otros usuarios, eso puede ayudar al mantenedor a decidir si conviene priorizar una función o una corrección de bug. Si hay una solución alternativa, también puede ayudar a encontrarla
Llamarlo extorsión al desarrollador fue injusto, pero no creo que hubiera nada malo en el primer mensaje en sí
La sensación de derecho de las empresas que usan software de código abierto y aun así exigen soporte es enorme. Ojalá se usaran más licencias con restricciones de uso, y ojalá la OSI no se limitara a decir “¡eso no es open source!!!”
Ese tipo de licencias podría evitar situaciones como esta.
En cualquier caso, está bien que la OSI y la FSF mantengan una postura firme aquí. Si tus prioridades no coinciden con las de ellos, ¿por qué tendrían que cambiar para complacerte?
Simplemente usa la licencia que te guste, aunque ellos no la aprueben. No veo por qué eso sería un problema. Si desde el principio no compartes sus valores, ¿por qué esas organizaciones tendrían que ponerle su sello de aprobación a tu elección de licencia?
Para los patrocinadores corporativos, no apoyar restricciones de uso no es un defecto, sino una característica.
También hay muchísimo dogmatismo alrededor de las definiciones de open source y software libre. Si no te ajustas a esas definiciones, es fácil que se te echen encima, y esas definiciones muchas veces se tratan como si fueran la Biblia. Sus defensores ni siquiera quieren aceptar la posibilidad de que tal vez haya que ajustarlas a la realidad de 2023.
Aunque intentes crear términos nuevos para evitar el conflicto, los defensores del open source y del software libre insisten en imponer su propio lenguaje y controlar la narrativa. Ese lenguaje está diseñado para tener connotaciones negativas dentro de su marco.
La libertad del usuario para ejecutar el software con cualquier propósito es la libertad 0, y Stallman explica de forma muy convincente por qué las restricciones de uso no ayudan: https://www.gnu.org/philosophy/programs-must-not-limit-freed...
Igual que las cláusulas de exención de garantía, el software libre se entrega sin condiciones. Es de mala educación que, después de recibir incluso la libertad de modificarlo como quieras, todavía exijas soporte y mantenimiento gratuitos. No creo que cambiar la licencia haga desaparecer a ese tipo de gente grosera.
Y puede haber opciones más amigables con el open source que con las empresas sin pasar por la licencia. Por ejemplo, exigir que quien reporte un problema importante publique también código para reproducirlo.
Incluso en los 80, cuando el soporte solía darse gratis, escuché muchas historias de empresas haciendo eso con software pirateado. Lo único que redujo esas prácticas fueron los contratos de soporte pagado.
La respuesta realista sería demandar por violación de licencia, pero no hay muchos desarrolladores de open source que tengan los medios para hacerlo contra medianas empresas, mucho menos contra grandes corporaciones.
El comportamiento de “FrugalGuy” fue inmaduro e infantil, pero el mantenedor de mitmproxy podría haber respondido mejor: de forma cortés pero firme, sin dejar espacio para malentendidos ni drama.
“De acuerdo con la licencia de mitmproxy, este software se proporciona tal cual y sin garantía, y los mantenedores del proyecto están actualmente comprometidos con otras prioridades y entregables.”
“Por lo tanto, lo declarado en el issue tracker de Github no basta para justificar una priorización del problema. La única forma de elevar la prioridad es contratar un acuerdo de soporte, disponible [here]. Con gusto podemos discutir más a fondo las condiciones.”
El equivalente al salario anual de un ingeniero, para algunas empresas, no es nada, y parece que la corrección podría hacerse en unas pocas semanas; eso sería lo justo.
O, si de verdad no quieren pagar, pueden asignar durante unos meses a un ingeniero de su empresa para parchear lo que necesita un cliente de pago y contribuirlo upstream.
Corrección: lo de la compensación anual de un ingeniero es solo una estimación mía, limitada e imprecisa. No estoy en posición de decir cuánto vale exactamente, pero supongo que para un ingeniero no familiarizado con la base de código probablemente serían necesarios unos meses de esfuerzo.
Solo que hacerlo podría generar otros problemas de compliance, y supongo que por eso no lo hicieron. Claro, ese no es problema del proyecto open source.
https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...
Preguntar simplemente “¿hay una fecha objetivo para la próxima release?” no tiene nada de malo, porque no es una exigencia.
La frase “estamos intentando construir una lógica interna para esperar, y necesitamos alguna fecha objetivo” se entiende más como que otras personas le exigen eso a él, no como una exigencia dirigida a los desarrolladores de mitmproxy.
En este comentario está haciendo una solicitud y explicando la motivación comercial y personal de esa solicitud. No había problema hasta que volvió por correo hablando de palabras como extorsión.
El post original incluía tanto el contexto como el empleador. Difundir el issue real de GitHub, que claramente el autor original intentó evitar a propósito, también es una conducta bastante mala.
FrugalGuy, me quedé sin palabras.