Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Proponer Code safety por defecto en nuevos bootstraps

Abierto
  • ¿Algo no está bien?
#57 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, javascript
Área
devtools, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
JavaScript
Estrellas
22
Forks
3
Merge medio
27 min
PR fusionados (30 d)
27

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de egdev6/github-repository-bootstrap

Todos los issues de egdev6/github-repository-bootstrap

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.