Dobálja ki az OpenBSD a felesleges dolgokat az OpenSSL-ből

Titkosítás, biztonság, privát szféra

A Heartbleed probléma után az OpenBSD fejlesztők úgy döntöttek, hogy kiszórják az OpenSSL-ből a számukra felesleges dolgokat, megpróbálják csak a feltétlenül szükséges és ésszerű dolgokat megtartani, a kódot elvárt kódolási stílus szempontjából rendbe tenni, illetve kitisztítani. A nekiveselkedésnek egy nagyobb rendezkedés lett a vége, ami egy hét alatt körülbelül 250 commitet jelent eddig.

A rendrakás elején Theo de Raadt mindjárt letiltotta Seggelmann RFC520 heartbeat-jét. A munka oroszlánrészét Ted Unangst (tedu@), Miod Vallat (miod@), Joel Sing (jsing@), Theo de Raadt (deraadt@) és Bob Beck (beck@) végezte.

A változások áttekinthetők itt. További részletek itt.

( tompos v | 2014. 04. 18., p – 13:18 )

Nem vagyok jaratos a temaban.
Mirol szol a heartbeat, minek kell es az obsd-nek miert nem?

( necrolite | 2014. 04. 18., p – 13:33 )

Valahogy ezt vártam Theo-tól a hiba kapcsán illetve hogy from scratch újraírják open-openssl néven ;o)

( ProTech | 2014. 04. 18., p – 14:00 )

Amire kivancsi leszek, hogy az a 250 commit amit oszehoztak egy het alatt, mennyi uj security bug-ot tartalmaz. Raadasul nem csak egy valaki, hanem tobben belenyultak. Biztos nagyon jo fejlesztok, de apro dolgokbol is lehetnek nagy problemak. Ne legyen igazam, de ezt a hirtelen felindulasbol vessunk at mindent nagyon veszelyesnek tartom.

Amíg a változtatások ilyen nagy horderejüek mint ez, addig nem aggódnék emiatt.
Csak remélni merem, hogy nem kézzel tördelgették újra az if-eket...

Ha jól értem a lényegi dolog itt a plusz feature-ök kiszedése, csak az nem lett volna több 3 commitnál...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( uid_16313 | 2014. 04. 18., p – 14:46 )

Része az OpenSSL egy default OpenBSD install-nak?
Mert ha igen, akkor ez már a 3. security hole in a heck of a long time!

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( atomjani | 2014. 04. 19., szo – 07:44 )

Végre egy jó hír. Minél nagyobb egy program, annál nagyobb biztonsági kockázatot hordoz magába, sőt a futás közben mérhető teljesítmény is romolhat. A kezdeményezés jó, ha jól csinálják.

......................
Egymás segítésére még: http://pc-kozosseg.com

Szerintem ezt nem lehet jól csinálni. Eleve nagyon szar a kódja, és ilyenkor a legjóindulatúbb rendrakás is csak további bajt csinálhat. Ezen csak a teljes újraírás segítene.

Ilyen kódoknál még általában az eredeti alkotók sem mernek belenyúlni a gázos helyekbe, mert kb. bármi elromolhat. Hát még ha kívülállókról van szó (nem tudom, hogy ők azok-e).

Meg hogy is van ez, ők a saját forrásfájukban kezdtek refaktorálgatni? Magyarul innen kezdve ha jön is bármi javítás az upstreambe, azt nehéz lesz áthozni, és még több a hibalehetőség.

--

Igen, az újraírás egy jó ötlet. Nem tudtam, hogy ennyire rossz a kódja.
Mondjuk ha folytatják ezt a módosítás, funkciók kivétele mizériát, akkor lehet, hogy a kód egyszerűbb, tisztább, átláthatóbb lesz. A kezdet a legnehezebb. Meg szerintem ez egy nagyon hosszú időt fog igénybe venni.
Egyébként lehet, hogy jó úton haladnak. Végülis csak a megfelelő lépéseket kell megtenniük.

......................
Egymás segítésére még: http://pc-kozosseg.com

Először kiszórják azokat a kódokat, amikre semmi szükség nincs. A maradékot átnézik, kijavítják benne a hibákat, amiket találnak (gondolom legalább egy
statikus kódanalizátort sikerült ráizzítani). Azért a saját forrásfájukban refaktorálnak, mert ezt így kell. Bizony, ha jön javítás, akkor azt majd
át kell húzni, viszont az nem megy, hogy az upstream-ben állunk neki refactorálni, és félkész állapotban lesz a rendszer. Az upstream (trunk) definíció
szerint mindig stabil. Refaktorálásnál ez nem áll fenn.

Mi SVN-ezünk, azaz van egy trunk-unk, amibe olyan kód van, ami fordítható, ÉS tesztelt, és vannak branch-eink, amiket akkor csinálunk, amikor
valami módosítás van a kódon. Ha kis módosítást csinálunk (bug korrekció, ilyesmi), az megy kapásból a trunk-ba, ha nagyobbat, akkor külön
branch, majd a végén visszamergeljük. Igy nem csesszük szét mások munkáját.

Vagy nem. Van egy webshop projekt, amit idestova 6 eve felugyelgetek, fejlesztgetek. 2008-ban, mikor elkezdtuk a meglevo CMS-em alapjait vettuk at hozza es azt fejlesztettuk tovabb egy csomo helyen. Kb. 3/4-1 ev utan, annak a rendszernek az alapjait ujragondoltuk itt-ott es csinaltunk belole egy egyseges belso keretrendszert, ahol javitottunk egy csomo olyan dolgot, amit anno felreterveztunk. Persze, aztan annak is lett egy 2.0-as verzioja, ahol nehany dolgot javitottunk.

Aztan az egesz cucc atkerult velem egyutt a megrendelohoz. Akkora mar latszottak az eredeti projekten azok a teves tervezesi dontesek, amelyek vegul nem valtak be es/vagy a valtozo igenyeket nem tudta jol kiszolgalni, ellenben az uj keretrendszer igen. Mi lett a vege? Fogtam, es belereszeltem az uj keretrendszert a regibe. Ezzel valami eleg undorito ketkeretrendszeres torzszulott lett a vege. Viszont mukodott. Es kb. fel-egy hetnyi munkaval megkaptam majdnem minden uj szolgaltatast, ami az uj keretrendszerben volt, valamint a regieket (amelyek a bevetelt termeltek) is tudtam tovabbra is hasznalni. Aztan az idok folyaman kollegak szepen-lassan elkezdtek atirni a regi kodokat. Most, hogy megint azzal a projekttel kell foglalkoznom, most megint tartok egy kis pucolast. (Lassan-lassan csak kivegzem a regi keretrendszer maradvanyait). Igen, eltartott 3 evig, viszont cserebe vegig tudott mukodni a rendszer.

Most azzal a rendszerrel 3 webshop es egy egyeb oldal megy (illetve nyaron a maradek negyedik webshopunkat is atallitjuk erre). Szep a felszin alatt? Nem, de javul. Ujra kellene irni? O hogyne, legszivesebben az egeszet .NET vagy Java alapokon ujrairnam. Megeri? Nem. Nagyon nem: fel-haromnegyed evre lekotne 3 embert es ugyanannyi featurenal tartanank, mint elotte.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™