Major és minor a gyakorlatban

Hát tisztelettel, ha eddig még nem lett volna világos, hogy mikor kell a major verziószámot növelni, és mikor a minor-t, azt most az OpenSSL-1.0.2g megmagyarázta: a legminorabb verziószám (vagyis az utolsó betű) nőtt csak, de inkompatibilis változás történt az ABI-ban ([default opciókkal fordítva] megszűnt létezni a SSLv2_server|client_method), emiatt eddig működő programok (curl, wget, php) nem-indíthatóvá váltak.

( Protezis | 2016. 03. 02., sze – 08:10 )

Nem "patch verzió" és "API" a szavak, amiket keresel?

Nem, neki az a fontos, hogy a már lefordított binárisok működjenek, azaz neki ABI kell - ami eddig linkelődött, linkelődjön most is jól. De nem tud. Hogy értsd: van neki lefordított curl, php, wget, ami most már nem indul el, mert a z openssl ABI (azaz ebben az esetben az exportált függvények szignatúrája) módosult.

( uid_194 | 2016. 03. 02., sze – 08:30 )

Tudom, hogy nem segit, es sokan nem ertenek vele egyet, de a verziozas teljesen szubjektiv. Ha valaki ugy gondolja, hogy a verzioszam a Pi-hez fog konvergalni, ha torik, ha szakad, megteheti. Van aki nem akar 20-nal tobb minor verziot, es gondol egyet, felnyomja a majort, mert csak. Van aki megunja, hogy sok a minor, es a majort vegul elhagyja. Van aki betuket illeszt a vegere, amikor csak bugfix van, meg akkor is, ha a bugfix nem backward compatible.

Ez van, sajnos. Release notes, jozan esz, es sok-sok szivas a baratod. Nem veletlenul leteznek disztribuciok, ahol ezeket vegigszopjak helyetted.

--
|8]

"ha torik, ha szakad, megteheti."
Csak éppen műszaki ember nem fogja komolyan venni.

Persze, geek dolog a TeX és a METAFONT verziózása, de attól még mérnökember csak kineveti ezt.
Mint ahogy kinevetnének akkor, ha nem épp szabványos csavart használsz, vagy nem szabványos csatlakozót. Lehet olyat csinálni, csak senki nem fog együttműködni tudni veled.

Ami logikus és értelmes, az a szemantikus verziózás, semver.org

" Release notes, jozan esz, es sok-sok szivas a baratod. "
Nem. NEM. NEM. Ennek véget kell vetni. Az egy dolog, hogy mindent lehet, de nem mindent szabad. Kurvasok pénzébe kerül az embereknek az, hogy az informatikusok nem igazán jó mérnökök még mindig.

Pedig a linux, az emacs es meg sok mas dolog verziozasat veresen komolyan veszik egyesek, pedig azok is - oz openssl-el egyutt - egy bizonyos logikat kovetnek. OpenSSL eseteben ez azt jelenti, hogy bugfix = betu, megha inkompatibilitast okoz is. Arra ott lenne a SONAME, ami egy sokkal praktikusabb megoldas a problemara.

SemVer pedig jol hangzik, de azert annak is vannak hianyossagai. Pl ha nagy feature miatt az ember szeretne major verziot lepni, mert szignifikans, nem teheti. Ha backward compatibilityt orokre megtartja igy vagy ugy, akkor 1.x.y lesz az idok vegeig, megha kozben az APIt teljesen at is irtak (regit megtartva mellette). Ez is butasag.

Ertem en, hogy meg kene valtani a vilagot, de nem fog menni. Nem mondom, hogy ez jo, csak annyit, hogy jobb nem is lesz. Sot.

--
|8]

SONAME-ról szólva, amennyire én tudom, az OpenSSL-1.0.2g-nek a major verziószáma az, hogy 1.0.0 ... Ez az a pont, ahol a hagyományos emberi értelem feladja a reményt, udvariasan elnézést kér, és visszavonul. 


$ cd /usr/local/src/openssl-1.0.2g
$ readelf -d ./libcrypto.so | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libcrypto.so.1.0.0]
$ readelf -d ./libssl.so | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libssl.so.1.0.0]

A szemantikus verziózás egy csomó feloldhatatlan problémát okozhat. Például kiadom a 2.0.0-át. Aztán kiderül, hogy az 1.0.0-ban olyan biztonsági hiba van, ami nem javítható ABI változtatás nélkül. Akkor mi lesz a javítás verziója?

Valójában egyedi azonosítóval ellátott API és ABI állapot objektumokra lenne szükség, ezek között definiált "felfelé kompatibilis" gráf élekkel. Illetve a kód és a fordított bináris is megjelennek a gráfban mint csomópontok, és ők pedig "ezt implmentálja" éllel hivatkoznak a megfelelő API és ABI objektumokra. Na, ez lenne a megoldás :-).

Csak úgy érdekességképpen megemlítem, hogy pl. AIX-on nincs SONAME.

Az a név íródik bele a bináris programba függőségként, amit a szerkesztéskor(ld) a parancssorban megadtunk, ami lehet pl. az alábbiak valamelyike (a helyi szokásoktól, a programozó hangulatától és a holdállástól függően): 


libssl.so.1.0.2.g
libssl.so.1.0.2g
libssl.so.1.0.2
libssl.so.1
libssl.so

Segítek a megoldásban.
A semver egy támogatott termék verziózásáról szól.

Igazából ez arról szól, hogy valójában két terméked van, amit támogatsz, így természetesen két külön verziósorozata is van ezeknek:
Foo1 1.0.0 és Foo2 1.0.0
És ha Foo1-ben van biztonsági hiba, akkor Foo1 verzióját lépteted.

A kérdés ugyebár visszavezethető arra, hogy mely terméket támogatod még. Amint külön támogatási ciklus van az egyes verziókhoz, az már külön termék. Ennyi.

Nem ez volt a kerdes, hanem az, hogy ha mindketto tamogatott, es Foo1-ben bugfix van ami API/ABI valtozassal is jar, semver szerint majort kene bumpolni. De mar van Foo2. Igy utkozes lep fel, es jon a wtf.

SemVer erre az esetre nem keszult fel, mert az abbol indul ki, hogy egy agat tamogatsz csak.

--
|8]

> Aztán kiderül, hogy az 1.0.0-ban olyan biztonsági hiba van, ami nem javítható ABI változtatás nélkül. Akkor mi lesz a javítás verziója?

attól függ, hogy az 1.0.0-ból mi volt a major és mi a minor.

pl: 


       major minor         major minor        
volt:  1.0.0 -      lett:  1.0.1 -
volt:  1.0   0      lett:  1.1   0
volt:  1     0.0    lett:  1a    0.0

(Persze ha libtool-t használunk, akkor az ő verziószám-modelljét kell követünk: major.minor.minor, mindhárom numerikus. De van egy bonyolultabb verzió is, amikor ezen a három számon egy ravasz transzformációt kell végezni (current-age-revision számok), azt átadni a libtool-nak, hogy ő aztán visszaalakíthassa)

Kit érdekel a libtool? Ez sokkal absztraktabb dolog annál:
két stringről (verziószám) kell megállapítani, hogy melyik frisebb, melyik tartalmaz ABI/API inkompatibilis változtatást, és melyik kompatibilis. Semmi köze ennek a libtoolhoz, rengeteg alkalmazás nem használ libtoolt.

Mert nem az OpenSSL a hibás, hanem maga az SSL protokoll. Minden SSLv2 implementáció érintett, mert az SSL maga a hibás. Azaz a hibát csak úgy tudod javítani, hogy az egész protokoll támogatását kidobod. És most ez történt az OpenSSL-ben: kivették az SSLv2 teljes támogatását, ami náluk API és ABI változással jár.

... mérnökember csak kineveti ezt...

Amit én nem értek, az biztos HÜLYESÉG! :)

Aki valamelyest ismeri a TeX mögött álló fejlesztő(ke)t, a filozófiát és a program működését, az inkább leveszi a kalapját és csöndben marad. Ha esetleg mérnök is, akkor kicsit eltátja a száját, hogyan lehet egy eszközt (programot) úgy elkészíteni (megírni), hogy évtizedekkel később is korrektul működjön, és (ezred?) miliméterre pontosan az elvárt eredményt produkálja.

Ha jól értettem, a T. Kollégák nem a TeX és barátai, mint program nagyszerűségét vonták kétségbe, hanem a verziószámítási algoritmust.
OK. Kalkulus megvolt? Akkor világos a pogram filozófiájából eredő logikus következtetetés, hogy a verziószámok
- nem lehetnek véletlenszerűek
- nem divergálhatnak a végtelenbe (1.x, 2.y, 3.z, stb)
- hanem KONVERGÁLNIUK kell valamely valós számhoz. Hogy melyikhez? Hát persze hogy a pi-hez vagy e-hez! A többi (1.0, racionális számok, gyökkettő, stb.) túl szimplák, unalmasak, netán még algebraiak is! Ez a kettő (amellett, hogy mindenki ismeri őket:) kellően bonyolult - transzcendens - aurával bír, s benne van a matematikai szentháromságban. Alias Euler-összefüggés, azaz e^(i*pi) = -1.

és ez ellentmond minden normális mérnöki hozzáállásnak. Miért kéne a verziószámnak konvergálnia? Értem én, hogy Knuth halálakor a TeX készen lesz, de ez nem jelenti azt, hogy konvergálnia kéne a verziószámnak. A verziószám TECHNIKAI információt hordoz: API kompatibilitás, ABI kompatibilitás, nem csak egy monoton növekvő érték, ezt kéne megérteni.
Jelenleg a TeX és a METAFONT verziószámozása nem tartalmaz technikai információt, így alkalmatlan bármilyen kompatibilitásra való következtetésre, ergo marad a gagyi release notes olvasgatás.
Senkit nem érdekel a TeX és Knuth filozófiája, ez nem matematika meg szépség, hanem szoftvermérnökség.

És csodálkozunk, hogy tele van a világ inkompatibilis szoftverekkel, mert a fejlesztők a saját egojukat a verziószámozgatásukban is kiélik. Szép lenne, ha az építészmérnök is kiélné a saját egóját a statikai számításokban, "jóleszúgy" alapon. De az nem mérnökség.

Vagy hogy másként mondjam: a verzió az nem egy szám, hanem egy adatstruktúra, aminek van karakterláncos szerializációja.
És ezen adastruktúrára értelmezett nem csak egy rendezési reláció, hanem több is, mindegyik más jelentéssel: major part relációja más jelent, mint a minor parté stb.

Majd ha a nagyon-szakerto mernokemberek tudnak olyan minosegu szoftvert gyartani, mint a viccesen es mernokietlenul verziozott TeX, akkor lesz erdemes barmifele verziozasrol es mernokiessegrol egy mondatban beszelni. Ameddig ez nincs igy, addig nevetseges.

--
|8]

Nem az a kerdes, hogy a TeX mire dependal, hanem mi dependel ora. Csillio szakdolgozat, tudomanyos publikacio, satobbi. Ha azokat eltorod, nem lesz boldogsag. Mission critical? Neked lehet, hogy nem, masnak igen. Azert, mert te nem tudod elkepzelni, nem jelenti azt, hogy mas sem.

Es tovabbra is allitom, hogy mernoki verziozasrol beszelni akkor, amikor a szoftver maga otvar fos, a fejlesztes menete sem mondhato mernoki alapossaggal megaldottnak, elegge hulyen jon ki. Ha verziozassal akarod szonyeg ala soporni a fejlesztes hianyossagait, valamit rosszul csinalsz.

--
|8]

( log69 | 2016. 03. 02., sze – 08:37 )

Nincs valamelyik dollár milliárdos multinak egy kis zsebpénze auditáltatni ezt a nyomorult openssl-t? Vagy direkt gáncsolják a dolgot bizonyos szervezetek?

Sőt, megjelent valami másik SSL implementáció is. De addig még sok projekt és sok régi de hosszú támogatású szerver verzió használja. Legjobban úgy lennénk kisegítve, ha ezt auditáltatnák. Nem hiszem el hogy egy legalább egyszeri kifizetésre ne lenne keret - mérlegre téve a fontosságát.

És mire mész azzal, hogy auditálod? Az auditálás mint folyamat nem fog hibát vadászni - nem ez a dolga.
Csak annyit fog felfedni, hogy megfelel-e a specifikációnak a szoftver, illetve hogy ellenőrzött keretek között folyik-e a fejlesztése, van-e minőségmenedzsment.
Hiába auditálják az OpenSSL-t, ha például a protokoll hibás.
Jelenleg a DROWN esetén magában a protokollban (az SSLv2-ben) van a hiba, és nem az OpenSSL implementációban.
A LibreSSL-t csak azért nem érinti a hiba, mert már nincs a kódbázisában SSLv2.

Egy auditálás ha azt vizsgálja, hogy a kód megfelel-e a specifikációnak, akkor nem fogja azt vizsgálni, hogy amúgy milyen, a specifikáción kívüli dolgokban lehet még bug.
Az auditálás találhat ugyan hibát - ha a hiba jellege az, hogy a kód nem implementálja a specifikációt.
De ennyi. Ha a specifikációt implementálja a szoftver, akkor át fog menni az auditon mint megfelelő. Attól még lehet bugos szar. És a protokoll is lehet bugos szar.

Nem az foglalkoztat amit leírsz, hanem hogy az algoritmusokat és a kódot szétszedve miért nem éri meg egy olyan audit kivitelezése a nagy cégeknek, amelyek a szóban forgó hiba fajták detektálását is célozzák - illetve további fontos aspektusokat is? Miért nem éri meg? Miért nem akarják és akarták eddig? Mi itt a gátoló tényező? A kód komplexitása? Nem kellene annál jobban a vizsgálat? Az foglalkoztat engem, hogy megtudjam, hogy egy ennyire fontos libet - melyre sok iparági szereplő sok megoldása épül - miért nem karolnak fel többen? Ezen hibákkal a biztonság sérül, és így a cégek renoméja is. Ez már közvetlen pénzügyi kárt is hozhat.

Volt hír a mikor kernelről, mely helyességét svájci kutatok két éven át bizonyították formális módszerekkel. Kripto területen nem kellene (érné meg) az iparnak kiizzadni pár olyan stabil alapkövet logikai és valós nyelvi implementációkkal, amelyek a lehető legjobb mértékben vizsgáltak (akár milyen módszert ideértve) ? Azért a nem régi openssl hiba is durva volt (ugye privát kulcsot lehetett kinyerni a szerverről kliens oldalról). Kicsit elgondolkodtató nem?

Milyen ipari és üzleti érdek gáncsol egy ennyire triviális szükséget?

(LibreSSL-t meg többi implementációt hagyjuk, a hosszú távú támogatású rendszereken ez lesz használatban még sok ideig - illetve Theo-ék vajon mennyire tudnak hibamentes kódot kiadni? milyen módszerekkel tudják biztosítani? Szkeptikus vagyok.)

Szerintem egyszerűen a közös lónak túrós a háta effektus ez. Mindenki arra vár, hogy valaki más elvégzi helyette a piszkos - és költséges - munkát. Gondold el, hogy melyik cégnek van erre két éve öt fejlesztővel a mai viszonyok között? Erre még a Google sem fizet pénzt.

Plusz ha egy csapat megcsinál egy ilyen auditot, az is csak egy pillanatnyi állapotra lesz érvényes, és ráadásul másoknak semmi okuk nem lenne megbízni benne - hiszen ezen a területen könnyű elképzelni, hogy az emberek le vannak fizetve azért, hogy szemet hunyjanak egy-egy sebezhetőség felett.

Ráadásul nem is versenyhátrány egy SSL hiba, mert a többieknek sincs jobb kripto kódjuk.

Nem két éves bizonyításra gondoltam, de vajon szerintetek nem lehetne pár emberrel pár hónap alatt minőséget ugrani a hibák szempontjából? Vajon tényleg akkora költség lenne - figyelembe véve a nagyok bevételeit?

Szerintem az egyszeri audit már sokkal jobban hangzik a nulla és a soha szavaknál.

Biztonság szempontból persze hogy megérné, csak kérdés, hoyg találsz e olyan embert aki megfelelő szinten képes értelmezni a forráskódot, átlátni a kódolási hiányosságokat, plusz matematikailag átnézni (és bizonyítani) a crypto részét az egésznek (itt már szerintem komoly bajban leszel), plusz ennek implementációját ellenőrizni OpenSSL-ben.
És akkor még ne is beszéljünk arról, hogy ha van is hiba, akkor azt engedik e majd publikálni (van nem 1 szervezet akinek ez nem lenne érdeke).
Mindezt úgy, hogy a kód tele van platform specifikus részekkel (tehát azokat is ismerni kell), és csomó olyan régiséggel amit ma már lehet csak 10 ember használ a világon (de ha van köztük 1 aktív fejlesztő is, akkor ő már elég, hogy a kódfának azt a részét megtartsák).
És akkor mindezek után jönne a másik probléma (ami most is előjött a tesztelés során), hogy az összes security oldalról megkérdőjelezhető dolgot ki kéne dobálni (nyugi, még ez után is van benne 1-2 amit konfigból tiltani kell ha tényleg biztonságra törekszik az ember. Bő egy éves, de még mai napig érvényes olvasmány), úgy hogy az új -major- verzió kompatibilis legyen lehetőleg mindennel ami erre a library-ra dependel.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( Huncraft v | 2016. 03. 02., sze – 09:05 )

Azért ha a change logot jól értelmezem, akkor Fedora-n se jönne elő ez a probléma ha a configure során betolnák az "enable-ssl2" kapcsolót, amíg ki nem purgálják a függőségekből ezt a hívást.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( zeller | 2016. 03. 02., sze – 10:23 )

El kéne már felejteni az SSLv2-t mindenestől, mert ennyire rozzant protokoll nem érdemes arra, hogy megmaradjon - maximum elrettentő példának :-P
Azzal, hogy most defaultban nem támogatott, az jó irány - illene az alkalmazásokkal is utánamenni ennek a lépésnek.
Bár ahogy az igen régóta obsolete ifconfig, route és társaik sem haltak még ki, úgy ez a szutyok is rohadt sokáig meg fog még maradni... Sajnos.