"Nossos clientes pagantes precisam disso no X; quando vocês vão corrigir?"

 (twitter.com/maximilianhils)
2 pontos por GN⁺ 2023-07-16 | 1 comentários | Compartilhar no WhatsApp
  • Um usuário corporativo com clientes de setores regulados, como bancos e órgãos federais, cobrou em uma issue pública o cronograma da próxima release da ferramenta open source mitmproxy, pressionando ao dizer que, por causa de vulnerabilidades conhecidas de severidade High e Critical, seus próprios clientes não poderiam usar o software
  • A vulnerabilidade em questão existe em uma parte de uma biblioteca que o mitmproxy não usa, então na prática não há impacto para os usuários reais
  • O mantenedor não recusou o pedido; em vez disso, respondeu que, se fosse necessária uma patch release em tempo hábil, poderiam firmar um contrato de suporte pago (support contract), indicando o e-mail em seu perfil
  • O usuário corporativo interpretou essa resposta como uma "piada ou uma tentativa de extorsão sutilmente disfarçada" e enviou um e-mail de protesto
  • O ponto central é que perguntar sobre o cronograma de release é legítimo, mas isso exige uma postura colaborativa do tipo "como podemos ajudar com contribuição ou financiamento?"; o autor original do comentário depois enviou um pedido de desculpas sincero

Contexto do caso

  • Segundo a explicação de contexto anexada, existe uma vulnerabilidade em uma biblioteca distribuída junto com o mitmproxy, mas ela está em uma parte que o mitmproxy não usa, então não afeta os usuários reais
  • Depois que o caso viralizou (went viral) externamente, esse contexto adicional foi explicado

Exigência inicial do usuário corporativo (issue no GitHub)

  • Há 16 horas, um usuário mencionou outro membro do projeto, @Prinzhorn, e perguntou pela data-alvo da próxima release (target date)
  • Ele explicou que clientes de setores regulados (regulated industries), como bancos e órgãos federais, são proibidos por norma de usar software com vulnerabilidades conhecidas de severidade High ou Critical
    • Disse que queriam definir a posição da empresa sobre esperar (waiting), mas que precisavam de algum tipo de data-alvo

Resposta do mantenedor mhils

  • O membro mhils respondeu há 15 horas dizendo que, se houvesse interesse em uma patch release em tempo hábil para atender aos requisitos de compliance da empresa, estaria disposto a estabelecer um contrato de suporte
  • Informou que os dados de contato estão no e-mail do perfil (incluindo a marcação ":-)")

E-mail de protesto ("Concerning response")

  • Depois, um e-mail com o assunto "Concerning response" foi enviado de um endereço no domínio us.ibm.com para github@hi.ls (com a marcação Jul 14, 2023)
  • Começando com "Mr. Hils", a mensagem afirma que a intenção era explicar melhor o pedido de data-alvo para obter uma resposta direta, em vez de agravar a situação ou poluir o rastreador de issues do GitHub com palavras desnecessárias
    • Também diz esperar que esse e-mail de acompanhamento não seja recebido de forma ofensiva e deixa claro que essa não era a intenção
  • Na parte destacada, o autor escreve que supõe que a resposta do mantenedor não foi uma resposta oficial do projeto, mas uma piada, ou pior, uma tentativa de extorsão sutilmente disfarçada (thinly veiled extortion attempt) (a frase é interrompida em seguida, quando ele diz que estava revisando a documentação oficial do projeto)

Posição do mantenedor

  • Ele deixa claro que a resposta não era uma piada
  • Diz que abordar um projeto open source com algo como "nossos clientes pagantes precisam de X; quando vocês vão corrigir isso?" talvez não seja a melhor forma de se apresentar
  • Reconhece que perguntar sobre o cronograma de release não o incomoda e que é uma pergunta válida (valid)
    • Mas o essencial é que o contexto deveria ser "temos interesse nisso; como podemos ajudar a fazer acontecer?" (com contribuição ou financiamento), e não "vocês estão causando um problema para os nossos clientes"

Encerramento

  • O autor original do comentário enviou um pedido de desculpas sincero (genuine apology), e o mantenedor disse apreciá-lo genuinamente
  • Ele pede que todos presumam boas intenções (assume good intentions) e tratem os outros com gentileza

Leituras relacionadas

1 comentários

 
GN⁺ 2023-07-16
Comentários no Hacker News

  • Lendo esta issue https://github.com/mitmproxy/mitmproxy/issues/6051, o pedido da IBM parece muito mais razoável do que no tweet
    O problema é que há um CVE em uma dependência do mitmproxy, e o mitmproxy atualizou a dependência em março, mas ainda não lançou uma release estável com essa atualização. O pessoal da IBM está perguntando “quando vocês pretendem criar a tag de release, há algum cronograma que possamos repassar aos clientes?”
    Em especial, eles não estão perguntando “quando vocês vão corrigir isso?”. Não há mais nada a corrigir; a pergunta é mais próxima de “quando vocês planejam fazer uma nova release com essa atualização de dependência?”
    Não acho essa pergunta, por si só, injusta. Claro, se querem que esse tipo de correção seja distribuído dentro de um prazo específico, também não é injusto exigir um contrato de suporte, mas responder de imediato com “consulte por e-mail sobre contratos de suporte” parece um pouco exagerado

    • A primeira pergunta foi educada e razoável, e a resposta de @mhils também foi. O que não foi nada razoável foi a parte do e-mail de acompanhamento da IBM que classificou isso como “uma tentativa de extorsão mal disfarçada”
      Maximilian não tem obrigação de fornecer cronogramas de release para quem não paga, e, se a IBM realmente precisa de um cronograma, também não há nada de estranho em sugerir que paguem por isso. Se isso fosse tão importante para a IBM, eles poderiam até criar hoje mesmo uma release interna do mitmproxy
    • Perguntar a data de release é um pedido totalmente razoável. Mas a minha resposta foi muito influenciada pelo contexto
      O motivo de eu ter dito “consulte por e-mail sobre contratos de suporte” foi que 1) eu já tinha deixado claro naquela thread que não faria uma patch release por causa disso e 2) o outro lado enfatizou o impacto que isso teria sobre os clientes pagantes deles
      Então, naquele ponto, era só isso que eu tinha a dizer. Concordo que eu poderia ter me expressado melhor, mas não sinto que minha resposta tenha sido totalmente exagerada
      O próprio CVE também é furado, e nós nem usamos essa parte da dependência
    • Essa parte é bem clara. O problema é o uso da expressão “extorsão mal disfarçada” na comunicação posterior, e isso está muito longe de ser razoável
    • Como o mantenedor explicou, esse CVE não afeta o mitmproxy na prática. No fim, isso só serve para ajudar alguém da segurança a desmarcar uma caixinha no checklist
      Por que o mantenedor deveria trabalhar de graça enquanto o solicitante obtém benefício com trabalho gratuito?
      O que é indevido é a atitude presunçosa do FrugalGuy. É preciso um nível bem especial de hipocrisia para exigir que mantenedores de código aberto trabalhem de graça e depois acusá-los de extorsão. Não dá para impor exigências a voluntários que tocam projetos de software livre e de código aberto no tempo livre
    • Mesmo assim, isso não muda o tom ameaçador usado no e-mail ao mantenedor

  • Sou o OP. Para deixar claro, a pergunta sobre a release em si não tem problema nenhum e é válida
    Mas o contexto deveria ser “temos interesse nisso; como podemos ajudar a fazer acontecer?”, seja com contribuição ou com dinheiro. Não deveria ser “por sua causa estamos tendo problemas com nossos clientes”
    Não quero que quem fez o pedido seja miserável por ter escolhido mal as palavras; só quero que grandes empresas tenham uma relação saudável com software livre e de código aberto

    • Se fosse meu projeto, acho que eu não teria oferecido um contrato de suporte. Questões trabalhistas e tributárias seriam complexas demais para mim
      O simples fato de ele ter oferecido esse contrato já foi, na verdade, algo bem gentil. O FrugalGuy poderia ter recebido como resposta “mande um pull request”, e não sei se ele teria gostado disso
    • Tirando as emoções e as pessoas da equação, fico curioso sobre o que exatamente impede o mitmproxy, como projeto de software, de lançar uma nova versão agora mesmo
    • Depois de ler isso, quis apagar meu comentário no GitHub, mas a thread estava bloqueada, então não consegui
    • Ainda não entendo como contribuição ou dinheiro resolveriam um problema de release. Se fosse um bug, daria para corrigir e enviar um patch
      Mas se o problema é a ausência de uma release para uma correção que já foi feita, não entendo bem como contribuição ou dinheiro resolveriam isso
    • Ainda assim, foi uma tentativa de extorsão

  • Isso soa como o típico caso de idiotas de segurança da informação que nem sabem o que exatamente estão “corrigindo”. O sistema automatizado avisa que existe um CVE, então eles acham que precisam “aplicar patch” de qualquer jeito
    Não verificam o que o CVE realmente alega, nem se o uso específico que eles fazem é vulnerável. Não sabem, não se importam, e não são programadores. Só sabem que precisam apagar uma caixa de seleção
    Houve algo parecido no h2database. Um “pesquisador de segurança” descobriu que, se você fizer algo que já foi dito para não fazer, acontece algo ruim; mesmo assim exigiu um CVE e conseguiu. Se você olhar de perto, vê que é bobagem, mas para esse tipo de gente o importante é apenas o fato de existir um CVE
    O que o desenvolvedor do h2database disse: https://github.com/h2database/h2database/issues/3686#issueco...
    “É difícil entender por que eu deveria ter o mínimo de simpatia por uma ‘grande empresa’ que usa um projeto open source desenvolvido por voluntários. Contratem alguém com o dinheiro da empresa para resolver isso, ou paguem por uma biblioteca comercial parecida”

    • Eles também podem saber e entender tudo isso e ainda assim não se importar. Talvez o desempenho deles seja medido pela rapidez com que apagam caixas de seleção, e exagerar na aprovação possa ser mais prejudicial do que exagerar na recusa
      Mesmo que tenham autoridade para conceder exceções em situações específicas, talvez precisem preencher mais documentação para justificar essa decisão. Essa papelada extra reduz a velocidade e pesa contra eles nas métricas de desempenho
    • Nossa, esse CVE é ridículo
      “Se você passar a senha pela linha de comando, outros processos do sistema podem vê-la com ps”
      Isso é óbvio. Se isso é um CVE de “alta gravidade”, então eu também posso me chamar de pesquisador de segurança. Consigo pensar em pelo menos meia dúzia de aplicações que permitem exatamente a mesma coisa e só colocam um aviso dizendo “não faça isso”
    • Concordo totalmente. Trabalho em um setor regulado, e o fluxo é assim
      A equipe de segurança da informação levanta a vulnerabilidade que apareceu no relatório, e o gerente entra em pânico
      O desenvolvedor tem que continuar atualizando tudo. Até dependências que nem são de produção. Dá para pedir exceção, mas isso é uma dor de cabeça completamente separada
      Aí depois o gerente quer saber por que o trabalho de desenvolvimento ficou mais lento
    • Trabalho em um fornecedor SaaS em um setor onde SaaS ainda é visto como algo meio “exótico”. Recebemos questionários de segurança absurdos, e 90% das respostas são “não se aplica”
      E ainda duvido que alguém realmente revise o restante das respostas

  • Em um dos meus projetos também houve um aumento repentino de comentários do tipo “quando isso vai ser corrigido?”, “eu também sou afetado e isso é importante”. Esse interesse repentino foi bem estranho
    Mas, por coincidência, mais ou menos na mesma época recebi um e-mail de desculpas dizendo que o chefe de uma empresa mandou os funcionários me pressionarem fingindo que muito mais gente era afetada do que realmente era

    • A melhor resposta é: “minha taxa é $XYZ por hora, e aceito dinheiro ou cheque”

  • Parece que alguém aprendeu no próprio trabalho que um tom agressivo ou ameaçador é muito eficaz, mas não entendeu que a posição de negociação aqui é completamente diferente

    • Se você fizer isso por 27 anos, acaba sendo promovido a Program Manager Secure Engineering and Incident Response da IBM

  • Existe uma diferença sutil entre “preciso saber quando isso vai acontecer para poder me planejar” e “estou ganhando dinheiro com o seu trabalho, então você tem que fazer isso, por favor acelere”
    Se quem fez o pedido tivesse perguntado sem esse pano de fundo, teria soado mais como a primeira opção e menos como a segunda

    • Não concordo que esse tenha sido o jeito certo de lidar com isso. Em um projeto open source, não há problema nenhum em explicar por que algo é útil
      Se esse motivo parecer importante também para muitos outros usuários, isso pode ajudar o mantenedor a decidir se vale acelerar uma funcionalidade ou correção de bug. Se houver uma solução alternativa, isso também pode ajudar a encontrá-la
      Foi injusto chamar isso de extorsão de desenvolvedor, mas eu não acho que houvesse problema na primeira mensagem em si

  • A sensação de direito das empresas que usam software de código aberto e ainda exigem suporte é enorme. Eu gostaria que licenças com restrições de uso fossem mais amplamente utilizadas, e que a OSI não ficasse apenas dizendo “isso não é open source!!!”
    Essas licenças poderiam evitar situações como essa

    • A GNU AGPLv3 irrita tanto os advogados corporativos que, na prática, pode acabar funcionando como uma licença não comercial. Mas, na realidade, não é uma licença não comercial e atende tanto aos critérios da OSI quanto da FSF
      De todo modo, acho bom que a OSI e a FSF mantenham uma postura dura aqui. Se suas prioridades não se alinham com as delas, por que elas deveriam mudar para satisfazer você?
      Basta usar a licença de que você gosta, mesmo que elas não a aprovem. Não vejo por que isso seria um problema. Se você nem compartilha os valores delas, por que essas organizações deveriam carimbar sua escolha de licença com aprovação?
    • Concordo, mas basta ver quem paga as contas da OSI: https://opensource.org/sponsors/
      Para patrocinadores corporativos, não apoiar restrições de uso não é um defeito, é uma funcionalidade
      Também existe um enorme dogmatismo em torno das definições de open source e software livre. Se algo não segue essas definições, é fácil atrair uma multidão para atacar, e essas definições muitas vezes são tratadas como se fossem a Bíblia. Os defensores sequer aceitam a possibilidade de que talvez precisem de ajustes para a realidade de 2023
      Mesmo quando se tenta criar novos termos para evitar conflito, defensores de open source e software livre insistem na própria linguagem e tentam controlar a narrativa. Essa linguagem foi concebida para carregar conotações negativas dentro do universo deles
    • Eu não gostaria que restrições de uso se tornassem mais comuns. Não, se por “restrições de uso” você quer dizer algo fora do espectro de copyleft em diferentes níveis de força oferecido por LGPL, GPL e AGPL
      A liberdade do usuário de executar o software para qualquer propósito é a liberdade 0, e Stallman explica de forma muito convincente por que restrições de uso não ajudam: https://www.gnu.org/philosophy/programs-must-not-limit-freed...
      Assim como cláusulas de isenção de garantia, software livre é dado sem condições. Receber de presente até a liberdade de modificar como quiser e ainda exigir suporte e manutenção gratuitos é falta de educação. Não acho que mudar a licença vá fazer esse tipo de gente rude desaparecer
    • Acho que a maioria não quer ser tão antiempresa assim. Se quisesse, não teria escolhido uma licença permissiva para começar
      E talvez existam alternativas mais favoráveis ao open source do que às empresas que não passam por licença. Por exemplo, exigir que alguém publique código de reprodução para relatar um problema importante
    • Não vejo bem como isso resolveria o problema. Esse software provavelmente ainda seria usado em ambientes de negócios, e ainda haveria gente pedindo suporte em nome do empregador
      Já ouvi muitas histórias de que, nos anos 80, quando suporte normalmente era oferecido de graça, empresas faziam esse tipo de coisa com software pirateado. A única coisa que reduziu esse tipo de palhaçada foram contratos de suporte pagos
      A resposta realista é processar por violação de licença, mas não há muitos desenvolvedores de open source com meios para fazer isso contra grandes empresas, ou até mesmo empresas de porte médio

  • O comportamento de “FrugalGuy” é imaturo e infantil, mas o mantenedor do mitmproxy poderia ter respondido de forma melhor, sendo educado e firme, sem margem para mal-entendidos ou drama
    “De acordo com a licença do mitmproxy, este software é fornecido no estado em que se encontra, sem garantia, e os mantenedores do projeto estão atualmente comprometidos com outras prioridades e entregas”
    “Portanto, apenas a declaração no rastreador de issues do GitHub não é suficiente para justificar a priorização deste issue. A única forma de elevar a prioridade do issue é firmando um contrato de suporte, disponível [here]. Terei prazer em discutir os termos em mais detalhes”

    • Não me parece essencialmente muito diferente da resposta real. Aliás, soa um pouco mais rude, embora eu nem saiba se essa era a intenção. Então não vejo bem o que isso acrescenta em relação à resposta real
    • Achei que a resposta real também foi educada e firme
    • Não. Essa resposta também é tão estranha quanto a pessoa original. Se você faz um pedido sem noção do clima, não tem direito de receber uma resposta educada

  • O equivalente ao salário anual de um engenheiro, para algumas empresas, é troco, e parece que a correção poderia ser feita em poucas semanas, o que seria justo
    Ou, se realmente não quiserem pagar, basta alocar um engenheiro da própria empresa por alguns meses para corrigir o que o cliente pagante precisa e contribuir isso de volta para o upstream
    Correção: o valor de uma remuneração anual de engenheiro foi apenas minha estimativa limitada e imprecisa. Não estou em posição de dizer exatamente quanto vale, mas suponho que um engenheiro sem familiaridade com a base de código provavelmente levaria alguns meses de esforço

    • Pelo que parece, bastaria compilar um release mais novo. A correção já existe
      Só que isso pode gerar outros problemas de compliance, e provavelmente foi por isso que não fizeram isso. Claro, esse não é um problema do projeto open source

  • https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...

    • O e-mail de acompanhamento citado pelo OP realmente passou de todos os limites, mas esse post no GitHub em si não me parece algo condenável. A resposta de “pague” também não teve problema
      Simplesmente perguntar “há uma data-alvo para o próximo release?” não é um problema. Não é uma exigência
      Na frase “estamos tentando construir uma lógica interna para esperar, mas precisamos de alguma data-alvo”, esse “precisamos” parece se referir não a uma exigência dirigida aos desenvolvedores do mitmproxy, mas a algo que outras pessoas estão exigindo dele
      Nesse comentário, ele está fazendo um pedido e explicando a motivação comercial e pessoal por trás dele. Não havia problema até ele voltar por e-mail usando palavras como extorsão
    • Essa pessoa específica importa?
      O post original incluía tanto o contexto quanto o empregador. É claro que o autor tentou deliberadamente evitar isso, então espalhar o issue real do GitHub também é uma atitude bem ruim
    • FrugalGuy... estou sem palavras