JInitiator está obsoleto y debería rechazarlo por razones de seguridad, ¿verdad?

JInitiator se basa en la implementación de JVM de Sun (ahora Oracle), por lo que es una apuesta segura que cada Vulnerabilidad única que estaba en Sun / Oracle JVM antes de 2008 (cuando se produjo la última versión de JInitiator) pero que se descubrió solo después se aplica a JInitiator. La falta de CVE solo proviene del desinterés por parte de las personas que llenan el CVE (no hay gloria en señalar fallas de seguridad en un producto que se ha suspendido hace cinco años).

Tenga en cuenta que algunas vulnerabilidades son novedades, por ejemplo, el descrito en esta página utiliza una función presentada con Java 7 - no funcionaría en JInitiator. Es posible que desee consultar esta lista : vulnerabilidades que fueron descubierto después de 2008, pero el impacto de JRE 1.3 y posterior, tiene una alta probabilidad de impactar también en JInitiator. Solo necesita encontrar una demostración de exploit en funcionamiento para tener un caso convincente de que JInitiator debería ser implementado lo antes posible.

Actualización (junio de 2015):

• Oracle Forms 11g (la última versión) ahora está certificado con Java 7 (o 1.7; ¡las convenciones de nomenclatura cambian y cambian con Java!) y creo que con el último Java 8 también. Ciertamente puedo confirmar que una aplicación Oracle Forms 11g funciona con estas dos versiones, sin necesidad de ajustes en el lado del cliente JRE.

• Se puede hacer que Oracle Forms 10g (ahora no compatible) funcione tanto con Java 7 como con 8 - esto significa que, para los sitios que tienen que usar Oracle Forms 10g (sistemas heredados, ruta de actualización lenta, etc.), al menos puede asegurarse de que estén utilizando el último cliente JRE.

Sin embargo, los pasos para lograr la compatibilidad con los nuevos clientes de Java para Oracle Forms 10g son bastante brutales: debe anular la información del proveedor para el cliente de JRE (de lo contrario, cree que está ejecutando una versión aún más antigua de Jinitiator) y actualice los JAR utilizados por su aplicación para alinearlos con los requisitos actuales para los JAR firmados; esto incluye los JAR de Oracle que forman parte del servidor web Oracle iAS 10g (la plataforma utilizada para ejecutar Oracle Forms 10g).

Los pasos necesarios para anular la información del proveedor en el cliente JRE se tratan en esta respuesta de desbordamiento de pila: enlace

Para actualizar los JAR, las firmas de Oracle existentes deben eliminarse, los manifiestos se actualizan y, a continuación, los JAR deben volver a firmarse con su propio certificado de firma de código. Usamos uno de Comodo que funciona sin problemas.

Es mucho lo que hay que hacer, pero una vez hecho, su sistema Oracle Forms 10g heredado debería funcionar correctamente con el último cliente JRE, sin advertencias de seguridad para sus usuarios finales.

Sí, como dijo @Tom Leek, migran fuera de JInitiator, es peor que las alternativas y las antiguas vulnerabilidades de jre deberían funcionar en su contra.

BUT:

Las noticias solo empeoran a partir de aquí.

Oracle Forms solo está certificado para ejecutarse en 1.6 JRE, que ahora no recibe actualizaciones.

Y, a veces, las actualizaciones de JRE 1.7 pueden eliminar cualquier instalación 1.6 (el consejo actual de Oracle es desactivar las actualizaciones automáticas de Java en ventanas no administradas).

Por lo tanto, acaba de pasar por el agujero de los conejos, y el desarrollador de Java y el desarrollador de Oracle Forms están tomando decisiones conflictivas (por supuesto, ambos son Oracle corp).

Bienvenido a mi mundo.