Firma de código en macOS: Lo que los Desarrolladores han de saber, Parte 3

Si has seguido los artículos previos de esta serie, entonces ya deberías de tener todo configurado: tus certificados de Desarrollador Apple deberían de estar almacenados en la app Acceso a Llaveros de tu Mac, de modo que ya puedas rellenar el campo Build Settings > macOS > Sign > Developer ID con el valor esperado del certificado, hacer clic en el botón Build (o Publish)… y distribuir tu nueva magnífica app a todo el mundo, ¿verdad? No realmente. Aún existen otras piezas del puzzle a tener en cuenta cuando se trata de firmar tus apps macOS.

A lo largo de los últimos 20 años Apple ha ido incrementando paulatinamente las medidas de seguridad en lo que respecta a la ejecución de apps distribuidas por terceros. Echemos un vistazo a esta línea temporal resumida, relacionada con las medidas de firmado de código y seguridad añadidas por Apple a lo largo de estos años:

Los aspectos más interesantes probablemente hayan ocurrido en los años 2011, 2012 y 2018, en los que se vieron por primera vez términos (tecnologías) como Sandbox y especialmente los Containers, Gatekeeper, Hardened Runtime y Notariado; impactando, por lo tanto, otras piezas del rompecabezas a tener en cuenta cuando se trata de firmar las apps en macOS. De hecho, podríamos decir que tecnologías como el firmado de código, Sandboxing, Entitlements o Provisioning Profiles fueron las primeras en ser trasladas desde iOS… ¡hacia macOS!

Veamos brevemente lo que significan dichas tecnologías:

Sandboxing. Cuando se utiliza confina las aplicaciones a un área restringida del sistema (su propio “Contenedor”), evitando así que la app pueda acceder a datos del usuario, hardware u otras apps de las que no se obtenga un permiso explícito. El sistema fuerza a las apps a que pidan permiso al usuario para emplear recursos hardware o bien cuando se trata de acceder a archivos del usuario. El Sandboxing es obligatorio para las apps enviadas para su distribución a través de la Mac App Store.
Gatekeeper. Esta tecnología supone la primera capa de seguridad, y se encarga de comprobar que cualquier app descarga provenga de un desarrollador verificado y conocido; especialmente cuando dicha aplicación ha sido Notariada por Apple.
Hardened Runtime. Actúa como un escudo proactivo reforzado del sistema que protege a las aplicaciones durante su funcionamiento, previniendo que código malicioso pueda introducirse en software legítimo. La activación de Hardened Runtime es requerida para el Notariado de software.
Notariado de software. Se trata de un proceso de revisión automatizado realizado por parte de Apple, en el que se explora el software distribuido fuera de la Mac App Store sobre la presencia de componentes maliciosos y por problemas o fallas de seguridad conocidas. Actualmente se requiere el Notariado para el software distribuido fuera de la Mac App Store, y que haya sido previamente firmado utilizando el certificado Developer ID Application. Como resultado del proceso, el Notariado genera y asocia un ticket sobre la app, ticket que ha sido firmado mediante uno de los certificados de Apple… de modo que Gatekeeper confiará en dicha app cuando el usuario la ejecute.

De modo que, básicamente, si bien el Sandboxing aun es opcional para las apps distribuidas fuera de la Mac App Store (es decir, firmadas mediante el certificado Developer ID Application), el Notariado y Hardened Runtime son tecnologías que deberías de aplicar en tus apps distribuidas fuera de la Mac App Store. Activar el Sandboxing para tu app es algo a considerar en función de las necesidades (capacidades) ofrecidas por tu app a los usuarios de la misma; un balance entre confianza / capacidades / privacidad del usuario.

Por otra parte, si tienes planeado distribuir la app también a través de la Mac App Store, entonces sólo has de habilitar Sandboxing y firmar la app utilizando tu certificado Apple Distribution; mientras que la activación de Hardened Runtime es, por ahora, algo opcional.

Entitlements y Provisioning Profiles

Además, varias de las tecnologías y medidas de seguridad previas requieren del uso de algo denominado Entitlements y Provisiones Profiles cuando se compila y firma la app… en función de las características y servicios utilizados por la aplicación propiamente dicha.

Por ejemplo, si decides seguir la ruta del Sandboxing para tus apps… entonces es obligatorio el uso de Entitlements. La buena noticia es que los entitlements relacionados con el Sandboxing son “gratis” de usar (es decir, no requieren de la creación y adición a tu proyecto del correspondiente Provisioning Profile asociado); pero si tu app requiere de algún tipo de acceso especial al llavero del usuario, o hace uso de tecnologías como iCloud o Apple Pay… entonces tendrás que crear un Provisioning Profile en el portal Apple Developer.

¡Hey! Espera, espera… pero, ¿qué son a fin de cuentas esos “Entitlements” y “Provisioning Profiles”, y qué relación tienen con el firmado de código en mis apps para macOS?

Entitlements

De forma resumida, los Entitlements son archivos .plist basados en XML (no muy diferentes a los Info.Plist a los que ya estás acostumbrado), cuyo contenido son una serie de pares clave-valor y que se embebe directamente como parte de la firma en el binario de la app (es decir, utilizando generalmente los certificados Developer ID Application o Apple Distribution):

Provisioning Profiles

Mientras que los Entitlements son simplemente un archivo, los Provisioning Profiles son una bestia aparte:

Estos han de crearse en el portal Apple Developer. Durante la creación de un provisioning profile has de proporcionar un App Id (esto es, una combinación de tu Team ID y el bundle de la app… y que es sensible al uso de mayúsculas y minúsculas; ¡cuidado con eso!). De modo que, si no tienes previsto distribuir tu app de macOS a través de la Mac App Store pero dicha app requiere utiliza un Provisioning Profile… entonces tendrás que crear en primer lugar un App ID en el portal Apple Developer.

Existen dos tipos de Provisioning Profiles: Development (desarrollo) y Distribution (distribución). Como parte de la creación de un Provisioning Profile tendrás que decidir qué tipo de provisioning profile vas a usar.

Los Provisioning Profiles de desarrollo son una buena opción cuando estás desarrollando tu app, dicha app se firmará utilizando tu certificado Apple Development y se ejecutará en una serie de Macs previamente registrados. Durante la creación de dicho perfil puedes añadir tantos certificados Apple Development como hayas creado en tu cuenta (Team ID).
Los Provisioning Profiles de distribución son la opción cuando se trata de distribuir tu app. En este caso has de añadir el mismo certificado Developer ID Application que vayas a utilizar durante el firmado de la aplicación para su distribución fuera de la Mac App Store; o bien el certificado Apple Distribution si tienes previsto distribuir la app a través de la Mac App Store.
Los Provisioning Profile de Distribución y Desarrollo caducan. Esto es algo que has de tener en cuenta, especialmente a la hora de desplegar nuevas versiones o versiones actualizadas de tu app, dado que pueda que debas de crear unos nuevos.
Los Provisioning Profile de Distribución y Desarrollo se pueden editar. Si has cometido algún fallo durante la creación de un Provisioning Profile, es buena cosa saber que puedes editarlos en el portal Apple Developer, aunque sólo podrás editar los campos App ID, el nombre dado al perfil propiamente dicho o bien el certificado seleccionado en cada caso; o bien los dispositivos de prueba seleccionados (en el caso de los perfiles de aprovisionamiento de desarrollo).

Cuando los Certificados y / o los Provisioning Profiles expiran…

Ya hemos visto en los artículos previos que los certificados de Desarrollo de Apple expiran… un año después de que se hayan creado y, ahora, también hemos descubierto que si tu app necesita hacer uso de un perfil de aprovisionamiento… ¡este también expira! ¿Qué implicaciones tiene esto para tus apps ya distribuidas?

No hay problema. Centrémonos en primer lugar en la apps de macOS distribuidas de forma directa (es decir, las firmadas utilizando el certificado Developer ID Application), y recuperemos una captura de pantalla del artículo anterior:

Fíjate en la línea Timestamp resaltada. Cuando se firma la app se añade automáticamente la fecha y hora en la que fue firmada (obtenida desde los servidores de Apple); de modo que cuando el usuario ejecuta una app, cuyo certificado Developer ID Application embebido ya caducó desde que se publicó la app, Gatekeeper echará mano de la fecha reflejada en la marca de tiempo, la comparará con la fecha de expiración del certificado embebido y, si la fecha es anterior a la de expiración del certificado, se ejecutará la app sin problemas… ¡siempre y cuando el certificado embebido no haya sido revocado por el propio desarrollador! Adicionalmente, si dicha app ha sido Notariada… entonces eso ayudará un montón, porque el ticket asociado con la app incluye su propia marca de fecha y se firmó mediante un certificado de Apple.

Si la app ha sido distribuida mediante la Mac App Store… ¡buenas noticias! Tan pronto como envías la app para su distribución mediante App Store Connect, y una vez que pasa el proceso de revisión por parte de Apple, la firma original de la app se desechará (es decir, la que realizaste utilizando tu certificado Apple Distribution), y Apple la firmará de nuevo utilizando para ello sus propios certificados. De modo que cualquier usuario podrá ejecutar cualquiera de tus apps descargadas desde la Mac App Store, incluso en el supuesto de que tu certificado Apple Distribution hubiese expirado tiempo atrás.

¿Y qué pasa con los Provisioning Profiles, especialmente los utilizados para la Distribución? Eso es algo completamente diferente, sí. Una vez que espiran, la app que contenga dicho Perfil de Distribución dejará de funcionar.

¡La buena noticia es que un Perfil de Distribución tiene un período de vigencia de 18 años! Eso significa que será bastante probable que hayas creado nuevos perfiles de aprovisionamiento como parte del ciclo de lanzamiento de nuevas versiones y/o actualizaciones de tus apps, mucho antes de que este expire sobre las apps ya instaladas.

Por supuesto, tan pronto como tus certificados de desarrollador expiren… ya sabes cómo solicitar e instalar nuevos certificados en el llavero de tu Mac.

Llegando al final del camino

En el próximo artículo, y último, veremos de qué forma te ayuda Xojo en todo lo relacionado con el firmado y distribución de tus apps macOS; y también veremos como tratar con algunos de los problemas más frecuentes relacionados con los certificados.