A kiadás a négy alapváltozat mellett kiskapitális betűváltozatot is tartalmaz, ami külön betűtípusként (Magyar Linux Libertine C O) használható az OpenOffice.org-ban. Több egyéb javításával, mint például a kiegészítő fj ligatúrák hiányzó változatainak pótlásával a Magyar Linux Libertine valószínűleg a jelenleg elérhető legjobb minőségű szabad OpenType betűkészlet a magyar nyelvű szövegszerkesztéshez és kiadványszerkesztéshez.

A jó minőségű szabad, jelen esetben GNU GPL és SIL OFL licencű betűkészlet jelentőségét nem lehet eléggé hangsúlyozni annak fényében, hogy ilyen nem nagyon volt (a TeX szedőrendszer Computer Modern betűkészlete valódi betűfokozatokat tartalmaz, de nincs egalizált OpenType változata az OpenOffice.org számára), valamint egyre szigorodnak a kereskedelmi forgalomban kapható betűkészletek licencelési feltételei, l. Nagy Bence: A font is szoftver, Magyar Grafika, 2006/4.

Letölthető Windowsra egy béta build, amelyet kifejezetten ennek az újdonságnak a tesztelése kedvéért készítettem. OpenSUSE alatt szintén ki lehet próbálni, fel kell venni a megfelelő verzióhoz való OpenOffice.org:UNSTABLE repository-t.

– Miért kellett lefordítani a függvények neveit magyarra?
– Felhasználókkal és oktatókkal konzultálva arra jutottam, hogy a magyar függvénynevek jobban segítik az OpenOffice.org Calc bevezetését az oktatásba és a munkahelyekre. A magyar Excelről való áttérés zökkenőmentesebb lesz, az Excelhez rendelkezésre álló magyar nyelvű szakirodalom az OpenOffice.org Calchoz is felhasználhatóvá válik.

– Melyik OpenOffice.org verzióban lesznek megtalálhatók a magyar függvénynevek?
– Az ooo-build rendszerre épülő kiadások 3.2.1-es verziójától kezdődően. Ezek többek között az FSF.hu-féle magyar OpenOffice.org, a Go-OO, a Novell Edition, az OxygenOffice, valamint az ArchLinux, Ark, Debian, Frugalware, Gentoo, Mandriva, openSUSE, SLED, SLES és Ubuntu Linux-disztribúciókban megtalálható OpenOffice.org-változatok.

– Eddig miért nem voltak lefordítva a függvénynevek? Mi lesz azzal, aki az angol függvényneveket tanulta meg?
– Eleinte az volt az álláspontom, hogy jobb meghagyni az angol függvényneveket. Később nem akartam megváltoztatni ezt, a felhasználók egy része által megszokott sajátosságot. Most vált elérhetővé az ooo-build rendszerben az a lehetőség, hogy a felhasználó választhat a lefordított és az angol függvénynevek használata között. Senki nem szenved tehát hátrányt a függvénynevek lefordításával. A súgóban az eredeti angol függvénynevek is szerepelnek a tárgymutatóban.

– Mely függvénynevek lettek lefordítva, és melyek nem?
– Csak azokat a függvényneveket fordítottam le, amelyek léteznek a magyar Excelben, és ott le vannak fordítva. Ez 199 függvényt jelent. Minden más függvény maradt az eredeti nevén. Célom kizárólag az exceles ismeretekkel való jobb kompatibilitás megteremtése volt, a függvénynevek sokszor erőltetett magyarra fordításával nem értek egyet.

– Mikor kerülnek be ezek a változások az upstream forráskódba?
– Az upstream forráskódból épül pl. a StarOffice vagy a vanilla OpenOffice.org és valószínűleg más OpenOffice.org-leszármazottak is, amelyek nem az ooo-build rendszert használják. Ha lesz lehetőség az OOo 3.2.1 megjelenése előtt a fordítás frissítésére az upstream forráskódban, akkor a lefordított magyar függvénynevek bekerülhetnek. Mivel a munka során sok apró hibát javítottam és javítok folyamatosan a súgóban a függvények leírásainál, jó lenne, ha ez sikerülne. Azonban az angol függvénynevekre való visszaváltás funkciójának beillesztési időpontja még nem ismert. Biztosan nem a 3.2.1 lesz az, hanem inkább a 3.3 vagy későbbi verzió. Ezért az upstream forráskódon alapuló verziókban egyelőre nem lehet visszaváltani az angol függvénynevekre.

A webcast megtekinthető az Oracle honlapján itt.

Címszavakban a lényeg (bár a webcast sem hosszú):

• Továbbra is fejlesztik és támogatják a nyílt forrású OpenOffice.org-ot, mint a közösség legjelentősebb tagja.
• A biztosítást, támogatást, jótállást, enterprise tool-okat, bináris patcheket és frissítéseket igénylő nagyvállalati felhasználóik részére továbbra is fejlesztik és támogatják a StarOffice/StarSuite-szerű licenckonstrukciókat – alacsonyabb TCO-val, mint a versenytársak.
• A StarOffice/StarSuite neve hamarosan megváltozik, ezek az Oracle Office termékcsalád részei lesznek.
• Lesz egy webes Office csomag, együttműködik az asztali verzióval, de teljesen a böngészőben fut majd, és ODF-et használ.
• Integráció az Oracle-termékekkel, például az üzleti intelligencia és tartalomkezelő alkalmazásokkal.
• A jDeveloper IDE segítségével lehet majd kiterjesztéseket fejleszteni és telepíteni az OpenOffice.org-hoz.

Nekem a legjobban az a bejelentés tetszett, hogy a termék neve Oracle Office lesz. Végre megoldódik az „a/az” névelőprobléma.

A könyvhöz szorosan kapcsolódnak olyan fejlesztések, mint az OpenOffice.org ellenőrzése, javítása és kiegészítése egy még teljesebb magyar honosítás elkészítése céljából. Példa erre, hogy az OpenOffice.org legújabb magyar helyesírási szótára felismeri, elválasztási szótára pedig helyesen választja el a magyar szavakat unicode-os f-ligatúrákkal is. A közeljövőben várható egy a magyar nyelv vonatkozásában valószínűleg legteljesebb szabad betűkészlet kiadása is (a könyv Linux Libertine betűkészletének bővített és javított változata), valamint az automatikusan kiválasztott a/az névelős kereszthivatkozások könnyen kezelhető megvalósítása az OpenOffice.org-ban.

Addig kérem az érdeklődőket, hogy teszteljék az alábbi linken letölthető kiadásokat és az értékes véleményeket osszák meg itt a hozzászólások között.

Letölthető innen:

ftp://ftp.devall.hu/kami/320beta/

OOo_3.2.0_100224_Win32Intel_install.exe – Angol változat

OOo_3.2.0_100224_Win32Intel_install_hu.exe – Magyar változat

Mivel nem mindenki olvassa a levelezőlistánkat, fórumunkat, sőt még ezt a honlapot sem, elkészítettük újra a teljes telepítőkészletet, hogy új felhasználóinknak nehogy később gondot okozzon ez a hiba. Akit a hiba nem érint, vagy már telepítette a javított DLL-t, annak nem érdemes újratelepítenie a programot. A letöltési hely és név változatlan, az MD5-ellenőrzőösszeg természetesen változott, valamint a névjegypanelen a “Build 2010-02-25″ szöveg olvasható.

Kérünk mindenkit, aki letükrözte a korábbi telepítőkészletet (pl. szoftverbazis.origo.hu), hogy cserélje ki. Elnézést a kellemetlenségért.

• Javított névelő-ellenőrzés a számok előtt. (Egy lemaradt $-jel miatt a számok előtti névelőket ellenőrző szabály rossz esetben is illeszkedett, aláhúzva az a névelőt a tizenvalahány és százvalahány előtt is.)
• Kibővített idézőjelekre vonatkozó javaslatok
  • ASCII idézőjelek cseréje: ,,vmi” → „vmi”, >>vmi<< → »vmi«
  • Belső idézőjelek helyes sorrendje: «vmi» → »vmi«
  • Angolszász nem dupla idézőjelek felismerése: ‘vmi’ → „vmi”, »vmi«
• Nem törő szóközök felismerésének javítása a pénzösszegek konzisztencia-ellenőrzésénél.
• Szűkebb ezrestagolók (nem törő keskeny szóköz, U+202F) használatának támogatása (a tipográfiai opciók között).

Letöltés

Elkészült a Slackware Linux 64 bites változatához is a 64 bites magyar nyelvű változat. Ez nem a go-oo féle változat, hanem a sima vanilla forrásból készített.

Letölthető: openoffice.org-hu-3.2.0-x86_64-1ned.txz

Részletek itt.

Az OpenOffice.org 3.2-ben javított biztonsági hibák:

• CVE-2006-4339: Potenciális sebezhetőség harmadik féltől való libxml2 könyvtáraktól
• CVE-2009-0217: Potenciális sebezhetőség harmadik féltől való libxmlsec könyvtáraktól
• CVE-2009-2493: OpenOffice.org 3 Windows változata az MSVC sebezhető változatát tartalmazta
• CVE-2009-2949: Potenciális sebezhetőség XPM fájl feldolgozással kapcsolatban
• CVE-2009-2950: Potenciális sebezhetőség GIF fájl feldolgozással kapcsolatban
• CVE-2009-3301/2: Potenciális sebezhetőség MS-Word dokumentum feldolgozással kapcsolatban

OpenOffice.org 3.2 biztonsági és személyes adatbiztonsági fejlesztései

Az OOo biztonságáról már volt szó egy korábbi hozzászólásban: http://www.openoffice.hu/2009/05/ooo_biztonsaga/.

Abban megtárgyalásra került néhány kérdés amely közvetlenül tisztázásra került, de volt néhány terület amelyről Malte Timmermann, az OOo biztonsági projekt vezetője azt ígérte, hogy az OOo 3.2-ben kerül sor a szükséges módosításokra, és ez meg is történt. Alább található szöveg a blogbejegyzés fordítása.

A korábbi hozzászólásban felsorolt szükségesnek ítélt fejlesztések

Probléma: Titkosított dokumentumok – Makrók hozzáadhatók, kicserélhetők vagy eltávolíthatók.

Az OOo 3.2-ben nem lehet hozzáadni nem titkosított makrófolyamot, vagy a meglévőt lecserélni egy másik nem titkosítottra.

A kompatibilitás megtartása miatt ez az ellenőrzés csak az ODF 1.2 változatú dokumentumokra vonatkozik, amelyeket az OOo 3.0 vagy újabb változatával készítettek. De az OOo nem egyedül a manifest.xml tartalmától függő ellenőrzést végez, hanem leellenőrzi a titkosított content.xml változatát is, így a dokumentumot manipuláló felhasználó nem tudja az ellenőrzést kikerülni az alacsonyabb számú ODF formátum használatával a manifest.xml-ben.

Továbbra is van lehetőség a makrófolyam teljes eltávolítására, mert a manifest.xml továbbra sem védett. Ennek védetté tételéhez az ODF 1.2 további módosítására lesz szükség, mivel nem akarunk csak az OOo által kezelt titkosítást készíteni.

Más kérdés a titkosított makrófolyamok beillesztése, de ennek nincs hatása. Az ok, amiért különböző aláírású makrók lehetnek, hogy a felhasználó minden makrókönyvtárt külön-külön jelszóval védhet. A titkosított makrófolyam hozzáadásával nem érhető el semmi, az OOo nem tudja a titkosítást feloldani, és nem regisztrálódnak a Basic könyvtárban, mert az a fájl is titkosított.

A megmaradt (valószínűleg nem olyan fontos) probléma esetében, ahol a titkosított dokumentumból eltávolítható a makrófolyam, különböző lehetőségeket kell kiértékelni. Az egyik lehet a manifest.xml védelme valamilyen aláírási algoritmuson keresztül, vagy a teljes ODF zip-folyam titkosítása. Az utóbbi esetben az ODF konténerbe lehet a folyamot csomagolni, így a mimetime-folyam rendelkezésre állhat a rendszerintegrálásra, és tárolhatja, hogy mely titkosítás került alkalmazásra.

Ennek kifejtésére ez a hozzászólás nem alkalmas, ha a részletek érdeklik, és dolgozni kíván a megoldásán, csatlakozzon az OOo Biztonsági projektjéhez, az ötleteket a biztonsági levelezési listán vitassák meg, ahova előzetesen fel kell iratkozni, mivel a válaszokat általában csak a listára küldik meg.

Probléma: Meg kell jegyezni, hogy a META-INF/manifest.xml és a META-INF/documentsignatures.xml önmagukban nem aláírtak

Az ODF 1.2 specifikáció módosításra került (ez az első változat ahol a digitális aláírás említésre kerül). A dokumentum aláírások fogalmának meghatározása, kijelenti, hogy az ODF csomag összes folyama, beleértve a manifest.xml-t is a dokumentum aláírásnak le kell fednie. Az egyetlen kivétel az aláírási folyam, amely kihagyható.

Az OOo 3.2-ben a manifest.xml a dokumentum aláírás része.

Probléma: A támadó nem deklarált fájlt tud hozzáadni (különösen veszélyes makrót vagy makrókat)

Ahogy az az eredeti hozzászólásban is szerepelt, ez nem nagyon változtatja meg a biztonságot, attól függetlenül, hogy a manifest.xml-ben szerepel-e vagy sem, ugyan is a manifest.xml amúgy is könnyen frissíthető.

De mivel az egy jó módszer, hogy minden fájl deklarálva legyen a manifest.xml-ben, az OOo 3.2 ellenőrzi ezt az ODF 1.2 dokumentumok esetében.

Mivel a régebbi változatú OOo-ok rögzítették az összes fájlt a manifest.xml-ben, megvitatásra érdemes az összes régebbi változatú dokumentum ellenőrzésének kérdése.

Probléma: Gondoljuk át azt az esetet ha egy titkosított makró lecserélésre kerül egy nem titkosított egyszerű szöveg (veszélyes) makróval.

Az első problémánál fentebb megbeszéltük, az OOo nem fogadja el a nem titkosított folyamokat a titkosított dokumentumokban, a dokumentum ODF változattól függetlenül.

További fejlesztések az OOo 3.2-ben és az ODF 1.2 specifikációban.

ODF 1.2 már lehetővé teszi különböző titkosítási algoritmusok alkalmazását, és manifest.xml-ben minden részletet a felhasznált algoritmusokkal kapcsolatban dokumentálni kell(ez az oka annak, hogy a manifest.xml nem titkosítható). Ezek az ODF módosítási javaslatok, benyújtásra kerültek az OASIS ODF műszaki bizottságához, és az OOo 3.2-ben bevezetésre kerültek. Ez csak annyit jelent, hogy az OOo az összes szükséges információt a manifest.xml-be helyezi. Nem azt jelenti, hogy az OOo új beépített titkosító algoritmust tartalmaz.

A részletekért, és a biztonsággal kapcsolatos további információkért keresse fel az OOo Biztonsági projekt wikioldalát.