Saltar al contenido

Lo que se lee al compilar y lo que se lee al arrancar

La distinción que ordena la configuración entera: qué queda congelado dentro del binario firmado y qué se puede consultar o cambiar en tiempo de ejecución. Y por qué es una propiedad de seguridad y no un detalle.

La frontera

Por qué lo compilado es una propiedad de seguridad

Aquí está la idea que hay que llevarse del nivel. Cuando una configuración se lee en tiempo de ejecución desde un fichero junto al binario, cualquiera con acceso al disco puede editarla. En una aplicación de escritorio eso incluye al propio usuario, a cualquier programa que corra con sus permisos, y a un instalador de terceros que empaquete tu aplicación con un ajuste distinto.

Compilar la configuración dentro del binario cambia eso: para alterarla hay que recompilar y volver a firmar. Sin la clave privada, no se puede. Y si alguien modifica el binario a mano, la firma deja de validar y el sistema operativo lo detecta.

TXT
configuración en un fichero junto al binario  →  editable por cualquieraconfiguración incrustada en el binario firmado →  hay que tener la clave

Por eso el manifiesto de permisos se compila y no se lee. Un modelo de permisos que viviera en un JSON editable sería una sugerencia, no un control. Es la misma razón por la que la política de contenido va compilada: si se pudiera editar, desactivarla sería trivial.

Leer la configuración en ejecución

Aunque esté compilada, se puede consultar. Desde Rust:

Rust
// El manejador de la aplicación da acceso a la configuración incrustada.let cfg = app.config();println!("{} v{}", cfg.product_name.as_deref().unwrap_or("?"), cfg.version.as_deref().unwrap_or("?"));

Y desde el frontend, con el plugin correspondiente, se puede pedir la versión y el nombre para mostrarlos en un «acerca de». Es la vía correcta para eso: la versión se lee de la configuración, no se escribe a mano en la interfaz, que es como se acaba enseñando una versión que no es la que corre.

La regla para decidir dónde va algo

Con todo lo anterior, la regla completa son tres preguntas en orden:

  1. ¿Puede depender de algo que solo se sabe en ejecución? —el monitor, la sesión anterior, lo que el usuario eligió—. Si sí, no cabe en un fichero estático. Va en Rust.
  2. ¿Es una frontera de seguridad? —permisos, ámbitos, políticas, identidad—. Si sí, va en la configuración, compilada, y asumes el coste de publicar para cambiarla.
  3. ¿Es una preferencia del usuario? Si sí, va en un almacén de preferencias, editable, y no en la configuración. Nivel 44.

Casi toda la confusión sobre dónde poner algo se resuelve con esas tres preguntas, y la que más se salta es la tercera: la configuración de la aplicación no es el sitio de las preferencias, aunque las dos se llamen «configuración».