Vlákno názorů k článku Java má další bezpečnostní chyby od Filip Jirsák - V moderním pluginu (Java 7 a novější verze...

V moderním pluginu (Java 7 a novější verze Java 6) už je applet a webstart to samé, resp. i applety se spouští přes webstart.

Ne kvůli bezpečnosti, ale prostě proto, že mi to spouštění z prohlížeče z nějakého důvodu přestalo fungovat a byl jsem líný to řešit.
Nepoužíváte Chrome/Chromium? Tam je podle mne od vydání "moderního Java pluginu" podpora Javy rozbitá, protože na moderní plugin přešli jenom na půl. Proto mne taky docela překvapuje ta panika kolem Javy v prohlížečích, přitom nikomu nevadí, že v Chrome je to už několik měsíců, ne-li let, rozbité.

A co takhle standardni scenar, uzivatel prijde, spusti a ono to bezi ... stejne jako miliony jinych aplikaci.
No vida, tak jste nakonec dospěl k tomu, co jsem psal na začátku.

IE s javou zcela souvisi, protoze stara java NENI funkcni, pokud ma dotycny na PC novejsi IE (jednoduse se ani nenecha instalovat).
O kterých verzích Javy a MSIE se přibližně bavíme? Mám MSIE 9 a nainstalovanou i Javu 5 (a taky 6 a 7), a nezdá se, že by to nešlo.

Mimochodem to, že nějaká aplikace vyžaduje konkrétní verzi Javy, je z hlediska bezpečnosti Java pluginu bezpředmětné. Aplikace si totiž může požadovanou verzi vyžádat, a ta verze se v případě potřeby doinstaluje. Takže nezáleží na tom, zda uživatel tu děravou verzi má nebo nemá nainstalovanou – podstatné je jenom to, zda má nainstalovanou libovolnou verzi s moderní verzí pluginu, která ty automatické instalace na pozadí podporuje.

Zkuste si porovnat ty uživatelské scénáře.

První varianta, uživatel přejde na stránku, potvrdí spuštění, na pozadí se mu případně automaticky stáhne a nainstaluje správná verze Javy, aplikace se spustí.

Druhá varianta, uživatel přejde na stránku, potvrdí spuštění, možná se mu spustí aplikace (možná taky ne, protože změna v JRE způsobí, že se aplikace ani nenastartuje), objeví se dialog, že má nepodporovanou verzi Javy, možná s odkazem. Takže přejde na stránku pro stažení starší verze JRE, vytvoří si Oracle Account, stáhne, nainstaluje, vrátí se na původní stránku, znovu spustí aplikaci, a znova se mu objeví ta samá hláška, protože když není nějaká verze vynucená natvrdo, aplikace se spustí s nejnovějším JRE. Můžete tipovat, ve kterém kroku uživatel usoudí, že rada od „j“ byla pěkně hloupá, můžete si ale být jist, že k tomu určitě dojde – poslední krok to zaručuje.

To, že je aplikace funkční pouze pod MSIE, s Javou nijak nesouvisí.

Tou konkrétní chybou opravenou v Java 7 update 11 netrpí řada 6, nové chyby jsou pořád ve stadiu „možná někde nějaká chyba je“ a nikdo o tom víc neví.

Příště se místo na jméno diskutujícího zkuste víc soustředit na obsah vlastního komentáře, dvě věci v rozporu s fakty a špatná dedukce v jediném komentáři nejsou žádná sláva.

Zcela normalni je, ze aplikace funguje na llibovolne verzi, ale garantovana je na nejakych vybranych verzich. Rozhodne neni normalni, aby aplikace natvrdo vyzadovala nejakou konkretni verzi.
Jak konkrétně se tohle zapisuje v JNLP souboru pro spuštění WebStart aplikace nebo appletu? Můžete také odkázat na screenshot dialogu, ve kterém následně uživatel vybírá, zda chce spustit aplikaci s garantovanou verzí JRE nebo s nějakou jinou? (Mimochodem, v MSIE něco takového opravdu funguje – pokud je vyžadována konkrétní verze a existuje novější, MSIE se dotáže, zda se má použít ta vyžadovaná nebo nejnovější).

co nejnovejsi - a tedy co nejmene derave
Nevybral jste si zrovna nejšťastnější dobu pro publikaci takového tvrzení. Od zveřejnění informací o poslední chybě, která se týkala jen řady 7 a starší verze byly bez této chyby, neuběhl ještě ani týden. Jinak to vyžadování verze se dělá právě proto, že nové verze někdy (bohužel víc, než by bylo milé) mají nové chyby.

Viděl jsem třeba verzi JRockitu, která měla chybu v optimalizčním kódu v JVM. Pod zátěží to začalo optimalizovat třeba java.lan.Long do nativního kódu, bohužel špatně, takže tu třídu efektivně vygumoval z JVM. ClassNotDefFound: java.lang.Long jsem tenkrát viděl poprvé a doufám naposledy v životě. Při nějaké konstelaci hvězd se ta chybná optimalizace ani nedokončila a sletěla rovnou celá JVM na segfault nebo něco podobného. Rada, že jsme to stejně měli provozovat na téhle (nejnovější) verzi, je sice hezká, ale nepoužitelná.

Ono totiž nic moc jiného nejde dělat, pokud máte garantovat, že vaše aplikace bude fungovat. Bylo by neefektivní testovat veškerou funkcionalitu s každou novou verzí Javy – třeba v případě appletů by to znamenalo s testováním různých verzí prohlížečů testovat stovky variant. Takže se vyvíjí a testuje s jednou verzí, za kterou autoři ručí. To neznamená, že to s jinou verzí nebude fungovat, ale může se stát, že v té jiné verzi runtime knihovny JRE bude nějaká změna, kvůli které ta aplikace přestane fungovat.

Jeden příklad z přechodu Java 6 na Java 7. Sedmička vynucuje vyšší úroveň zabezpečení při HTTPS komunikaci. Jako programátor to můžete ovlivnit ve své aplikaci. Ale když se aplikace spouští jako applet, pro stahování souborů appletu se použije výchozí nastavení, které nejde ovlivnit. Takže když se soubory appletu stahují přes HTTPS, v sedmičce se vždy použije vyšší zabezpečení (pokud uživatele nenasměrujete, jak si to někde v hlubinách ovládacích panelů přepnout). Jenže tohle vyšší zabezpečení musí podporovat i server. A když ho nepodporuje, jediná možnost je vynutit si Javu 6.

Pro bankovnictví Citibank (Citidirect) jsme nuceni používat JRE6 verze 7 (slovy - sedm). Pravda, v kombinaci s hardwarovými kalkulačkami. Jen doufám, že tyhle aplikace mají alespoň nějaký bezpečnostní standard.

To externě s potvrzením je na 99 % právě využití pluginu, který se v posledních verzích chová právě takhle. Jinak byste tu aplikaci musel stáhnout a spustit ručně, a to asi neděláte :-)

A hlavně některé banky reagují na bezpečnostní opravy tak "pružně", že je potřeba mít několik verzí starou Javu, aby IB fungovalo.

Díky za eKonto :-)

No, upřímně lituji klienty bank, jejichž IB vyžaduje k chodu Javu. Na webu jedné z nich visí info, že chyba už byla odstraněna a tak si ji mají znovu zapnout...