Repository navigation
El ADR-0040 recoge la regla «en macOS, la API de macOS, salvo el DNIe» y el glosario el Almacén de macOS #2001
Copy link
Copy link
Closed
Labels
ready-for-agentFully specified, an agent can pick it upFully specified, an agent can pick it up
Description
Parent
What to build
Quien toque macOS encuentra la regla y su excepción en el ADR-0040 reescrito en su sitio, como se hizo con el ADR-0035, y el término «Almacén de macOS» con el orden de almacenes nuevo en el glosario. La tabla de adaptadores pendientes del ADR-0040 se queda como está: cada ticket que sustituye uno lo retira de ella.
Acceptance criteria
- El ADR-0040 enuncia la regla y la excepción del DNIe con su motivo, y la distribución sin cuenta de Apple Developer (tap de Homebrew y actualizador propio).
-
CONTEXT.mddefine «Almacén de macOS» junto a «Almacén de Windows» y el orden de almacenes de ID-531. - El índice de ADR de
docs/AGENTS.mdsigue correcto.
Blocked by
- None (can start immediately)
Spec extract
Implementation Decisions (from #2000):
- ID-527: En macOS se usa la API de macOS siempre que se pueda (Security.framework, CryptoTokenKit a través del llavero, LaunchServices), como ID-475 en Windows. La excepción es el DNIe, que va por PKCS#11 porque macOS no trae controlador del sistema para él y la DGP solo publica un módulo PKCS#11. El ADR-0040 se reescribe en su sitio con la regla y la excepción, como se hizo con el ADR-0035; los adaptadores pendientes que esta spec sustituye salen de su tabla.
- ID-528: Término nuevo «Almacén de macOS» (clase de almacén propia, como
StoreClass::Windows): los certificados con clave privada del llavero de la persona usuaria. Se rotula «Almacén de macOS» en la lista, el asistente y el estado. El glosario lo define junto a «Almacén de Windows»; «llavero» sigue reservado para lo que guarda secretos. - ID-531: El orden de almacenes pasa a ser: tarjeta, Almacén de Windows o Almacén de macOS, Almacén de rFirma, NSS del sistema, familia Firefox, familia Chromium. El glosario se actualiza.
- ID-548: No hay cuenta de Apple Developer. rFirma para Mac no se firma con Developer ID ni se notariza; mantiene la firma ad hoc y el hardened runtime desactivado del ADR-0040, que además deja cargar módulos PKCS#11 de terceros.
- ID-549: Se distribuye por un tap de Homebrew propio del proyecto, con un cask que instala el
.apppublicado en la Release. La entrega vuelve a construir el paquete de macOS (revierte f785fe3) y el tap se actualiza en cada versión. Las instrucciones de instalación, incluidoxattr -c /Applications/rFirma.apppara abrir la aplicación ante el aviso de Gatekeeper la primera vez, van en la documentación del tap y en la de rFirma; la landing no anuncia macOS como instalación sin pasos. - ID-550: En macOS, rFirma se actualiza sola con el canal de Windows (Actualización de rFirma en Windows desde la propia aplicación #1230): la entrega publica el paquete de actualización de macOS firmado con minisign y su entrada en
latest.json, y rFirma lo comprueba e instala igual que en Windows. El cask declaraauto_updates: true, de modo quebrew upgradeno lo toca y no hay dos vías que se pisen; rFirma no trata una instalación por Homebrew como gestionada por paquete. Es el modelo de tabularis. La descarga del actualizador no lleva la marca de cuarentena del navegador, así que el aviso de Gatekeeper solo aparece en la primera instalación; está por verificar con la firma ad hoc en la prueba manual N→N+1, como Validar a mano la actualización N→N+1 en una VM Windows #1238.
Complexity
standard — solo documentación, sin código. Estimación: unos 50k tokens.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
ready-for-agentFully specified, an agent can pick it upFully specified, an agent can pick it up
Activity