@drakenclimber Vou apresentar um esboço rápido de um documento MAINTAINER_PROCESS.md que podemos discutir / editar, mas ainda estou tentando finalizar a versão v2.4.0 agora e provavelmente precisarei de alguns dias para tende a algumas outras questões não relacionadas e negligenciadas :)

@pcmoore - Não se preocupe. A propósito, bom trabalho na versão v2.4! Deixe-me saber como posso ajudar.

Sinta-se à vontade para me usar como cobaia enquanto acertamos o processo :)

A propósito, bom trabalho na versão v2.4! Deixe-me saber como posso ajudar.

Qualquer teste que você possa fazer é útil neste ponto. Sinto-me muito bem com a qualidade deste lançamento, mas muitas das partes complicadas mudaram, portanto, não é irracional imaginar que algum gabinete quebrou em algum aplicativo. Tenho esperança de que não teremos que fazer uma versão "brown bag" v2.4.1, mas nunca se sabe.

Sinta-se à vontade para me usar como cobaia enquanto acertamos o processo :)

Fico feliz em ouvir você dizer isso porque você é a cobaia;)

@drakenclimber Estou reservando este comentário para um rascunho do documento MAINTAINER_PROCESS.md (acho que posso continuar editando-o aqui com base no feedback). Sinta-se à vontade para enviar qualquer ideia que você tenha sobre esta edição e eu prepararei um relatório para isso assim que tivermos algo próximo.

O processo de manutenção libseccomp

https://github.com/seccomp/libseccomp

Este documento tenta descrever os processos que devem ser seguidos pelos vários mantenedores da libseccomp. Não é pretendido como um requisito rígido, mas sim como um documento de orientação destinado a tornar mais fácil para vários co-mantenedores gerenciar o projeto libseccomp.

Reconhecemos que este documento, como todas as outras partes do projeto libseccomp, não é perfeito. Se houver necessidade de fazer alterações, elas devem ser feitas de acordo com as diretrizes descritas aqui.

Revisando e mesclando patches

Em um mundo perfeito, cada patch seria revisado de forma independente e verificado por cada mantenedor, mas reconhecemos que não é provável que seja prático para cada patch. Sob circunstâncias normais, cada patch deve ser aprovado por uma maioria simples de mantenedores (no caso de um número par de mantenedores, N / 2 + 1) antes de ser incorporado ao repositório. Os mantenedores devem ACK patches usando um formato semelhante ao kernel do Linux, por exemplo:

Acked-by: John Smith <[email protected]>

O mantenedor que fundiu o patch no repositório deve adicionar sua assinatura após garantir que é correto fazê-lo (consulte a documentação sobre como enviar patches); se não for correto para o mantenedor adicionar sua assinatura, é provável que o patch não deva ser mesclado. O mantenedor deve adicionar sua assinatura usando o formato padrão no final dos metadados do patch, por exemplo:

Signed-off-by: Jane Smith <[email protected])

Os mantenedores são encorajados a se comunicarem uns com os outros por várias razões, uma das quais é permitir que os outros fiquem inacessíveis por um longo período de tempo. Se um patch está sendo retido devido à falta de ACKs e os outros mantenedores não estão respondendo após um período de tempo razoável (por exemplo, um atraso de mais de duas semanas), desde que não haja NACKs pendentes, o patch pode ser mesclado sem maioria simples.

Gerenciando Relatórios de Vulnerabilidade Sensível

O processo de relatório de vulnerabilidade libseccomp está documentado no documento SECURITY.md.

Os mantenedores devem trabalhar junto com o relator para avaliar a validade e seriedade da vulnerabilidade relatada. Sempre que possível, práticas responsáveis ​​de relatórios e patches devem ser seguidas, incluindo notificação às listas de discussão _linux-distros_ e _oss-security_.

• https://oss-security.openwall.org/wiki/mailing-lists/distros

Gerenciando o rastreador de problemas do GitHub

Usamos o rastreador de problemas do GitHub para rastrear bugs, solicitações de recursos e, às vezes, perguntas sem resposta. As convenções aqui destinam-se a ajudar a distinguir entre os diferentes usos e priorizar dentro dessas categorias.

As solicitações de recursos DEVEM ter um prefixo "RFE:" adicionado ao nome do problema e usar o rótulo "aprimoramento". Os relatórios de bugs DEVEM ter um prefixo "BUG:" adicionado ao nome do problema e usar o rótulo "bug".

As questões DEVEM ser priorizadas usando os rótulos "prioridade / alta", "prioridade / média" e "prioridade / baixa". O significado deve ser óbvio.

Os problemas PODEM ser etiquetados adicionalmente com os rótulos "pendente / informação", "pendente / revisão" e "pendente / revisão" para indicar que são necessárias informações adicionais, o problema / patch está com revisão pendente e / ou o patch requer alterações.

Gerenciando os marcos de lançamento do GitHub

Deve haver pelo menos dois marcos do GitHub em qualquer momento: um para a próxima versão principal / secundária (por exemplo, v2.5) e um para a próxima versão de patch (por exemplo, v2.4.2). Conforme as questões são inseridas no sistema, elas podem ser adicionadas aos marcos a critério dos mantenedores.

Gerenciando a lista de mala direta pública

A lista de e-mails está atualmente hospedada nos Grupos do Google e, embora seja possível participar de discussões sem uma conta do Google, é necessária uma conta do Google para moderar / administrar o grupo. Os mantenedores que têm uma conta do Google e desejam ser adicionados à lista de moderadores devem ser adicionados, mas não há nenhum requisito para isso.

Apesar do termo "moderador", a lista atualmente não é moderada e deve permanecer assim.

Lançamentos de novos projetos

O processo de lançamento da libseccomp está documentado no documento RELEASE_PROCESS.md.

Idealmente, acho que seria bom receber um ACK de cada mantenedor em cada patch / PR, mas não tenho certeza se isso seria um obstáculo demais? Meu pressentimento é que os patches / PRs de libseccomp têm um volume baixo o suficiente para que isso não seja um grande problema, mas estou curioso para saber o que você acha

Concordou. Acho que buscar um ACK para cada patch seria bom, mas podemos deixar a flexibilidade aberta para contornar isso para patches realmente simples ou outras circunstâncias atenuantes (férias longas, etc.). Obviamente, ignorar os outros ACKs deve ser a exceção, não a norma.

Independentemente do acima, acho que os patches de qualquer mantenedor precisam ser ACK e confirmados por um mantenedor diferente.

Esse seria definitivamente um bom hábito para adquirir. Deve ajudar a evitar erros tolos.

Também precisamos documentar como lidar com a fusão de PRs e patches, por exemplo, aprovação do mantenedor, fazer isso manualmente e não usar as ferramentas do GitHub, etc.

Eu estaria interessado em ver o processo que você recomenda. Existe um motivo pelo qual devemos evitar as ferramentas integradas do github?

Acho que a chave aqui é listar todos os mantenedores na seção apropriada no README.md e mencionar que os mantenedores devem trabalhar juntos para resolver o problema e seguir os processos apropriados de divulgação responsável. Devemos incluir links para as listas linux-distros e oss-security.

Sim, fornecer um método fácil e seguro para que outras pessoas relatem problemas é fundamental. Eu concordo.

Concordou. Acho que buscar um ACK para cada patch seria bom, mas podemos deixar a flexibilidade aberta para contornar isso para patches realmente simples ou outras circunstâncias atenuantes (férias longas, etc.). Obviamente, ignorar os outros ACKs deve ser a exceção, não a norma.

Pontos positivos, eu concordo.

Também precisamos documentar como lidar com a fusão de PRs e patches, por exemplo, aprovação do mantenedor, fazer isso manualmente e não usar as ferramentas do GitHub, etc.

Eu estaria interessado em ver o processo que você recomenda. Existe um motivo pelo qual devemos evitar as ferramentas integradas do github?

Eu realmente gosto da ideia de que todos que tocam em um patch, seja por autoria ou por commit no repositório principal, adicionam explicitamente sua assinatura ao arquivo. Eu também realmente acho que os mantenedores deveriam fazer um make check em seu sistema local antes de enviar qualquer coisa para o repositório principal. Mesclar PRs diretamente de dentro da interface do GitHub não permite realmente fazer nenhuma dessas coisas.

Imagino que se o volume de RP aumentasse dramaticamente, poderíamos reconsiderar isso, mas agora o volume está baixo o suficiente para que as etapas manuais adicionais não sejam realmente significativas em minha opinião.

Opiniões @drakenclimber?

Acabei de verificar a lista de e-mails dos Grupos do Google e parece que não consigo usar sua conta / endereço do oracle.com como uma conta de administrador / moderador, deve ser uma conta do Google. Neste ponto, acho que depende de você @drakenclimber; se quiser acesso de gerente / moderador, você precisará se inscrever com uma conta do Google.

É importante notar que eu não modero a lista no momento, e não acho que ela deva ser moderada. No momento, as únicas postagens que não são enviadas imediatamente para a lista são coisas que o Google considera SPAM.

Também não vale a pena que o tráfego na lista de e-mails fora das notificações de confirmação esteja se aproximando de zero, a maior parte da interação acontece no GitHub agora. Embora eu ache que devemos manter a lista de e-mails por perto, por favor, não sinta que você precisa ser um gerente / moderador da lista para "dividir o fardo", não há "fardo" neste caso.

Imagino que se o volume de RP aumentasse dramaticamente, poderíamos reconsiderar isso, mas agora o volume está baixo o suficiente para que as etapas manuais adicionais não sejam realmente significativas em minha opinião. Opiniões @drakenclimber?

Concordou. Estou bem com uma etapa manual nesta fase do projeto. Na verdade, é exatamente isso que venho fazendo há algum tempo.

Neste ponto, acho que depende de você @drakenclimber; se quiser acesso de gerente / moderador, você precisará se inscrever com uma conta do Google.

Embora eu ache que devemos manter a lista de e-mails por perto, por favor, não sinta que você precisa ser um gerente / moderador da lista para "dividir o fardo", não há "fardo" neste caso.

Faz sentido. Sinta-se à vontade para adicionar meu endereço do gmail se quiser; Eu realmente não vejo uma desvantagem, mas pode ser útil mais tarde. tom dot hromatka no gmail.

Acabei de notar que, na guia "Segurança" do projeto, o GitHub parece lidar com o arquivo SECURITY.md de uma maneira especial (consulte CONTRIBUTING.md como exemplo). Devemos considerar o uso desse arquivo como parte desse processo.

A guia "Segurança" também permite que você crie uma bifurcação privada do projeto para que possa trabalhar em patches em particular; isso pode ser uma grande vitória, pois nos permite colaborar melhor nas correções de segurança sem tornar o problema público antes que a correção esteja pronta.

Esse é um recurso muito legal. Bom achado!

@drakenclimber Acabei de atualizar o documento no comentário acima,

@drakenclimber Acabei de inscrever o seu endereço do Gmail no grupo do Google e dei a você acesso de gerente / moderador, se não estiver funcionando, me avise.

Acabei de inscrever seu endereço do Gmail no grupo do Google e concedi a você acesso de gerente / moderador, se não estiver funcionando, me avise.

Parece que está funcionando. Consegui fazer o login e acessar as configurações da lista de e-mail. Obrigado!

Acabei de atualizar o documento no comentário acima, dê uma olhada e me diga o que você achou.

Parece muito bom para mim.

@drakenclimber aqui está um rascunho rápido de um documento SECURITY.md, o que você

O processo de manipulação de vulnerabilidade de segurança libseccomp

https://github.com/seccomp/libseccomp

Este documento tenta descrever os processos através dos quais bugs de segurança relevantes podem ser revelados de forma responsável ao projeto libseccomp e como os mantenedores do projeto devem lidar com esses relatórios. Assim como os outros documentos do processo libseccomp, este documento deve ser tratado como um documento de orientação e não como um conjunto rígido e inflexível de regulamentos; os relatores de bug e mantenedores do projeto são encorajados a trabalhar juntos para resolver os problemas da melhor maneira possível, da maneira que funcione melhor para todas as partes envolvidas.

Problemas de relatório

Problemas com a biblioteca libseccomp que não são adequados para divulgação pública imediata devem ser enviados por e-mail para os mantenedores atuais da libseccomp, a lista está abaixo. Normalmente solicitamos um período de no máximo 90 dias para resolver o problema antes de torná-lo público, mas faremos todos os esforços para resolver o problema o mais rápido possível e reduzir a janela de divulgação.

• Paul Moore, [email protected]
• Tom Hromatka, tom. [email protected]

Resolvendo Problemas Sensíveis de Segurança

Após a divulgação de um bug, os mantenedores devem trabalhar juntos para investigar o problema e decidir sobre uma solução. Para evitar uma divulgação antecipada do problema, aqueles que estão trabalhando na solução devem fazê-lo em particular e fora das práticas tradicionais de desenvolvimento do libseccomp. Uma solução possível para isso é aproveitar a funcionalidade "Segurança" do GitHub para criar uma bifurcação de desenvolvimento privada que pode ser compartilhada entre os mantenedores e, opcionalmente, o relator. Um problema do GitHub pode ser criado, mas os detalhes devem permanecer extremamente limitados até que o problema seja corrigido e divulgado com responsabilidade. Se um CVE, ou outra tag, tiver sido atribuído ao problema, o título do problema do GitHub deve incluir a tag de vulnerabilidade assim que o problema for divulgado.

Divulgação Pública

Sempre que possível, práticas responsáveis ​​de relatórios e patches devem ser seguidas, incluindo notificação às listas de discussão linux-distros e oss-security.

• https://oss-security.openwall.org/wiki/mailing-lists/distros

da maneira que funciona melhor para eles.

nitpick - Eu ficaria tentado a mudar isso para in a manner which works best for all parties involved.

Acho que o documento de vulnerabilidade de segurança parece muito bom. Bom trabalho!

da maneira que funciona melhor para eles.

nitpick - Eu ficaria tentado a mudar isso para in a manner which works best for all parties involved.

Eu gosto disso, atualizando o rascunho agora.

Acho que estamos de acordo que vale a pena montar um PR com as atualizações de doc / processo, farei isso agora e postarei um link de volta aqui.

Link PR (também incluído no histórico do GH acima): https://github.com/seccomp/libseccomp/pull/158

Acho que está tudo pronto agora @drakenclimber , se notar alguma coisa errada, me avise.