Oracle dicht 40 Java-lekken met komende patch

Oracle brengt komende dinsdag een patch voor Java uit die 40 lekken in de software ongedaan maakt. Van de veertig lekken zijn 37 door kwaadwillenden op afstand uit te buiten zonder dat verdere authenticatie nodig is.

De kritieke patch heeft betrekking op versies 5, 6 en 7 van de Java Runtime Environment en de Java Development Kit, maar ook op JavaFX 2.2.21 en ouder, maakt Oracle bekend in de vooraankondiging van het oplapmiddel. Het gaat in totaal om veertig lekken in de software. Daarvan zijn 37 op afstand via een netwerk te misbruiken zonder dat een gebruiker een wachtwoord of inlognaam hoeft in te voeren. De lekken krijgen dan ook de hoogste score van 10.0 in Oracles Common Vulnerability Scoring System.

Oracle raadt gebruikers aan de patch zo snel mogelijk uit te voeren zodra deze dinsdag verschijnt. Oracle zag zich al eerder dit jaar genoodzaakt noodpatches uit te brengen die geen onderdeel zijn van de vaste patchrondes die elke kwartaal doorgevoerd worden. Onder andere in maart, februari en januari werden al noodpleisters uitgebracht. De volgende patchronde na dinsdag zal, volgens schema althans, 16 oktober plaatsvinden. Java kampte de laatste jaren regelmatig met ernstige beveiligingslekken.

Reacties (99)

Wat mij verbaast is dat Tweakers.net niet meld dat ze vanaf heden ook een aparte Server JRE hebben.
Dit is dus de Java JRE minus de browser plugin en auto-update.

Voor veel gebruikers is dit de beste keus.
Die hebben niet de browser plugin nodig. (tenzij ze een cursus online volgen bij IBM )
Ook weer een indicatie dat ze de betrouwbaarheid van Java willen verhogen door te wijzen op het feit dat de meeste problemen toch in die plugin zit en niet in de rest van het systeem.

Grappig, wist ik ook niet.

Niet zo vreemd, want met al die verschillende versies is ook hun aanbod net zo lomp en onhandig als de software zelf .

Is de codebase van java dan zo slecht of is het gewoon software die te complex is geworden doordat deze op zovele platformen moet draaien? Ik snap niet goed hoe het kan dat je bijna elke maand met dit soort patches moet komen voor je product.

Het issue is eerder dat Java tegenwoordig voor een compleet ander doel gebruikt wordt dan men oorspronkelijk voor ogen had. Java was oorspronkelijk bedoeld om applicaties in een sandbox in de browser te draaien met behulp van de applet plugin. Door o.a. de concurrentie met Flash is Java echter juist een omgeving geworden die veel meer aan de server kant gebruikt wordt, Java applets komen tegenwoordig nog vrij weinig voor.

In tegenstelling tot applets en Web Start applicaties, draaien server-side en desktop applicaties meestal niet binnen een sandbox. De security issues die nu naar voren komen zijn vrijwel altijd issues met de sandbox. Als ik het goed heb begrepen zijn de meeste security issues in Java problemen in implementatie classes van Sun/Oracle die reflection gebruiken en waar men geen rekening houdt met de mogelijkheid dat deze code ook door sandboxed code aangeroepen kan worden. Sandboxed code kan hier in sommige indirect reflection calls laten uitvoeren om bijvoorbeeld method references te krijgen uit privileged code. Deze method references kunnen weer gebruikt worden om code aan te roepen die normaal gesproken geblokkeerd worden door de sandbox.

Ik dacht dat men in Java 8 iets structurelere maatregelen wil gaan nemen om dit soort problemen met de sandbox te voorkomen. Toch vraag ik het mij af of het misschien niet beter is om de applet plugin en Java Web Start te deprecaten. Er zijn helaas heel wat sites en bedrijven die daar gebruik van maken, maar ik kan het mij niet voorstellen dat het nog rendabel is om die code bij te houden. Applets en Web Start zijn maar een extreem klein deel van het Java eco-systeem, maar ze leveren de rest van het Java eco-systeem, waar deze issues niet spelen, wel een slechte naam op.

[Reactie gewijzigd door MetroidPrime op 15 juni 2013 20:04]

Snap niet hoe dit een +2 kan krijgen. Java is al vanaf de conceptie bedoeld geweest voor zowel applet-based als stand-alone applicaties. Het applet-gedeelte daarvan heeft in de loop der jaren geleidelijk een teruggang gezien zodanig, dat het tegenwoordig eigenlijk alleen nog in web-based bedrijfssoftware gevonden wordt.

Java was oorspronkelijk bedoeld om applicaties in een sandbox in de browser te draaien met behulp van de applet plugin.

Voilgens mij was het oorspronkelijk bedoeld als een programmeertaal voor allerhande elektronische apparaten, zoals televisies, afstandsbedieningen en koelkasten. Het is alleen een beetje uit de hand gelopen.

wel eens een patch overzicht van windows gezien?

Inderdaad, it's quite the other way around.

Oracle heeft Java eigelijk 'gekocht' (door heel Sun, de vorige eigenaar van Java, te kopen) voor z'n eigen interne apps. Voor een lange tijd leek het ze niets te kunnen schelen wat er met Java 'in the wild' gebeurde.

Tegenwoordig heeft ervoor gezorgd dat Java een enorm slecht imago heeft. Waar het een paar jaar geleden nog een extreem populaire taal is, is dat nu voorbij. Java zou een beveilinginslek zijn - en dat is het ook, in de browser dan.

Oracle heeft pas een paar maanden geleden z'n strategie veranderd en begint nu pas weer met het patchen van lekken. Ik denk eigelijk dat het al te laat is, want dit soort berichten laten het ook een beetje lijken dat Java een lek mandje is, terwijl dit juist bugfixes zijn.

Maar goed, Java's toekomst is voornamelijk somber. In de browser heeft niemand het meer (nodig), dankzij HTML5 en ... hoe erg ik het ook haat, Flash.

Voor de desktop is het niet meer zo van belang. Bijna iedereen heeft Windows tegenwoordig, dus het hele platform-probleem van Java is er niet meer zo sterk. Met Windows komt C#, wat eigelijk Microsofts Java is, maar dan zonder het slechte imago. Natuurlijk werkt C# lang niet zo goed op andere platformen en is er geen officiele ondersteuning van MS voor dit soort platforms.

Jammer eigelijk, want sinds Java 'SE' zijn ze echt snel/goed. Met IDEs zoals Eclipse is Java op papier een programmataal die goed mee kan met de anderen. Als dat nou ook voor z'n imago gold ...

Ik vind reacties op Tweakers.net altijd zo leuk. Ze lijken volledig geinspireerd op andere berichten op Tweakers.net en in geheel geen relatie te hebben tot de werkelijkheid.

De toekomst van Java is helemaal niet somber. Aan de server kant wordt er zeer veel gebruik gemaakt van Java. Dat je het in de browser niet meer tegenkomt komt ook niet alleen doordat Java onveilig is. De trend is sowieso om veel meer te doen met HTML/Javascript. Dat zie je ook in het naderende einde van Flash. Een omgeving als Flash/Java is gewoon niet meer nodig in de browser omdat de javascript en render engines inmiddels een stuk beter zijn dan 10 (!) jaar geleden toen Java en Flash nog de klok sloegen.

Tijden veranderen en daar is niks mis mee, maar Java afschrijven alleen omdat je het in je browser niet meer tegenkomt is nogal kortzichtig.

Alle implementaties zijn op de client kant een drama, Java, Flash en Silverlight. In de backend is Java goed te doen, maar op client kant heeft het zo veel nadelen, alleen het erge is, je kan soms niet zonder.

Helaas hebben we te maken met meerdere soorten client systemen waarbij een universele taal en vm nodig is. Maar dat neemt niet weg dat dit soort zaken een drama zijn vanuit het perspectief van de eindgebruiker.

C# geen slecht imago? Sorry hoor, maar ik ken maar een paar mensen die het daadwerkelijk gebruiken. De rest gebruikt of C++ of Java, omdat multiplatform zonder extra vertragende runtime (Mono), waardoor het langzamer is dan Java [bron]

Hou er trouwens ook rekening mee dat er erg veel servers zijn die java gebruiken, omdat netwerken er heel makkelijk in is.

Ja, het kent wat veiligheidsprobleempjes, maar dat komt voornamelijk omdat de orginele codebase van voor 2000 stamt, ze wel backwardscompatible willen zijn maar ook (zeer begrijpelijk) nieuwe dingen willen toevoegen. Sinds Oracle java weer serieus neemt en regelmatig van patches voorziet, er binnenkort multiple inheritence en betere multithreading komt, zie ik juist een mooie toekomst voor Java.

Ontwikkelaars voor beide platformen zijn even gewild en in ruwweg gelijke getale present. In het wild zal een Java programmeur echter zelden een .Netter zien en vice versa. Een der beide platformen zal dus wel een slecht imago hebben afhangend van je omgeving.

.Net is in de bedrijfswereld namelijk wel razend populair in de meer administratieve hoek van zaken, deels waarschijnlijk door ingebouwde ties met Microsoft's SQL platform en deels misschien door iets simpels als de pijnloosheid waarmee men een UI ontwerpt in Visual Studio, hehe.

Verder zal de integratie en prestaties op het Windows-platform ook wel van enige invloed zijn; hoewel de JRE sneller is dan Mono, loopt het .Net Framework rondjes om de JRE (wat net zoals JRE en Mono een soort van bytecode-etende VM is, ze zijn alle drie één pot nat eigenlijk.)

Een link in de OP naar een enumeratie van de Java-lekken had wel reuze-interessant geweest, ik ben nieuwsgierig naar waar het fout kan gaan op zo'n platform en misschien inspireert het me wel tot het prikken van .Net, ik vind het namelijk altijd wel wat curieus hoe je nooit een kik hoort over de kwetsbaarheden van het .Net-platform, het stamt immers ook al uit de vroege 2000's en is ook nog volledig achterwaarts-compatibel.

Edit: De Java-kwetsbaarheden zijn als 'Confidential' gemarkeerd zo te zien. Had ik kunnen weten.

[Reactie gewijzigd door strandtentje op 15 juni 2013 17:20]

hoi Rob

Natuurlijk zal het per millieu verschillen en natuurlijk hebben beide z'n voor en nadelen. Ik ben persoonlijk voornamelijk vanuit Linux aan het redeneren omdat ik daar op programmeer en het gros van de servers Linux draait. Op Linux is Mono helaas een verplichting voor C#.

Ik vind het zelf ook curieus dat .NET geen enkel lek lijkt te hebben. Natuurlijk gaat mijn complottheoriehersenen meteen aan de slag met het feit dat java semi-open source (immers OpenJDK implementatie?) is waardoor er makkelijker fouten gevonden kan worden, maar goed

En indeed UI's zijn ruk om te maken, maakt (imo) weinig uit welke taal je er ook voor neemt.

[Reactie gewijzigd door Gropah op 15 juni 2013 17:45]

vraag het me af of C# zoveel sneller is dan Java. Met Java heb je wel het voordeel dat je niet aan een windows omgeving gebonden bent en je programma prima op elke unix draait.

Verbaas me trouwens nog steeds over het deel van de reacties hier. Leer eens het verschil tussen serverside java en client java. Aan de client met zijn appletjes mag het idd ondertussen wel dood want daar heeft het geen bestaansrecht meer. Maar aan de server kant is het prima op zijn plaats.

In python en ruby heb je wel snel iets op het scherm maar als het om high performance gaat en beheer van een grote code base dan kom je toch gauw in de knoei met python en vrienden.

De code van windows zal wel ietsjes groter zijn, dus statistisch gezien ook meer kans op bugs.

Tuurlijk wel, maar Windows is een heel OS van enkele GB groot met een groot scala aan tools, Java is een raamwerk, een enkele tool van enkele MB groot.

In mijn ogen: ja en nee.
De code kan eigenlijk gewoon niet meer volgen met de ontwikkelingen.
Doordat java eigenlijk op alles wordt gebruikt is het natuurlijk handig voor hackers om hier hacks/exploits voor te gaan zoeken.

Maar zoals hieronder wordt gezegd, windows patch ook elke x weken
Je kan nu niet eenmaal code onmiddellijk van de eerste keer 100% bugfree maken.

Gaan we nu serieus patches van een runtime voor een programmeertaal vergelijken met een compleet OS? Hou de vergelijking dan eerlijk en beperk je vergelijking dan tot het .NET framework..

Via apt krijg ik ook wekelijks updates voor applicaties binnen. Is Linux daarom net zo lek als Java dan?

Maar 37 verholpen remote exploits in drie maanden tijd in een runtime van een programmeertaal is wel heel erg extreem.. Zitten de drie noodpatches van de afgelopen maanden hier ook in, of is dit een aanvulling?

Een wekelijkse update ronde is misschien iets te veel, maar ik denk dat het wel verstandig is dat Oracle net als Microsoft met een maandelijkse patch ronde komt. Hoewel het aantal exploits welke je verhelpt gelijk is het nogal een flink verschil of je update 40 of 13 exploits verhelpt. Het draait allemaal om perceptie en op dat vlak doet Java het gewoon niet goed..

En ja, ook bij het .NET framework worden vaak patches uitgegeven...

Het zou denk ik voor iedereen beter zijn als ze een wekelijkse patchronde zouden doen.

Wil jij wekelijks een Ask-toolbar weigeren?

Oracle zou eens een auto-updater moeten maken! Maar ja ... geld ...

Download van java.sun.com daar zit geen ask-toolbar in de setup.

Waarom zou Oracle een autoupdater moeten schrijven? Alle voorname linux distro's hebben een centraal updatemechanisme waar alle softwarevendors (ook die van proprietaire software) op in kunnen haken. Als je het mij vraagt zou Microsoft dat ook moeten doen. Dan zou je in een keer klaar geweest zijn...

Ja, een van de meest briljante uitvindingen van de Linux wereld: repositories. Fantastisch systeem. Beetje jammer dat als zowel Microsoft als Apple dan eindelijk eens met een soort van software-repositories op de proppen komen, dat weer een systeem moet zijn met een voornamelijk commerciele insteek, de app stores.

Ik snap dat zij geld moeten verdienen, maar update-beheer is in mijn optiek een redelijk integraal onderdeel van een besturingssysteem, en zowel op Mac OS X als op WIndows is dat uitermate slecht geregeld, met uitzondering van de core elementen van het OS zelf. Hierdoor installeert praktisch elk omvangrijk pakket zijn eigen update beheerder wat weer een flinke bult aan extra nutteloze services oplevert, die op Linux gewoon niet nodig zijn omdat de package beheerder het daar al regelt

Persoonlijk heb ik mijn applicaties graag onafhankelijk van het OS. Bij repositories ben je afhankelijk van de maintainer en dat leidt nog wel eens tot ergernissen, van kleine versie achterstanden, tot complete naamsveranderingen van applicaties (Iceweasel) en geheel missende applicaties.

Mja wat nou als Windows (of Linux) gewoon een software manager had? Stel je wilt Java hebben, je voegt de Oracle source toe (met een mooie "source:http://oracle/whatever" URL), installeert Java en het OS update elke keer netjes al je software uit die sources.

Ja, dan moet Oracle z'n software source maintainen,... maar ze moeten nu ook hun website maintainen.

Lijkt me een vele malen betere opzet dan losse .exe (of .msi) files downloaden installeren, en 4 verschillende background updaters hebben, bij elk programma dat je opstart pop-ups dat die wel wil updaten op het moment dat je er mee wilt werken of hopeloos verouderde versies met verschrikkelijke vulnerabilities.

Heb het in het algemeent niet zo op Linux, maar als ze één ding goed geregeld hebben, is het wel het installeren van software.

Het enige probleem met Linux is dan weer wel dat iedereen z'n eigen dingen wil hebben. Ze hebben massaal last van het NIH syndroom. Met portage, apt (aparte voor Ubuntu en Debian natuurlijk!), yum, en andere systemen.

Iceweasel is specifiek van naam gewijzigd, omdat er merkrecht leunt op het firefox icoon, iets wat niet schikt met de Debian Guidelines

tevens, der is ook zoiets als de restricted repositories, waarin non-free software te vinden is

Ja want Libs heten vaak ook niet NET wat anders vanwege historische redenen bij specifieke distro's.
Waardoor je handmatig troep mag gaan zitten aanpassen.
Dit zijn de kleine dingetjes waardoor je huistuin en keuken gebruikers beter niet linux kan laten gebruiken.

Misschien kan je je probleem toelichten - gezien ik het niet kan ontdekken.

a) Niemand verplicht jou repositories te gebruiken
b) Je kan prima je eigen repositories maken
c) Leveranciers van (closed source/proprietary) software op linux hebben vaak eigen repositories die je dus gewoon kunt toevoegen aan je package manager en dan de updates direct krijgt van de leverancier van het pakket. Bekende voorbeelden zijn bijv. de vmware tools en opsview.

Overigens is het binnen een release over het algemeen niet zo dat applicaties ineens verdwijnen (ik heb het nog nooit gezien in ieder geval - behalve in bijv. gentoo maar dat is een rolling release en er is dus geen gentoo 7, gentoo 8, etc.).

Eens met @claudandus, daarnaast kan je gemakkelijk iceweasel verwijderen om alsnog de vanilla firefox te installeren

je kunt de runtime ook gewoon downloaden vanaf OTN; dat is gewoon een "offline" installer zonder die gare toolbar.

http://www.oracle.com/tec...vase/downloads/index.html

(pak de download onder JRE)

Een auto-updater die standaard die Ask-toolbar meegeeft ja.

Die arme artsen, kunnen ze weer wachten tot ze met hun UZI-pas weer 'veilig' kunnen inloggen....

Die Ask-toolbar, dat klere ding. Je kunt het gewoon malware noemen. Ik wil het kreng niet. Wat er bij komt, laatst heeft mijn vader zijn PC geupdate, mag ik op afstand uit de beschrijving opmaken dat er per ongeluk de Ask-toolbar is bijgevoegd.

Iedereen zou gewoon Java moeten ontvluchten. Lost deze 2 problemen in 1 keer op

Ik denk niet dat Oracle een arm klein bedrijfje is.

Ze zijn alleen niet gemotiveerd met Java als Microsoft met .NET/C#.

ninite.com/java geen toolbar te bekennen...

De reactie is misschien een beetje ongenuanceerd maar het is wel waar. Oracle heeft Sun overgenomen juist vanwege Java.

Het is dus echt niet zo dat Oracle het belang van Java niet inziet.

Nou, ik denk dat Oracle ook Sun overgenomen heeft vanwege de hardware, zodat ze nier meer afhankelijk waren van HP voor hun exa- hardware lijn...

Daarom dat ze de hardware (SPARC) zo verwaarsloosd hebben zodat zowat geen enkele klant nog bij hun aanklopt.
Oracle is of was inderdaad enkel ge-interesseerd in de de Exa-data/Exa-logic systemen die "big bucks" opbrengen... en die draaien op x86. En raad eens waar Oracle nu die x86 gaat halen: http://www.computerweekly...astructure-for-its-future

Misschien eens tijd om van Java af te stappen in plaats van Patchen. Bij ieder bedrijf waar ik langs kom is het alleen maar drama, beheerders en gebruikers hebben het gehad met Java.

• Java kost veel resources op systemen;
• Java is veelal onveilig;
• Software werkt vaak niet meer na een Java Patch;

Java is populair bij ontwikkelaars, maar Java is vanuit een gebruikers-/beheerdersoogpunt meer een noodzakelijk kwaad.

Er is wel een verschil tussen Java op de client en op de server.
Wij bouwen webapplicaties die draaien op een applicatieserver. De klant hoeft geen Java te installeren, het staat alleen op de server. Ik zie dan ook niet in waarom wij van Java af moeten stappen.

omdat het dus onveilig is?

Dan moet je lezen waar de fouten in zitten. Die zitten in de browser plugin!
Iets wat je dus niet gebruikt op de server.
Ze hebben daarvoor (vanaf nu) speciaal een Server JRE download gemaakt.

Dat kun je niet zo zeggen. Die vulnerabilities zitten vaak in de plugin waarmee Java-applets in de browser gedraaid worden en dan kun je er vaak ook alleen onder Windows nog maar kwaad mee doen. Daar heb je dus niets mee te maken als je Java alleen maar op een dichtgetimmerde server onder Linux draait.

Het zou voor iedereen beter zijn als (vooral web) ontwikkelaars het niet meer zouden gebruiken, dan heeft niemand het meer nodig.
Daarnaast is het een goed idee om Java te verwijderen als je het niet nodig hebt en als je het toch nodig hebt voor b.v. Minecraft, Java in je browser geheel uit te schakelen, daarmee voorkom je een heleboel ellende.
Safari is hiermee al op de goede weg om Java in de browser na 30 dagen niet gebruiken uit te schakelen.

Probleem is dat grotere bedrijven specifieke software hebben dat is geschreven in Java. In het verleden een van de weinige platform-onafhankelijke software.

Zolang zij hun software niet herschrijven dan zal het blijven bestaan.

We hebben hier ook een aantal proggies geschreven in Java, werkt alleen met oude IE en je moet norton plugin ook uitschakelen anders start het programma niet op. Gezien de slechte ervaringen in het verleden blijven we die ook nog een tijdje gebruiken totdat heel het netwerk opnieuw wordt opgebouwd from scratch. Tot heden is het altijd uitbreiding op uitbreiding maar enkele servers draaien al ruim 10 jaar.

De planning is ergens volgend jaar inventariseren en tussen kerst en nieuwjaar een nieuw netwerk ivm vakantie. Ruim anderhalf tegenaan kijken nog...

En als die grotere bedrijven dat dan ook netjes platform-onafhankelijk hadden geschreven dan had je de JVM zo kunnen upgraden... is nou niet echt sprake van backward-incompatible changes in de java-wereld (tenzij je het over software hebt die komt uit de tijd van java 1.0 met de toenmalige awt natuurlijk, die is in 1.1 inderdaad stevig over de kop gegaan. Voor de rest bij mijn weten geen incompatibilties geintroduceerd voor pure java programma's (lees: netjes uit de internal packages wegblijven en alleen de APIs gebruiken))

Wetenschap maakt ook nog veel gebruik van java.

Ik vraag me eerder af hoeveel nieuwe veiligheidsrisico's er met deze patch bijkomen. Bij JAVA is het dweilen met de kraan open. Deze software staat in Secunia PSI al sinds jaar en dag op een (bijna) maximaal veiligheidsrisico. Ik heb niet het gevoel dat er echt wat verbeterd is de laatste 5 jaar.

Je kunt die software waarschijnlijk beter verwijderen als je deze niet persé nodig hebt.

Wat ik trouwens niet snap is dat een heleboel mensen de gevaren van Java onderschatten. Door de melding Java update available te negeren

Begin me niet over de Java update meldingen.
verschillende versies, verschillende meldingen en verschillende manieren van reageren. En alle meldingen voor de gebruiker uit zetten is verre van gemakkelijk. Het zelfde geld voor bedrijfsbreed patchen van Java op werkstations.

Het zelfde geld voor bedrijfsbreed patchen van Java op werkstations.

Hier zijn zat oplossingen voor, pakketten als Dell Kace en Microsoft System Center Configuration Manager...

[Reactie gewijzigd door Dylan93 op 15 juni 2013 20:27]

De andere kant van de medialle is nu eenmaal dat bepaalde andere software niet met JAVA XX of lager werken kan.
Die _keuze_ of melding minimaal, moet er dus altijd zijn.

Het mooie is dat als een bank een keer een gedupeerde klant zijn geld niet wil vergoeden...
hoeft die alleen maar te wijzen op hoe banken zelf (niet eens-) ' up to date zijn' .

Aan de andere kant, heel veel software werkt met Java versie x ud xx MAX. Het probleem met Java is dat er niet alleen minimale versies vereist zijn, maar ook maximale versies.

Weet je wat nou zo grappig is, toen ik nog Java geinstalleerd had staan, kreeg je idd iedere dag zo'n melding, en dan klikte je erop, kreeg je een UAC popup, en dan vervolgens gebeurde er niets.

De kritieke patch heeft betrekking op versie 5, 6 en 7

5 en 6 waren toch al end of support ?

http://www.oracle.com/tec...n/autoupdate-1667051.html

The last publicly available release of Java 6 will be in February of 2013 with the release of Java SE 6 Update 41 (Java SE 6u41).

Al hebben ze u43 en u45 ook al uitgebracht, dus geen idee welke waarde deze eos notice heeft ?
Volgens http://en.wikipedia.org/wiki/Java_version_history is u45 weer de final public update.

[Reactie gewijzigd door DDX op 15 juni 2013 16:54]

Kennelijk heeft men zich bedacht ofzo, want als je op deze site kijkt, zie je dat je gewoon nog Java SE 6 Update 45 publiek kunt downloaden. Dat is dus nog niet de versie met deze patch, maar wel de meest recente die beschikbaar is.

http://java.com/en/download/faq/java_6.xml

Java SE 6 End of Public Updates
Oracle will no longer post updates of Java SE 6 to its public download sites. All Java 6 releases up to and including 6u45 will be moved to the Java Archive on the Oracle Technology Network, where they will remain available but not receive updates.

Benieuwd of ze zich weer gaan bedenken.

[...]


5 en 6 waren toch al end of support ?

http://www.oracle.com/tec...n/autoupdate-1667051.html

[...]


Al hebben ze u43 en u45 ook al uitgebracht, dus geen idee welke waarde deze eos notice heeft ?
Volgens http://en.wikipedia.org/wiki/Java_version_history is u45 weer de final public update.

Het probleem is dat met name Java 6 nog heel veel in gebruik is. Ik merk dat veel medische software op cliënt kant wel met Java 6 werkt maar niet met Java 7. Dit houdt in dat even naar Java 7 upgraden niet kan. En om Java nu in een ThinApp of iets dergelijks te stoppen is ook een drama.

Wanneer ik zie hoe veel werk het is aan test kant en implementatie kant in bijvoorbeeld een deftige Citrix omgeving of bij 2.000+ werkstations dan is het hopeloos. En niet ieder bedrijf heeft de mogelijkheid om met provisioning van RDS/XenApp/XenDesktop te werken vanuit financieel oogpunt.

En ja, je hebt RES Automation Manager/SSCM en andere tooling om software bij te werken, maar in een complexe omgeving is Java gewoon een drama. Niet eventjes een zoek Java Update 6.41 en vervang naar 6.42 omdat je de kans hebt dat het allemaal niet meer werkt.

Overigens geldt het zelfde met IE, Firefox en Chrome. Dat is in veel bedrijven ook niet even simpel bij te werken door de gebruikte software. Zelfs een bepaalde IE 8 en IE 9 kb's geven soms problemen net zoals met FF.

Prima dat Oracle actief bezig blijft met het dichten van lekken. Maar ik snap niet dat er zoveel blijven opduiken. Kunnen ze heel de handel niet een keer echt goed testen/controleren/aanpassen ?

Tegen dat ik alle servers en pc's heb kunnen updaten staat er alweer een nieuwe klaar. Bezigheidstherapie van Oracle?

Gevalletje Sun die jarenlang de client side van Java links heeft laten liggen. Oracle is nu druk bezig de ellende bij te werken, maar dat gaat dus niet zomaar in een avondje.

Ik ben het niet eens met de beslissingen die Oracle doorgaans maakt, maar de hoeveelheid kak die ze over zich heen krijgen op dit gebied is geheel onterecht. Ze doen het juist erg goed, tegen mijn verwachtingen in.

Maar nog steeds ben ik van mening dat in Java 8 het hele applet gebeuren gewoon moet verdwijnen. Wat een drama.

Ze doen het juist erg goed, tegen mijn verwachtingen in.

Nauja, dat was ook niet spontaan... Na hun fuck-up vorig jaar zijn er vele, ook grote organisaties die java op een zwarte lijst hebben gezet.

Oracle heeft nog wat goed te maken, ze moeten zich opnieuw bewijzen.

Lekken zul je veel sneller vinden in een framework dat door heel HEEL veel mensen gebruikt worden en op veel platformen...

En jij bent heel goed als je van te voren kunt bepalen wat een lek is en wat niet, een heel mooi voorbeeld is SQL injection, tot jaren geleden was SQL injection niet echt iets dat bekend was, maar nu is het wel een zo bekend 'lek' dat je je eigenlijk moet schamen als zoiets nog gebeurd, maaaaar je ziet het nog steeds veel voorkomen in productie....

Zo'n rijkelijk late patchronde bevestigt het mijn keuze om JAVA nog altijd links te laten liggen.
Ironisch genoeg dringen ze de gebruikers vervolgens aan om deze patch zo snel mogelijk te installeren, alsof de beveiligingslekken pas gisteren bekend zijn geworden.

Ironisch genoeg dringen ze de gebruikers vervolgens aan om deze patch zo snel mogelijk te installeren, alsof de beveiligingslekken pas gisteren bekend zijn geworden.

Nee, maar zodra de patchnotes zijn gepubliceerd, worden de lekken wel veel bekender en dus gemakkelijker te misbruiken.

En weer al eens...

Goed dat ze de lekken dichten, maar er zouden er in eerste plaats gewoon niet zoveel mogen voorkomen. Dit gaat wel degelijk ten kosten van de reputatie van Java.

Waarom staan nergens in het bericht verwijzingen naar publicaties of bronvermeldingen? Ik ben wel benieuwd over wat voor lekken het precies gaat. Voordat we allemaal gaan schreeuwen dat Java rommel is zou het namelijk best nuttig zijn om vast te stellen om wat voor edge cases het gaat. Ik kan me slecht voorstellen dat het om lekken gaat die blootgesteld worden als je een JRE op je desktop PC-tje hebt draaien....

En nu maar hopen dat alle bedrijven en organisaties hun Java-gebaseerde toepassingen snel aan de praat krijgen met deze nieuwe versie. Zoals de huisartsen die noodgedwongen al een versie achterlopen, maar ik weet ook een Amerikaans IT-bedrijf (nee ik noem geen namen... waarvan de werknemers nog op Java 6u33 zitten omdat de VPN software én het Oracle ERP systeem anders niet functioneren.