Apple retrasa a enero de 2020 la exigencia de notaría en las apps de macOS Catalina

Os hablamos hace un tiempo de un requisito que tendrían todas las apps en macOS Catalina: la notaría. Básicamente Apple exigirá que todas las apps tengan un "sello" creado por ellos, que certifica una versión de una app tras pasarle unos tests automáticos. Es un proceso de pocas horas, muy sencillo, pero necesario para que GateKeeper certifique que esa app ha sido validada por Apple. Os lo explicamos al detalle en este artículo.

En aquel momento se estableció la condición que todas las apps que se ejecutarán en macOS Catalina, desde su lanzamiento, deberían estar notariadas y si no, darían un error de seguridad y forzaría al usuario a ejecutarlas bajo su responsabilidad pulsando la tecla CTRL mientras se ejecuta. Incluso, si lo que vamos a ejecutar es una librería no notariada, dentro de nuestra app, esta también requería esta condición. En las betas esto ha dado algún problema como que Firefox de un error de seguridad en Catalina o Chrome informe que el paquete de ejecución de Flash (externo a la propia app) no está firmado y niegue su ejecución.

La complejidad que subyace a que todas las apps y versiones de las mismas tengan que estar notariadas con el Apple ID Developer que se genera con una cuenta de pago del programa de desarrolladores (obligatorio, por otro lado) ha hecho que Apple retrase un poco su exigencia y permita que las apps puedan ir adaptándose hasta enero del próximo año 2020.

De hecho, dada la complejidad de un sistema operativo de escritorio, Apple ha tenido que rebajar también las exigencias para obtener la notaría porque determinadas apps que necesitan un acceso más "profundo" al sistema, nunca conseguirían esa validación.

Por este motivo, Apple ha tenido que incluir las siguientes excepciones para que todas las apps puedan ser notariadas:

• Apps que no habiliten la función Hardened Garden que complementa al sistema de protección de integridad del sistema o SIP y evita accesos al kernel, inyección de código y otros intentos de ataque.
• Apps que usen librerías no firmadas con el Developer ID dentro de una app.
• Apps que no tengan sellado de tiempo seguro dentro de la firma de la app.
• Apps que estén compiladas con versiones antiguas de SDKs.
• Apps que incluye el entitlement com.apple.security.get-task-allow a verdadero, que permite que otros procesos ajenos a la propia app se enlacen a esta. Como un depurador de código, por ejemplo.

Como ya hemos comentado en alguna ocasión, un sistema operativo de escritorio es un mundo mucho más complejo que debe permitir mayor versatilidad. En iOS yo puede cerrar el jardín por defecto (el hardened gargen) e incluso prohibir que nadie use máquinas virtuales menos la mía (como el caso de los navegadores que todos deben usar el motor WebKit del sistema). Pero en un sistema de escritorio esto no tiene lógica alguna y siempre ha de deber permitirse (para que tenga sentido como herramienta profesional) una permisividad mayor. Sobre todo si trabajamos como desarrolladores.

Apple, obviamente, se tiene que ir adaptando a la realidad del mundo del desarrollo y las apps en Mac y no le queda otra que ir relajando las exigencias, eso sí, intentando preservar al máximo las garantías de seguridad de los usuarios.

Podéis consultar la nota de prensa para desarrolladores, pulsando aquí.