Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Proponer Code safety por defecto en nuevos bootstraps

Aberta
  • Algo errado?
#57 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
github-actions, javascript
Domínio
devtools, security

Direção de pesquisa

Start by reading the manifest intake, schema, validator, renderer, and public CLI paths that handle module planning and application; the issue does not name their files. Then trace how the exact plan binds source, rendered, and destination hashes, and how isolated tests cover opt-out, approval, preservation, and early and late drift. Done means meeting the acceptance criteria, including remote CI and Windows verification, while keeping the real asset unchanged.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

status:approved type:chore

Objetivo

Proponer el workflow Code safety por defecto en los manifiestos nuevos de GitHub Repository Bootstrap, preservando opt-out, compatibilidad y aprobación por plan exacto. Esta adopción reutiliza herramientas estáticas revisadas; no sustituye las issues #28–#30 del scanner contextual B06 ni las cierra.

Alcance aprobado

  • Módulo explícito codeSafety: false | { mode: "ensure" | "replace", policy?: object }.
  • Default de intake y ejemplo: { "mode": "ensure" }; manifests existentes que omiten el campo permanecen inactivos.
  • Semgrep (JS/TS) y zizmor (workflows) desde egdev6/quorb@176ae636fdd80ce60d6fffec188ce558c5f6692b, baseline revisada e inmutable. Checkout objetivo separado y tratado como datos.
  • Checker de repositorio opcional con política específica revisada y renderizada como datos estáticos; no copiar las excepciones de imágenes de Quorb ni confiar en políticas del objetivo.
  • Hashes de fuente/render/destino ligados al plan; cobertura ausente o malformada falla cerrado antes de planificar; checks anti-drift antes de mutaciones y antes de escritura.
  • ensure conserva archivos existentes; replace omite bytes iguales y actualiza diferencias solo con autorización exacta; no borrar.
  • Una PR de entrega con commits por unidades, según elección expresa del mantenedor. No tracker ni PRs hijas.

Criterios de aceptación

  • El manifiesto nuevo propone Code safety sin aprobar automáticamente su instalación.
  • Omisión o false no observa ni lee assets del módulo, y no desinstala un workflow existente.
  • Schema, validator y política admiten el mismo dominio JSON compatible.
  • Colisiones con archivos genéricos y evidencia incompleta se rechazan.
  • La CLI pública demuestra aprobación exacta, preservación y errores anti-drift tempranos/tardíos, manteniendo evidencia de trabajo ya completado.
  • Las pruebas usan copias aisladas y no alteran el asset real.
  • CI remota del candidato pasa en las plataformas configuradas, sin ejecutar releases.
  • Dependencia de control, alcance advisory y límites se documentan sin certificar ausencia general de malware.

Evidencia de preparación

Suite local corregida: 281 tests correctos, cero fallos u omisiones. Verificación independiente de lógica/contratos y posterior integridad: 13 tests de renderer y 9 CLI correctos con SHA256 del asset idéntico antes/durante/después.

Se corrigieron el mock CommonJS contaminado por un manifiesto ambiental, la evidencia desconocida del plan y el test late-drift que inicialmente modificaba el asset. La primera suite green se retiró como prueba de integridad; la evidencia nueva usa comparación exacta antes y después.

Hash limpio: 64ec81f4d3057ee024f63bfacb408d422478edb4608e1a2ae90c0ab3e1771826.

Límites y exclusiones

  • Hallazgos Semgrep/zizmor advisory; errores operativos, parseo y cobertura desconocida bloquean. No detector universal de malware ni certificación de Rust/exfiltración/ofuscación completa.
  • El workflow usa pushes a main, PRs y dispatch manual: otro default branch no obtiene automáticamente el trigger de push.
  • La política temporal vive hasta el teardown del runner hospedado; no se promete compatibilidad con runners persistentes arbitrarios.
  • Una PR puede editar su workflow; protecciones y required checks son decisiones separadas.
  • La rama de discovery con Projects v2 no tiene un caso dedicado; no inferir validación de live Projects, secretos o LLM desde fixtures.
  • Workflow portable real en GitHub Actions, actionlint y Windows: pendientes de verificación remota de entrega.
  • No merge, versión, release, tag, cambio de protecciones, actualización de instalación ni cierre de otras issues autorizados.
Linguagem predominante
JavaScript
Estrelas
22
Forks
3
Merge médio
27min
PRs com merge (30d)
27

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de egdev6/github-repository-bootstrap

Todas as issues de egdev6/github-repository-bootstrap

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.