# 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` |

---

## 2. Checklist antes de publicar

```bash
# 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

```bash
# 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:

```text
~/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:

```bash
./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.