OpenOffice 3.2 dicht Microsoft-gaten

Ik suggereer helemaal niks, dat lees je er allemaal zelf in. Als het niet waar is wat ik hierboven schrijf, wijs me daar dan even op en leg even uit waar ik de mist in ga. Voorlopig heb je dat nog niet gedaan, maar krijg ik wel weer een term als 'belachelijk' naar m'n hoofd. Dat deert me allemaal niet zoveel, maar het zou zoveel beter zijn wanneer het hier eens over de inhoud ging.

Echt belachelijk.Dat heb ik ook wel eens gevonden. Zelfs bij herhaling aangegeven dat de situatie problemen zou geven. Maar als je vervolgens opdracht krijgt om het toch zo te bouwen, dan beslist toch de betaler. En dat je achteraf toch te horen krijgt dat je eigenlijk wel gelijk had is dan alleen een schrale troost.

Nogal een slechte gewoonte trouwens dat schelden. Ik merk dat de sfeer weer hard achteruit gaat. De sfeer is hier vaak al niet best, maar nu is het ronduit grimmig.

Hoezo is het per definitie onzin? Als de spec van een formaat zegt:

"The contents of tags <exe>...</exe> should always be executed"

...dan moet die code dus uitgevoerd worden, veilig of niet. Triviaal voorbeeld, maar het is geenszins onmogelijk. De Javascript-spec (ECMAScript, ok) zegt niks over dat het onmogelijk moet zijn cross-domain scripts aan te roepen, toch vinden we dat inmiddels niet zo'n goed plan meer.

Beste bliep, ik zal proberen het verhaal nader te verklaren op een manier die geen van beide betrokken partijen (OOo én Microsoft) bij voorbaat vrijwaard van schuld:


Specificatie:
Een 'specificatie' van een bestands formaat is een raamwerk voor ontwikkelaars om ze de mogelijkheid te geven dat betreffende formaat te kunnen implementeren.
Hierbij is het de verantwoordelijkheid van de maker van de specificatie om deze specificatie veilig te maken.


Implementatie:
Voor ontwikkelaars is de veiligste methode om te zorgen dat hun software kan omgaan met *alle* bestanden van dit formaat - ook als deze door andere software zijn aangemaakt - om de specificatie zo letterlijk mogelijk te implementeren.
Hierbij is het de verantwoordelijkheid van de maker van de implementatie om deze implementatie veilig te maken.


In a perfect world:
Het in theorie mogelijk is dat een ontwikkelaar zelfstandig de gehele specificatie onderzoekt op mogelijke ontwerpfouten. Het is in theorie ook mogelijk dat de ontwikkelaar hierbij *alle* ontwerpfouten in de specificatie onderschept.


In de real world:
In de praktijk is dat echter helaas niet zo gemakkelijk als we allemaal het liefst zouden willen.


Met optimisme over de kunde van de ontwikkelaar:
Laten we aannemen dat de ontwikkelaar alle ontwerpfouten heeft gevonden. Dan betekent dit dat iedere andere implementatie van de betreffende specificatie mogelijkerwijs één of meerdere van deze lekken implementeert. Op het moment dat dat gebeurt, kan je een keuzes maken:

1: Documenten die het lekke onderdeel van de specificatie gebruiken volledig weigeren.

2: De lekke specificatie klakkeloos overnemen met alle risico's van dien.

3: Een tussen-oplossing zoeken die het lek zo goed mogelijk vermijd bij het exporteren naar het gespecificeerde formaat. En toch bestanden accepteert waar de ontwerpfouten wél in zijn gebruikt én bij het importeren van deze potentieel gevaarlijke lekken preventieve maatregelen doorvoeren om alsnog te beschermen tegen het lek.


Kwaliteits analyse van de keuzes:
Optie 1: is niet gebruiksvriendelijk, en als deze massaal zou worden geimplementeerd in de gehele ontwikkelsector zou je al vrij snel tegen absurde vendor lock-ins aan lopen vanwege niet uitwisselbare bestanden.

Optie 2: is wat meestal gebeurt, omdat het helaas gewoon zelfs met de beste bedoelingen niet altijd mogelijk is om alle fouten te onderscheppen.

Optie 3: combineert het beste van twee werelden. Dit is wat hier met de besproken update gebeurt.


Conclusie:
Dat betekent het volgende...

Before situatie:
- Ja, de oude versie van de software was gevoelig voor een beveiligingslek. (naive implementatie door OOo, fout van OOo)
- Ja, de oude versie implementeerde de specificatie zoals deze omschreven was. (Volledige ondersteuning van de specificatie, goed van OOo)
- Ja, de specificatie, gemaakt door iemand anders, was lek. (specificatiefout van iemand anders, niet de fout van OOo)

After situatie:
- Ja, de update repareert de naive implementatie. (fout van OOo verholpen)
- Nee, de update repareert niet de specificatiefout. (fout van specificerende partij is niet verholpen)