JInitiator è obsoleto e dovrei rifiutarlo per motivi di sicurezza, giusto?

JInitiator è basato sull'implementazione JVM di Sun (ora Oracle), quindi è una scommessa sicura che ogni vulnerabilità singola che era in Sun / Oracle JVM prima del 2008 (quando è stata prodotta l'ultima versione di JInitiator) ma rilevata solo successivamente a JInitiator. La mancanza di CVE deriva solo dal disinteresse da parte delle persone che riempiono CVE (non c'è gloria nell'indicare difetti di sicurezza in un prodotto che è stato interrotto cinque anni fa).

Si noti che alcune vulnerabilità sono novità, ad es. quello descritto su questa pagina utilizza una funzionalità introdotta con Java 7 - non funzionerebbe su JInitiator. Potresti passare attraverso questo elenco : vulnerabilità che erano scoperto dopo il 2008, ma ha un impatto su JRE 1.3 e versioni successive, ha un'alta probabilità di impatto su JInitiator. Devi solo trovare una demo di exploit di lavoro one per avere un caso convincente che JInitiator debba essere implementato al più presto.

Aggiornamento (giugno 2015):

• Oracle Forms 11g (l'ultima versione) è ora certificato con Java 7 (o 1.7: la convenzione di denominazione si riduce e cambia con Java!) e credo anche con l'ultima versione di Java 8. Posso certamente confermare che un'applicazione Oracle Forms 11g funziona con entrambe queste versioni, senza necessità di modifiche sul lato client JRE.

• Oracle Forms 10g (ora de-supportato) può essere fatto funzionare con Java 7 e 8 - questo significa, per i siti che devono utilizzare Oracle Forms 10g (sistemi legacy, percorso di aggiornamento lento, ecc.), puoi almeno assicurarti che stiano utilizzando l'ultimo client JRE.

I passaggi per ottenere la compatibilità con i più recenti client Java per Oracle Forms 10g sono, tuttavia, abbastanza brutali: è necessario sovrascrivere le informazioni del fornitore per il client JRE (altrimenti si pensa che si stia utilizzando una versione ancora più vecchia di Jinitiator) e aggiornare i JAR utilizzati dalla propria applicazione per portarli in linea con i requisiti attuali per i JAR firmati; questo include i JAR Oracle che fanno parte del server Web Oracle iAS 10g (la piattaforma utilizzata per eseguire Oracle Forms 10g).

I passaggi necessari per ignorare le informazioni del fornitore nel client JRE sono trattati in questa risposta Overflow dello stack: link

Per aggiornare i JAR, è necessario rimuovere le firme Oracle esistenti, i manifesti aggiornati, quindi i JAR devono essere riscritti con il proprio certificato di firma del codice; ne usiamo uno da Comodo che funziona senza problemi.

È molto da fare, ma una volta fatto il tuo sistema legacy Oracle Forms 10g dovrebbe funzionare correttamente con l'ultimo client JRE, senza avvisi di sicurezza per gli utenti finali.

Sì, come ha detto @Tom Leek, migrare lontano da JInitiator, è peggio delle alternative e i vecchi exploit di jre dovrebbero funzionare contro di esso.

MA:

Le notizie peggiorano da qui.

Oracle Forms è certificato solo per essere eseguito su 1.6 JRE, che ora non riceve aggiornamenti.

E a volte gli aggiornamenti di JRE 1.7 possono spazzare via qualsiasi installazione 1.6 (l'attuale consiglio di Oracle è di disattivare gli aggiornamenti automatici di Java nelle finestre non gestite).

Quindi, sei appena uscito dalla tana del coniglio e lo sviluppatore di Java e lo sviluppatore di Oracle Form stanno prendendo decisioni contrastanti (ovviamente sono entrambi Oracle Corp).

Benvenuti nel mio mondo.