TrafficServerLocal/docs/publicacion-anonima.md

Política de publicación anonimizada

Todo proyecto del laboratorio que se publica en un repositorio público o compartido debe estar anonimizado. Esto aplica tanto a la infraestructura como al código fuente de las aplicaciones.

Motivo: el laboratorio investiga Software Libre y comparte su producción técnica. Los repositorios no deben exponer datos del servidor de trabajo, dominios, credenciales ni la identidad de las personas que despliegan.

---

1. Qué se anonimiza

Categoría	En el servidor real	En el repositorio
Nombre de persona	nombre.apellido	$USER, usuario-local
Ruta de home	/home/<usuario>/srv	~/srv
Email	<nombre>@<universidad>.edu.ar	usuario@localhost
Nombre de proyecto	<nombre-del-cliente>	miapp, ejemplo, demo
Dominio real	<dominio-real>.com.ar	example.com, midominio.com, miapp.local
IP de servidor	<ip-publica-del-servidor>	203.0.113.45 (RFC 5737, reservada para docs)
Credenciales	<clave-en-claro>	${DB_PASSWORD}
Ruta interna	/var/lib/<aplicacion>/produccion	/var/lib/miapp

Exención institucional. El nombre del laboratorio — Laboratorio de investigacion en Software Libre Gugler - FCyT— y las referencias a git.gugler.com.ar son públicos por decisión propia y no se anonimizan. La anonimización protege los datos de las personas y de la infraestructura del servidor, no a la entidad que publica el código.

---

2. Checklist antes de publicar

# 1. Verificar datos sensibles en el índice
./tools/verificar-anonimato.sh

# 2. Confirmar que lo excluido NO está trackeado
git status --ignored --short | grep -E '\.env|\.key|\.crt|acme\.json'

# 3. Revisar el historial de commits
git log --format='%an <%ae>' | sort -u

# 4. Confirmar el tamaño del repo (sin datos ni dependencias)
git count-objects -vH
du -sh .git

• No hay .env, *.key, *.crt, acme.json, .sql, .dump, .zip
• No hay vendor/ ni node_modules/ (se regeneran con composer / npm)
• Nombres de proyecto genéricos en compose, .env, scripts y documentación
• Dominios de ejemplo, nunca los reales
• Sin direcciones IP públicas ni internas reales
• Sin rutas con nombre de usuario
• Sin datos de negocio en migraciones, seeders o fixtures
• git log revisado
• LICENSE (GPL-3.0) presente
• .gitignore actualizado con los patrones del proyecto

---

3. Herramientas de apoyo

# Buscar patrones sospechosos en el contenido versionado
git grep -nEi "password|secret|api[_-]?key|token|[0-9]{1,3}(\.[0-9]{1,3}){3}"

# Historial de autores
git shortlog -sne

# Buscar en TODO el historial, no solo en el HEAD
git log -p --all | grep -Ei "password|secret|api[_-]?key"

Si un secreto se subió por error, no alcanza con borrarlo: queda en el historial. Hay que rotar el secreto y reescribir el historial (git filter-repo) o reiniciar el repositorio.

---

4. Patrón recomendado para proyectos

Separar siempre en dos repositories:

~/srv/projects/<proyecto>/
├── app/       → código fuente, en su propio repo público y anonimizado
└── (resto)    → .env, data/, backups/ → NUNCA versionados

La infraestructura (proxy, Traefik, generador de proyectos) se publica una sola vez desde este repositorio; los proyectos solo aportan su app/.

Al crear el proyecto, se usan nombres de ejemplo desde el inicio para que el anonimizado no sea un paso posterior olvidado:

./init_project.sh miapp midominio.com 80

---

5. Licencia

Todo el material se publica bajo GPL-3.0. Si un proyecto incluye código de terceros, se conserva su licencia original y se acredita en el README y en los encabezados de los archivos afectados.

---

6. Denuncias

Si se detecta un dato sensible publicado, reportarlo a quien mantiene el repositorio para la rotación inmediata del secreto y la limpieza del historial.