![Os prós e contras de usar o React hoje](https://optimuscloud.com.br/wp-content/uploads/2024/01/1706208466_Os-pros-e-contras-de-usar-o-React-hoje-150x150.jpg)
Os prós e contras de usar o React hoje
25 de janeiro de 2024![Mudanças incrementais do ScyllaDB: apenas a ponta do iceberg](https://optimuscloud.com.br/wp-content/uploads/2024/01/1706209443_Mudancas-incrementais-do-ScyllaDB-apenas-a-ponta-do-iceberg-150x150.jpg)
Mudanças incrementais do ScyllaDB: apenas a ponta do iceberg
25 de janeiro de 2024No início deste ano, a Python Software Foundation contratou o programador Python Seth Larson para uma nova função de desenvolvedor residente de segurança, financiado pela própria organização sem fins lucrativos da Linux Foundation, a Open Software Security Foundation.
“Sou um defensor apaixonado da sustentabilidade na manutenção de código aberto”, disse Larson em entrevista por e-mail, então “tem sido um sonho para mim viver o que acredito ser o modelo ideal para segurança sustentável de código aberto”.
O financiamento da posição veio do Projeto Alpha-Omega da OSSF, que “faz parceria com mantenedores de projetos de software de código aberto para encontrar sistematicamente vulnerabilidades novas e ainda não descobertas em código-fonte aberto”, de acordo com seu site, “e consertá-las para melhorar a segurança da cadeia de fornecimento de software global.”
Larson é apenas um dos vários desenvolvedores em tempo integral contratados recentemente para ajudar o ecossistema Python. Desde julho de 2021, também existe um desenvolvedor residente – que em breve será aumentado por um novo deputado desenvolvedor residente. Então, em agosto, a fundação adicionou seu primeiro engenheiro de segurança e proteção em tempo integral para PyPI, o repositório oficial onde quase 500.000 projetos Python contribuídos por usuários estão disponíveis para instalação.
Ao procurar um novo desenvolvedor de segurança, o envolvimento de longo prazo de Larson foi definitivamente uma vantagem. Além de contribuir para muitos projetos de código aberto, o site de Larson observa que ele é o principal mantenedor da biblioteca cliente HTTP urllib3, “o pacote mais baixado no Python Package Index, com mais de 10 bilhões de downloads”.
Mas Larson também vê potencial para um impacto muito maior: demonstrar a eficácia dos investimentos em comunidades críticas para melhorar a sua postura de segurança — e, assim, fortalecer toda a cadeia de fornecimento de software.
“Os ecossistemas de software têm muito que podemos aprender uns com os outros, por isso tenho documentado tudo o que aprendi — para que possa ser usado por outras pessoas que queiram replicar meu trabalho em seu próprio ecossistema!”
Diagramando ameaças
Larson diz que começou analisando do início ao fim todo o processo de lançamento do Python. Especificamente, ele criou um diagrama de cada estágio, “e então combinou esse diagrama com ameaças comuns à cadeia de suprimentos para software de código aberto.
“Esse processo me deu boas ideias sobre onde começar para garantir o processo de liberação.” (Entre outras coisas, Larson agora está trabalhando com gerentes de lançamento – e com o desenvolvedor residente Łukasz Langa – para melhorar as compilações do macOS e do Windows.) Em uma palestra recente, Larson disse que está explorando a automação de redução de carga de trabalho como o Azure Pipelines, que poderia também reforçou a segurança. “A injeção de malware durante o tempo de construção aconteceu em vários outros projetos de código aberto com resultados desastrosos para os usuários”.
Uma postagem no blog também compartilha detalhes da auditoria de julho das assinaturas usadas nas versões do Python. Larson queria garantir que os usuários finais vissem uma assinatura consistente com a documentação, então “juntei alguns scripts simples que baixei e tentei verificar cada artefato de lançamento do Python em relação às suas assinaturas e publiquei os resultados”. Então, após a auditoria de assinaturas, Larson “trabalhou com gerentes de lançamento para corrigir discrepâncias que encontrei”, ajudou a padronizar assinaturas para versões mais antigas e até adicionou controles às ferramentas de lançamento do Python “que evitam que algo ruim aconteça com as assinaturas – qualquer coisa confusa – antes eles são publicados.”
Logo Larson foi convidado a se juntar à equipe de resposta de segurança do Python, onde tem ajudado a coordenar correções de bugs (para que os desenvolvedores voluntários do Python não precisem monitorar continuamente os relatórios recebidos, caso alguém precise de sua resposta).
Larson também escreve em seu relatório do terceiro trimestre sobre como adicionar um pouco de automação, “movendo o processo de geração de relatórios e triagem para o GitHub usando os avisos de segurança do GitHub”. Mas uma coisa que ele aprendeu durante esse processo foi como os números CVE eram atribuídos a vulnerabilidades recém-descobertas.
Os problemas são principalmente designados pela Divisão Nacional de Segurança Cibernética do Departamento de Segurança Interna da América. E, surpreendentemente, foi realmente possível obter um número CVE para uma vulnerabilidade do Python sem realmente falar com ninguém associado ao projeto Python!
Larson disse que isso criou uma situação que “fez com que relatórios que não eram vulnerabilidades de segurança fossem aceitos como CVEs” (o que, é claro, “causou confusão para os usuários”). Seria melhor – e mais rápido – se os principais desenvolvedores do Python poderiam simplesmente adicionar suas dicas de correção (juntamente com atualizações e outras informações) diretamente no CVE.
Larson começou a trabalhar e, em agosto, a Python Software Foundation foi autorizada como autoridade de numeração CVE (tanto para a linguagem de programação Python quanto para o instalador de pacotes Python). Larson diz que dividirá funções primárias com Ee Durbin, diretor de infraestrutura do PSF, e Chloe Gerhardson, uma de suas engenheiras de infraestrutura.
Entre outros benefícios, a autorização trouxe pago pessoal para operações CNA (“em vez de exigir tempo voluntário”), o que alivia a carga de trabalho dos mantenedores de Python (e PIP) que anteriormente tinham sido encarregados de publicar eles próprios avisos.
Uma postagem no blog do PSF acrescenta esperança de que isso leve a “avisos publicados e registros CVE mais ricos, incluindo descrições, metadados e informações de remediação”. (Os futuros CVEs serão revisados e aprovados pelas equipes de resposta de segurança responsáveis, com informações mais detalhadas provenientes diretamente do projeto Python.) “Desde que nos tornamos um CNA, revitalizamos a lista de discussão security-announce@python.org para alertar os usuários do Python quando foram encontradas novas vulnerabilidades no Python e no pip”, diz Larson.
E no final de agosto, Larson publicou “minha primeira divulgação de vulnerabilidade ponta a ponta para Python”, de acordo com a postagem do blog daquela semana, que incluía “um lançamento coordenado de versões corrigidas do Python e a publicação do comunicado ao anúncio de segurança Lista de discussão @python.org e ao banco de dados consultivo PSF…
“Agora que experimentei o fluxo de ponta a ponta e posso começar a pensar sobre onde há potencial para melhorias e quais itens precisam estar em nossa ‘lista de verificação’ para reduzir o estresse e as suposições dos desenvolvedores de remediação, gerentes de lançamento e coordenadores.”
Ajudando outras comunidades
Mas tudo isso pode ser apenas o começo. “O PSF quer ajudar outras organizações de código aberto”, explicou Larson em uma postagem no blog de agosto, “e compartilhará lições aprendidas e desenvolverá orientações sobre como se tornar um CNA e nas operações diárias”. Larson diz que já está se comunicando com o programa Curl sobre sua experiência como CNA – para ajudá-los a dar o mesmo passo. E para compartilhar ainda mais a experiência, “escrevi um guia para se tornar um CNA como um projeto de código aberto no grupo de trabalho de divulgação de vulnerabilidades do OpenSSF”.
Em outro lugar, outra postagem no blog observa que o governo dos EUA “está solicitando ideias da comunidade mais ampla sobre onde focar e o que fazer para melhorar a segurança do software de código aberto”. (No início de novembro, Larson passou meses conversando com outros colegas e estava lutando para cumprir o prazo para envio de propostas.) “Tudo o que for feito pelo governo dos EUA provavelmente terá enormes implicações para todos que mantêm e consomem software de código aberto, por isso é fundamental que as políticas e decisões sejam tomadas tendo em mente a sustentabilidade”, escreveu Larson.
“Estou honrado por fazer parte disso e por representar tantos Pythonistas em meu trabalho, tanto para esta RFI quanto todos os dias como Desenvolvedor Residente de Segurança.”
Projetos futuros incluem um fortalecimento adicional do processo de lançamento do Python e “vários padrões de empacotamento funcionam” – onde também há um papel para a comunidade em geral. Em sua palestra, Larson disse que também estava entrando em contato com os autores de algumas propostas interessantes de aprimoramento do Python (ou PEPs) relacionadas à segurança.
Recomenda-se que os instaladores criem um registro no formato JSON mostrando a origem das distribuições Python e um hash de distribuição exclusivo. Na verdade, Larson criou uma ferramenta experimental para testá-lo, usando a implementação de referência do PEP para gerar documentos SBOM (nos formatos SPDX e CycloneDX) para o gerenciador de pacotes do Python.
E um dia Larson também espera criar seu próprio padrão para os metadados de projetos agrupados – que em alguns casos incluem até outros projetos não escritos em Python. (Na palestra, Larson observou que já encontrou e relatou duas que continham vulnerabilidades.)
Larson também está experimentando a criação de uma Lista de Materiais de Software (ou SBOM) confiável para projetos críticos como CPython e PIP – e então facilitando o uso dessas informações ao criar SBOMs para outros pacotes Python. No futuro, a esperança é capturar facilmente metadados automaticamente – e também obter as novas informações de embalagem apoiadas pela atual safra de ferramentas que geram SBOMs automaticamente.
Sustentabilidade, Clareza, Visibilidade
Na sua palestra em Setembro, Larson destacou os seus três “princípios orientadores”: sustentabilidade, clareza e visibilidade. “Sustentabilidade” significa focar em causar um impacto duradouro – de preferência, de maneiras que exijam manutenção mínima. “São coisas como melhorar processos, automação, lidar com a burocracia ou padrões de publicação.” E com uma cacofonia de novas ferramentas de segurança sendo lançadas, Larson se esforça para trazer clareza. “Uma grande parte da minha função é resumir tudo o que está acontecendo na área de segurança e, em seguida, formar parcerias com as pessoas certas em projetos para garantir que o valor seja alcançado.”
Mas a “visibilidade” assume a forma de publicações regulares em blogs e anúncios públicos, para dar à segurança o perfil mais elevado que ela merece. “Todos deveríamos estar orgulhosos e celebrar o trabalho que fizemos para manter a nossa comunidade segura… Parte da garantia do sucesso atual e futuro nesta área exige falar sobre o que está a ser feito e destacar onde há mais oportunidades.”
Então, como está funcionando? “Estou muito orgulhoso do que conquistei até agora”, escreveu Larson em uma postagem no blog em outubro, “e acho que isso mostra o valor de investir na segurança do código aberto por meio da contratação de pessoas para trabalhar em tempo integral em funções. ”
Larson diz que recebeu comentários agradecidos de mantenedores, aliviados por ele estar ajudando com a segurança, e “A resposta dos principais desenvolvedores e da comunidade em geral tem sido extremamente positiva”.
Larson ainda recebeu uma mensagem de agradecimento sobre o novo podcast core.py do desenvolvedor principal do Python Pablo Galindo Salgado e do desenvolvedor residente Lukasz Langa. E em nossa entrevista por e-mail, ele achou profundamente gratificante “fazer uma diferença positiva em uma comunidade que amo tanto…
“Minha experiência até agora tem sido incrível.”
A postagem O novo desenvolvedor de segurança do Python tem planos para proteger a linguagem apareceu pela primeira vez em The New Stack.