Estoy desarrollando update4j , un marco de lanzamiento y actualización basado en Java. Hace poco tuve una pequeña disputa con un colaborador y quiero aclarar las cosas.
Yo como pocas palabras posibles; hay un actualizador del lado del cliente que lee un archivo de "configuración" remota. Ese archivo contiene toda la información necesaria para descargar los archivos de la aplicación.
Además, hay una función de suscripción para firmar archivos y verificar cada descarga con una clave pública. Esto debería evitar que los piratas informáticos cambien los archivos en la configuración o modifiquen los archivos reales de aplicaciones remotas. En la configuración, al lado de cada archivo, el actualizador del lado del cliente agrega y usa un campo signature para verificar una clave pública conocida proporcionada en la instalación.
Ahora, consideré la inclusión del desarrollador si el certificado / clave pública se usa en el actualizador cuando solicito realizar una actualización. De lo contrario, el actualizador ignora completamente el campo signature . Pero afirman que si la configuración contiene firmas, esto por sí solo se considera una opción de inclusión y debe obligar al actualizador a verificar, y si el actualizador nunca tuvo conocimiento de ninguna clave pública y nunca la solicitó, debería fallar.
No se proporciona certificado local
Si la configuración contiene firmas (por lo que el proveedor intenta asegurar la actualización), pero no se proporciona un certificado local, update4j descarga la configuración, los archivos y la ejecuta. En mi opinión, esto no es seguro. Ver
src/test/java/org.update4j.integration.SigningTest.noCertificateWithSignatureTest()
Desde mi perspectiva, esto se siente innecesario. El "proveedor" suele ser el mismo equipo de desarrollo del actualizador del lado del cliente (al menos decidieron cómo configurar el actualizador). Si un pirata informático puede acceder a los archivos o la configuración misma y modificarlos, el "proveedor" ya no busca seguridad. Si cambian las cosas a sabiendas de que el actualizador nunca requiere firmas, ¿por qué en el mundo ese pirata informático agregaría el campo signature ? Además, hace que sea muy difícil agregar seguridad solo para algunas instalaciones (por ejemplo, una función de prueba) ya que tendría que agregar una firma pero ahora hará explotar a los antiguos clientes.
El único caso en el que podría estar de acuerdo es que la configuración en sí no fue pirateada, solo los archivos remotos. Aquí el proveedor todavía querría verificar los archivos. Pero recuerde, el equipo de desarrollo nunca buscó seguridad ya que no configuraron el actualizador para verificar las firmas.
¿Cómo manejaría tal caso?