Nets forklarer manglende Java-test: Vurderede ikke, det var nødvendigt

Opdateringerne af Java har altid været bagudkompatible, så det var ikke nødvendigt at teste dem med NemID, lød vurderingen hos Nets DanID. Første melding til Version2 var i øvrigt forkert.

Forklaringen på, at Nets DanID blev ramt af Java-problemer, da Java 7 update 45 kom på gaden den 15. oktober, var simpel: NemID var ikke blevet testet med den nye opdatering.

Læs også: Årsagen til NemID-kaos: Nets testede ikke Java-opdatering

Det har Nets forklaret i en redegørelse til Digitaliseringsstyrelsen - men hvorfor valgte Nets ikke at teste mod nye Java-opdateringer?

»Historisk set har Java-opdateringerne altid været bagudkompatible, så det har ikke været noget, vi har vurderet var nødvendigt at teste. Men det er klart, at det er en praksis, vi nu ændrer, da det øjensynligt ikke længere er sådan,« siger Søren Winge, pressechef for Nets DanID, til Version2.

Datalogen Christian Panton har ved at analysere NemID-appletten fundet tegn på, at der bliver brugt et internt API via reflections, hvilket ikke er meningen fra Oracles side. Alt tyder derfor på, at NemID fik problemer med den nye opdatering, fordi Oracle tilføjede ekstra sikkerhed, der skulle beskytte det interne API mod brug fra andre end Java selv.

Læs også: Nets brugte 3 døgn på at tilføje 2 linjer kode til NemID

Men Nets ønsker ikke at be- eller afkræfte den forklaring eller på anden måde fortælle om, hvad der gik galt.

»Vi ønsker – først og fremmest af sikkerhedsmæssige årsager - ikke at kommentere konkret på, hvordan vi koder NemID-løsningen, og heller ikke, hvilken kode der var årsag til problemerne mellem Java 7_45 og NemID,« skriver Søren Winge til Version2 og uddyber mundtligt:

»Vi synes ikke, at der er nogen grund til at diskutere i detaljer, hvad vi laver i Java,« siger han.

Da problemerne opstod i midt-oktober, lød Søren Winges foreløbige bud på en forklaring, at der ikke var blevet testet godt nok. Han sagde dengang til Version2: ’Vi får typisk en beta-version af opdateringerne fra Oracle, så vi kan teste den.’

Læs også: Nets om Java-problemer: Vi har måske ikke testet godt nok

Men der var altså slet ingen test, og den udtalelse var en fejl, baseret på en misforståelse mellem nye versioner af Java og nye opdateringer af Java.

»Det var forkert, for jeg havde simpelthen misforstået. Det var en forkert tilbagemelding fra min side. Vi har adgang til pre-releases af nye versioner af Java, men ikke, når der kommer nye opdateringer af Java,« siger pressechefen.

Indtil nu har Nets faktisk slet ikke haft adgang til opdateringerne før alle andre.

»Vi har ikke tidligere fået adgang til de kvartalvise opdateringer, så af den grund kunne vi ikke teste. Men det var heller ikke noget, vi har haft en procedure for,« siger Søren Winge.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kasper Hansen

Ja, det er ærgelige nyheder her fra Nets. Det er selvfølgelig rigtigt rart at de er ærlige, men det er også skræmmende at de ikke har haft en procedure for tests, og blot stolet på et Amerikansk firma beholder bagudkompabiliteten. Tænk at basere oppetiden på Danmarks IT-infrastruktur på et Amerikansk firmas udokumenterede praksis - det burde være utænkeligt.

Anyway, se at få de procedure op og stå! Og det er ligegyldigt om det er Java eller ej, der skal testes ved alle ændringer i stakken - kun dybden at testen kan varieres, ikke om der skal testes eller ej!

  • 14
  • 0
Michael Thomsen

Når man baserer sin software på Java og ovenikøbet benytter ikke-officielle API'er, så er man komplet idiot når man kan udtale:

Historisk set har Java-opdateringerne altid været bagudkompatible, så det har ikke været noget, vi har vurderet var nødvendigt at teste.

I har med andre ord kun været ualmindelig HELDIGE indtil nu.

  • 10
  • 0
Allan Høiberg

Da Java kom frem, var ét af hovedargumenterne så vidt jeg husker at man kunne skrive sin kode én gang, og derefter afvikle den stort set overalt hvor der var Java.

Siden da har jeg oplevet firewall-administrationssoftware holde op med at ville snakke med sin administrator, RAID-controllersoftware begynde at advare om at nu er det snart slut, og selvfølgelig NemID blive besværlig.

Har Java overhovedet nogen eksistensberettigelse når det kommer til stykket, sådan lidt sat på spidsen? Det tyder i hvert fald ikke på at hovedargumentet holder i praksis.

  • 5
  • 3
Kim Hansen

Ganske enkelt "Arrogance" - det er hvad ord man kan sætte på dette.. Når man binder et helt lands digitale ID op på et firma - så må man sgu også forvente at de er opgaven moden - og det synes jeg ikke ligefrem er det der udstråles af denne artikel...... Det er sgu ligesom med "mobil nem-id" - som man har lovet flere år - og som endnu ikke er klart - det er altså ikke iorden...

  • 4
  • 0
Andreas Vinter-Hviid

»Vi har ikke tidligere fået adgang til de kvartalvise opdateringer, så af den grund kunne vi ikke teste. Men det var heller ikke noget, vi har haft en procedure for,« siger Søren Winge.

Er oracles java og openJDK ikke næsten samme kode(openJDK er i hvert fald reference implementationen)? Forgår udviklingen af openJDK ikke åbent så man bare kan downloade den nyeste kode fra repositories?

Jeg må indrømme at jeg ikke er helt sikker, men hvis det er tilfældet giver det vel ikke mening at snakke om hvornår man for adgang til nye versioner efter som alle har adgang med det samme...

  • 1
  • 0
Helge Svendsen

Nu isolerede problemerne sig til Oracles version af java. OpenJDK kørte gennem hele forløbet ganske OK.

Plugin til browseren er forskellig kodebase mellem OpenJDK og Oracles Java.

I øvrigt mener jeg, at man i service releases bør kunne forudsætte samme behaviour. Dvs. man burde kunne forvente at Oracle havde bumpet i det mindste det sidste tal i release nummeret, hvis de laver om i funktionaliteten, og ikke bare i implementeringen.

Det er vel de krav, man stiller til andet software.

Det ændrer dog ikke på, at dette burde være fundet i en (automatiseret) test.

  • 3
  • 0
Helge Svendsen

Det holder .. Serverside :-D

Build once run anywhere kan aldrig fungere på clienter. Bare det at der er vidt forskellige HID interfaces at have at gøre med sætter næsten i sig selv en begrænsning for det.

Men java var og er en kæmpe success serverside, hvor man vitterligt kan køre det samme kode på både Linux, unix og windows, forudsat det er lavet korrekt.

Jboss, Tomcat, JEE / Spring MVC stacken er alle eksempler herpå. Og i dag ikke kun til java men også Groovy, Scala og så videre.

  • 2
  • 0
Robert Larsen

»Vi synes ikke, at der er nogen grund til at diskutere i detaljer, hvad vi laver i Java,« siger han.

Nej, det ville jo være frygteligt hvis koden blev lagt ud til offentlig beskuelse, så nogen kunne se deres klyt og sige, "det der vil ikke virke med Java 7 u45". Det ville jo være skrækkeligt, hvis nogen kom og afhjalp deres elendige praksis for dem. PIIIIINLIGT ligefrem.

Så fortsæt endelig med at holde jeres skidt så skjult som muligt. Security by obscurity FTW.

Sarkasme KAN forekomme.

  • 3
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize