LibreSSL

 ( trey | 2014. április 22., kedd - 8:21 )

Nemrég volt szó arról, hogy az OpenBSD-sek nekiálltak kidobálni minden olyan dolgot az OpenSSL-ből, ami számukra szükségtelen, nekiálltak a kód megfelelő formára hozásának stb. Nem csak arról van szó, hogy némi takarítást végeznek. A The OpenBSD Foundation és az OpenBSD Project támogatásával létrejött a LibreSSL projekt.

A projekt kezdetleges weboldala szerint a LibreSSL az SSL/TLS protokoll egy szabad változata, amely az OpenSSL forkolásával jött létre. Egyelőre OpenBSD-hez reszelik. Multi-OS támogatás akkor érkezik majd, ha a kódot megfelelő mértékben gatyába rázták, ha feláll egy megfelelő csapat, aki a portabilitásért felel majd és sikerül megfelelően (támogatásokkal) alátámasztani a projektet anyagilag.

A LibreSSL fejlesztését elsődlegesen az OpenBSD Project végzi, debütálása operációs rendszerben az OpenBSD 5.6-ban fog megtörténni. A LibreSSL fejlesztését anyagilag a The OpenBSD Foundation és a The OpenBSD Project támogatja. Akinek tetszik a kezdeményezés, az fontolja meg annak támogatását.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Tudatlanságból kérdezem, nem ítéletet mondva: nem lett volna jobb a tisztításhoz hozzájáruló patcheket elküldeni az OpenSSL-nek? És esetleg a fejlesztésre szánt pénzt is? Így most nekem úgy tűnik, hogy szépen szétforgácsolódnak a fejlesztésre rendelkezésre álló erőforrások.

Az attól függ. Ha az OpenSSL projekt vezetése valóban olyan rossz, mint ahogy arról egyesek egyes helyeken írnak, akkor nem. Ha az OpenSSH-ra gondolunk, az sincs rossz helyen.

--
trey @ gépház

Pont ez érdekelne - van esetleg konkrét forrásod arra nézve, hogy az OpenSSL projekt vezetése rossz? Csak olyat találtam magamtól, ahol nyafiznak mindenfélékről (nincs pénz, nincs fejlesztő, nincs ingyen sör, ilyenek), de ez még nem akkora gáz.

A "rossz" egy relatív fogalom. Kinek a szemszögéből és miért rossz? Kinek az érdekeit képviselik? Honnan nézzük? Az OpenBSD úgy döntött, hogy jobban járnak, ha kezükbe veszik a dolgot.

de Raadt véleménye az OpenSSL csapatról:

"OpenSSL is not developed by a responsible team."

Hogy ez azt jelenti-e egy, a biztonságot a zászlója csúcsára tűző projektnél, hogy "rossz"? Szerintem igen.

--
trey @ gépház

Köszi, ez teljesen jó forrás.

Parttalan viták gyakran több energiát fogyasztanak mint egy önálló ágon futó fejlesztés. Az OpenSSH fejlesztése kiválóan megy az OpenBSD-seknek. Valószínűleg egy önálló SSL-lel is boldogulni fognak.
A névválasztásnak annyi a pikantériája, hogy itt pont mások stipi-stopizták az Open- előtagot, és azt kell más néven forkoli.

"Parttalan viták gyakran több energiát fogyasztanak mint egy önálló ágon futó fejlesztés."

Ez az egyik dolog. A másik az, hogy hiába küldene az OpenBSD projekt egy rakás patchet az OpenSSL-nek, ha az utóbbinak vezetése

- felelőtlen (Seggelman megint be[b|g]ombázik és patchet küld, amit alapos átnézés nélkül commit-olnak)
- szakmailag kevés (a patchet hozzáértés nélkül commit-elik, nem megfelelő emberek a karbantartók stb.)
- korrupt (NSA / corporate shill-ek ülnek a vezetésben)

stb.

--
trey @ gépház

Mivel nem céljuk támogatni olyan platformokat (pl Windows, VMS) amit az OpenSSL-eseknek igen, ezért nem lenne sok értelme. + a már említett okok.
_____________________________
Powered by 1,3,7-trimetilxantin

Funkcionalitast is dobnak ki, amit az openssl nyilvan nem fogadna be.
--
zsebHUP-ot használok!

Ja, pl. a heartbeat-et. Ahelyett, hogy inkább kijavítanák benne a hibát :-)

De értem, és meg is értem a kapott infók/linkek alapján, hogy az OpenBSD miért áll így a dologhoz.

A site-on az openssl link egy dalra mutat a youtube-on.

Nem ertem en amugy, hogy a sok nagyarcu beszolos el van borzadva, hogy hogy nez ki az openssl, beleertve az openbsd-t. Eddig is ilyen volt, hasznaltak.
Ha tudtak rola, miert nem tettek ellene (bunosok kozt cinkos, aki nema).
Ha nem tudtak rola, akkor meg mire van nagy arcuk, voltak olyan ostobak, hz ultrasecure OS-ukbe beraktak auditalas nelkul vmit, amire 10 evvel kesobb kiderul, hogy egy rakas szar. Csondben meghuznam magam:)

t

Azt valószínűleg látták, hogy rossz a kód minősége, de épp ezért nehéz benne észrevenni az ilyen hibákat, valószínűleg nem volt erőforrásuk ezt olyan szinten végig nézni, hogy ez kiderült volna. Amíg be nem bizonyult, hogy funkcionális hibák is vannak benne, addig nem az volt az elsődleges prioritás, hogy átirják a régi kódot szépre.
Sajnos nem lehet mindig mindent 100%-osan végig ellenőrizni, amit használsz, mert a világ összes ideje sem elég rá.

------------------
My Open-Source Android "Projects"

Az opensslrampage cikkei szerint meg nekem, amator nezelodonek is nyilvanvalo, hogy nem 100%-osan, hanem 1%-osan kellett volna csak belenezni es nyilvanvalo lett volna, hogy csak ido kerdese.
Egy core infrastrukturalis komponensnel ez lenyeges-e? Remelem, ez nem kerdes.

Ezek alapjan az openbsd fejlesztok sem sokkal kevesbe felelosek, h betettek az openssl-t az openbsd-be es ott tartottak hosszu eveken keresztul. Theo odarakhatja a nyelvet az openssl team segge lyukahoz, mert csak egy hangyafasznyival vannak elobbre.
Megvolt az ideje, tudasa es eroforrasa es elvileg a celja is.

tompo

Ha minden kódot nekem kellene karban tartanom, amit egy rakás szarnak tituáltam, de használnom kellett, akkor 100000 évig kellene élnem...

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

Nocsak, osszemerheto vagy az OpenBSD-vel, a google-vel vagy mas hasonlo projekttel ill. ceggel?

Ha igy gondolod, akkor ha mas nem, legalabbis az arcod osszemerheto Theo-eval:)

t

Nem kell ahhoz nagy arc, h az ember belassa, h teljesen mindegy, h opensource vagy proprietary a kod, a donto tobbsegenek a minosege kritikan aluli, minel inkabb bazar, annak inkabb. Ezert tudott peldaul a Coverity is regebben mig szuksege volt hirverest kelteni azzal, h ingyen es bermentve kod auditalt open source projekteket. Vagy ezert nez ki ugy az OpenSSL ahogy, h ontopic maradjak. :)

---
pontscho / fresh!mindworkz

Ami a sajat, Java-s tapasztalataimat illeti az opensource projektek (nem mind, de az ismertebbek, mint a spring, a guava, a hibernate vagy az Apache alapitvany rengeteg libje) jobb minoseguek, mint a closed source projektek (fuggetlenul attol, hogy azt kicsi vagy nagy ceg fejleszti).

Ez azert eleg kis szelete az egesz open source vilagnak. Egyszer majd nezz korul mondjuk az sf.net-en amig meg letezik.

---
pontscho / fresh!mindworkz

Hát ma reggel óta nem nagyon tudom elérni... Eddig létezett?


"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Ha a sourceforge.net a szóban forgó site... Nekem működik.

Igen, az, itt nem megy. De akkor csak itt. Ez tulajdonképpen jó hír.

Update: Most is elérhetetlen innen. Állítólag a Savvis a szolgáltatójuk, a számok meg magukért beszélnek.

http://www.internetpulse.net/


"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Ezen open-source projektek mogott cegek allnak, akiknek erdeke, hogy normalisan hasznalhato, a fejlesztok szamara is jo minosegu szoftvert csinaljanak. Hiszen szamukra a fejlesztok a piac, es nem a vegfelhasznalok.
Amugy a Hibernate es a tobbi JBoss termek kb. kizarolag XML-alapu konfiguralasa agyfasz.

Az, hogy áll e mögötte cég vagy sem, az itt nem volt szempont (mellesleg az Apache commons-* mögött szerintem nem áll cég). Másrészről meg ezek a projektek (guava-t leszámítva) előbb léteztek, mint hogy cég és vállalkozás nőtt volna mögéjük. Azért nőtt mögéjük vállalkozás, mert sikeresek voltak. És lehet folytatni a sort: joda-time, ehcache, slf4j+logback, jetty, jboss, quartz.

A nagy arc ahhoz kell, hogy ezek utan kijelentse:

"OpenSSL is not developed by a responsible team."

Evek ota kenytelen vagyok figyelni az openssl koruli valtozasokat (mikor evekkel ezelott egyszer egy forumon elmeseltem, h a kodja meg a linux kernel 2.4.18-nal is ocsmanyabb akkor majdnem megkoveztek, h mind a ketto az OS csimborasszoja) es bizony ehhez sem kell nagy arc.

---
pontscho / fresh!mindworkz

Azert plane egjen a pofaja Theo(*)-nak es baratainak, h sokan (ezek szerint te is, de sok mas postot is felhoztak mostanaban itt-ott), hogy mi a helyzet.

t

(*): Persze itt nem konkretan csak o erdekes, csak kipeceztem, mert ot konnyu:)

Miert *kotelessege* pl. Pontschonak ujrairni az openssl kodjat?
Ujrairas nelkul nem lehet velemenyt formalni?

Miert *kotelessege* barkinek is ujrairni a kodot? Rengeteg *nagy ceg* is hasznalja az openssl-t, most vegre valaki nekiult *dolgozni*, miert is kellene pont ot szarral dobalni?

Miert nem mesz neki mondjuk a Google-nek a Facebooknak, vagy barmelyik nagy cegnek, akik szinten hasznaltak (es epitettek ra!) az openssl-t? Nekik tobb *eroforrasuk* lett volna aktivan reszt venni a fejlesztesben.

Azert ez az openbsd team nem olyan hude nagy....

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

> Miert *kotelessege* pl. Pontschonak ujrairni az openssl kodjat?

He?

> Ujrairas nelkul nem lehet velemenyt formalni?

Ejha. Mivan?!

> Miert *kotelessege* barkinek is ujrairni a kodot? Rengeteg *nagy ceg* is hasznalja az openssl-t, most vegre valaki nekiult *dolgozni*, miert is kellene pont ot szarral dobalni?

Olvasd vissza, amit irtam.

> Miert nem mesz neki mondjuk a Google-nek a Facebooknak, vagy barmelyik nagy cegnek, akik szinten hasznaltak (es epitettek ra!) az openssl-t? Nekik tobb *eroforrasuk* lett volna aktivan reszt venni a fejlesztesben.

Olvasd el ujra, amiket irtam. Vagy csak keress a google-ra..

t

Bocs, hogy nem vagyok eléggé hupceleb, de szerintem a kódminőséget nem a fost szarrá pofozó maintainer pofájára mérik.

Teljesen mindegy, hogy milyen kód. Arról van szó, hogy használnom kell (mert még mindig előrébb vagyok vele, mintha nekiállnék nulláról lefejleszteni), és látom, hogy szar, de nem lehet mindent helyrepofozni.

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

Eppenseggel nem arrol van szo.
Arrol, hogy az openbsd a biztonsagot tuzte a zaszlajara. Kozben epp csak egy core komponenst tartottak benn minden nemu vizsgalat nelkul. Mennyivel felelosebb az o viselkedesuk, mint aze, aki belefejlesztett egy bugot? A vegeredmeny ugyanaz.

De tovabbra is, fel lehet hozni ezer masik kozosseget vagy ceget. A google szertepofogi, h ok mar csak ssl-en szolgaltatnak, az biztonsagos, kozben annyira nem vettek a faradtsagot, h az egesz alapjank egy _picit_ utananezzenek.

Persze google john legalabb nem beszel a masik felelossegerol, nagyarccal.

t

Ha jol ertem, azt mondod, hogy az OpenBSD-nek mindent, egyszerre ujra kene irnia. Ez egy egesz jo modell lenne, ha a fejlesztoi kapacitas vegtelen lenne. Hja de kerem, egy 300k soros crypo libet nullarol ujrairni az trivialis... Azt amugy tudod, hogy a library, mint olyan, mire valo? Bar a fenti kommented alapjan nyilvan nem.

Egyebkent pedig:

OpenSSL is written by monkeys

/*!
* Load CA certs from a file into a ::STACK. Note that it is somewhat misnamed;
* it doesn't really have anything to do with clients (except that a common use
* for a stack of CAs is to send it to the client). Actually, it doesn't have
* much to do with CAs, either, since it will load any old cert.
* \param file the file containing one or more certs.
* \return a ::STACK containing the certs.
*/
STACK_OF(X509_NAME) *SSL_load_client_CA_file(const char *file)
...

Pffff leesett az állam, még csak így amatőrként is. Ki a retek bírta azt az átláthatatlan részt befogadni/commitolni?

Köszi a linket!

Hat en sose voltam goto ellenes, de ez kicsapta a biztositekot most:

...
	if (0)
		{
err:
		if (ret != NULL) sk_X509_NAME_pop_free(ret,X509_NAME_free);
		ret=NULL;
		}
...

Mar elnezest, de HOGY LEHET VALAKI EKKORA ALLAT?

Hát nem tudom, szerintem ez annyira nem gáz. C-ben elég nehéz rendes hibakezelést írni. Az egészet nem láttam, az lehet, hogy gáz.

Nehez, nehez, de ennel rendesebbet egyaltalan nem nehez... es ezt ugy mondom, hogy sokakhoz hasonloan nekem is aranylag ritkan van dolgom C-ben, de errol a kodrol ordit, hogy balfekek irtak

Csak, hogy tanuljunk, hogyan lehetne szebben írni?

Például a függvény normál returnje utána írjuk az err:-t nem egy if (0)-ba?

Azzal az lehet a baj, hogy lehet, hogy vannak olyan dolgok amit mindig el kell végezni, akkor is ha hiba van, akkor is ha nincs, előbbi esetben a hibakezelés után. Ebben az esetben nem lehet visszatérni az if (0) előtt, vagy kódot kell duplikálni.

Meg sem árt, ha minél kevesebb exit point van egy függvényben.

Pont ez az eset van itt is.

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

de nekem nem tunik olyan ganynak: van 4 hiba hely ami utan fel kell szabaditani a ret-et + felszabaditani a lefoglalt mas memoriakat. rendes futas eseten csak a sima memoriat kell felszabaditani.

persze lehetne a goto helyett felszabaditani "helyben" a ret-et, de gondolom cel is volt hogy keruljek a kod duplikaciot.

biztos lehet szebben is megoldani, majd egy c guru leirja... :)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ha az if-en kivulre rakjak a labelt (lehetoseg szerint a fv vegere, lasd linux), maris sokkal szebb.

------------------
My Open-Source Android "Projects"

Szebbnek lehet, hogy szebb, de akkor nem működik. :) Vagy kell még egy unconditional goto ugrás is az abszolút végére.

G.

-

"Mar elnezest, de HOGY LEHET VALAKI EKKORA ALLAT?"

Arról nem a kóder tehet, hogy egy nyelv valamit nem tud, ezért taknyolni kell.

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

Ja aha, a nyelv miatt van, ofc.

Hja, csak a sokak által agyonfikázott try-catch-finally blokkban pont van erre nagyjából kulturált megoldás. Vagy pl. a C# using () {}-ja is elég hasznos tud lenni, hogy ne maradjon el egy-egy felszabadítás.

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

És még te tartod magad mindenek felett álló szoftverfejlesztőnek? Annyira egyértelmű, hogy a procedúrán ennyire kívülálló goto flagnek (főleg ha hibáról szól) a return ret; után van a helye. De igazad van, a C hibája, hogy ehelyett beletaknyoltak a kód közepébe egy if(0)-t. Eddig azt hittem, hogy aki try, catch, finally-t látott már az is automatikusan odatenné, mert ott a logikus, hiba a végére, de nem, szerinted tök normális ez a közepén, hogy if(0) és belegotozunk egy feltételes szerkezetbe (ami mondjuk még mindig eggyel kevésbé csúnya, mint vezérlési szerkezet közepére gotozni, de ettől még ez is gusztustalan marad).

"És még te tartod magad mindenek felett álló szoftverfejlesztőnek?"

Hol írtam ilyet?

" Eddig azt hittem, hogy aki try, catch, finally-t látott már az is automatikusan odatenné"

Vegyél már vissza az arcodból. Mondtam én, hogy _ez_ normális?

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

Úgy általában a hozzáállásodból ez jön le. Te mindig jobban tudod hogy mit hogy illene minden fejlesztőnek csinálnia, és hogy minden csak úgy jó ahogy te jónak tartod.

Na, megnéztem közben az eredeti kódot is. Azért egy picit árnyalja a képet. Egyrészt van még kód bőven a } után is. Szóval nem igazán tudod hova rakni. Gyakorlatilag try-finally-ra lefordítva ez egy függvény közepén lévő finally blokk, aminél a try rész a függvény 12. sorában lenne. Igen, ocsmány, de ezt tudod megcsinálni C-ben. Perpill nem is nagyon van rá jobb ötletem. (Illetve van, de az még rondább lenne).

De halljuk, hogyan lenne szebb ez a függvény C-ben, segédváltozó bevezetése nélkül?

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

"De halljuk, hogyan lenne szebb ez a függvény C-ben, segédváltozó bevezetése nélkül?"

Hallod, pont egy segédváltozós megoldást akartam bekommentelni egy nem sokkal efölött lévő komment fölé (ami szebb is, jobb is, olvashatóbb is). Segédváltozó nélkül tényleg csak annyit tudsz, hogy az utolsó 4 sort fellabelezed finally:-nak, return után meg err: és a végén a finally-ra gotozol (szerintem ez is szebb eggyel, de tényleg nem sokkal)

Magyarul, ugyanott tartunk, amit mondtam: C nyelv nem ad rá lehetőséget, hogy szebben, tömörebben old meg.

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

Tömörebbet nem is állítottam csak szebbet. Mert a vezérlési szerkezetbe vagy feltételes szerkezetbe gotozni csúnya dolog, a goto a procedurális gondolkodás része, a feltétel az ugrás előtt kell hogy legyen.

(Csak sokan ezt nem fogják fel, meg zt sem, hogy a gotot lehet ésszel is használni, ezért inkább csak annyit mondanak: "a goto rossz és ne használd")

Na de ha nem akarunk bevezetni segédváltozót (és miért is tennénk, plusz memória és semmi szükség rá), valamint megegyezhetünk abban, hogy a kódok sorrendjét nemigazán lehet felcserélni (lévén, hogy az if (0) {} utáni felszabadításnak ugyanúgy meg kell történnie), nagyon más megoldást nem látok annál, hogy

void bizbasz(...)
{
  // blabla, ha hiba van goto err

  if (0) {
  err:
    // tralala
  }

  // asdfasdf
}

helyett ezt írod:

void bizbasz(...)
{
  // blabla, ha hiba van goto err

  goto hurra;

  err:
    // tralala
  
  hurra:

  // asdfasdf
}

Amivel effektíve ugyanott vagy, kétlem, hogy az if (0) helyett más fordulna be oda. Egyik ocsmány, mert vezérlési szerkezetbe ugrasz, másik ocsmány, mert goto halmok hegyeit tartalmazza. Ezen kívül már csak a kódduplikálás van.

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

Az az egy segédváltozó annyira fájdalmas, hogy inkább ilyen kódot írnak?

Még a Linux kernel forrásban is inkább segédváltozóznak.

Igen is meg nem is. Sokak szerint az a szep, mert nincs goto akkor, masok szerint felesleges ram, CPU utasítás (bár értelmes fordító kioptimalizalhatja. De a lényeg az, hogy mindket esetben hiányzó nyelvi elemért kiált a dolog.

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

És pl. egy ilyen konstrukció (ilyesmi a Linux kernelre a jellemző)?
Csak a visszatérési értékre van segédváltozó, azzal meg a legtöbb fordító tud mit kezdeni. Kb. a kivételkezelés-féle stack visszagörgetést-destruktor hívást játszod le. Persze nyilván nyelvi elemmel kulturáltabb lehetne. De az openssl-féle "megoldást" nem tartom elfogadottnak, ha ilyet is lehet:

a=get_a();
if(!a){
   retval=-ENAGYABAJ;
   goto err_a;
}
b=get_b()
if(!b){
   retval=-ENAGYABAJ;
   goto err_b;
}
goto ret_success; /* egy bemenet – egy kimenet */
err_b: 
  free_a(a_ptr);

err_a: 
ret_success:
  return retval;

Egyébként nagyon akarsz, tudsz kivételkezelést megvalósítani C-ben, igaz, nem nyelvi elemként, inkább csak érdekességként írom (nem használnám): http://www.on-time.com/ddj0011.htm

Itt nem kifejezetten az exceptionok hiánya a probléma, hanem a finally blokké.

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

Aki a segédváltozó vs. goto témakört általánosságban meg akarja válaszolni, az nem ért hozzá.

A segédváltozó általában szebb, jobban olvasható, könnyebben áttekinthető kódot eredményez. Cserébe több prociidőt és memóriát igényel. Ha egy fél óra futásidejű program végrehajtása során egyszer jut arra az ágra, ahol ezt végre kell hajtani, akkor ez a jobb megoldás.

A gogo általában átláthatatlanabb, error-prone-abb (hogy mondják ezt magyarul?) kódhoz vezet. Cserébe kevesebb prociidő és memória kell neki. Ha a fél óra futásidejű program az idő nagy részét abban a ciklusban tölti, ahol ezt kell végrehajtogatnia, akkor a goto a jobb megoldás, mert ha nem goto lenne, akkor lehet, hogy fél óra helyett 35 perc lenne a futásidő.

Általában viszont mindaddig, amíg be nem bizonyosodik, hogy a teljesítmény a szűk keresztmetszet, érdemesebb a segédváltozós megoldást alkalmazni. Ennek az oka, hogy ha a teljesítmény nem gond (és nem szokott az lenni, illetve nem ilyesmik miatt szokott az lenni), akkor mindenképpen érdemesebb a szebb, módosíthatóbb, refaktorálhatóbb stb. - jobb programozói élményt nyújtó módszert választani.

Én azt tanultam, hogy premature optimization is the root of all evil.

Szerintem egy olyan kódot, amit várhatóan 1-nél többen fognak olvasni / használni, olvashatóra és karbantarthatóra kell megírni.

Goto nélkül, strukturáltan, kommentekkel.

Ha kész, jól működik, és kiderül, hogy lassan fut a fordító által elkövetett optimalizációk ellenére is, akkor meg lehet nézni, hogy mi miatt.

Ha azt találnám, hogy egy szép és jól olvasható kód kézzel csúnyává szétfaragása jelentősen gyorsítana egy tényleg időkritikus részt, lehet, hogy széttúrnám. Nem biztos. Feladattól és követelményektől függ.
De biztos nem túrnám szét, ha bármiféle biztonsággal vagy titkosítással kapcsolatos feladata lenne a kódnak.

Ránézésre ez a lib (akármiSSL) nem végez olyan feladatokat, amik időkritikusak, szerintem semmiféle kézi csúnyává optimalizálásra nem lehet mentség.

Egyébként, amikor még programozóként dolgoztam, voltak olyan feladatok, amiket jelentősen gyorsítani kellett ezért sokat vizsgálgattuk profilerrel a futást. Nem emlékszem egy esetre sem, amikor egy segédváltozó létrehozása okozott volna akkora overhead-et, hogy azt kellett volna valahogy kioptimalizálni kézzel.
Vagy azért, mert a fordító már úgyis kioptimalizálta magától, vagy azért, mert az overhead pici volt a valóban lassító tervezési hibák mellett.

En nem vagyok az ocsmany, de gyors kod hive, de ez azert eleg eros. Hogy az OpenSSL-nel nem lenne szempont a sebesseg? Mar hogyne lenne? Szerverek milliardjain fut, minden masodpercben szolgalja ki keresek millioit, ha itt nem szamit a teljesitmeny, akkor nem tudom hol igen.

Vajon pl. a F@szbuknak miért nincsen saját ssl implementációja? Kvázi php van.
Azoknak a szervereknek a milliárdjain nem az OpenSSL teljesítménykorlátaiba szoktak beleszaladni - hidd el! :D

Miert lenne, ha az OpenSSL is kelloen gyors? Nyilvan nem abba fognak belefutni, mert a PHP nagyobb tenyezo, de attol meg ne mondd mar nekem, hogy tokmindegy, hogy 1%-nyi CPU idot visz el, vagy 5-ot. Ez ilyen rendszereknel mar millio dollaros kerdes.

Te is írod az első kérdésedben, de még egyszer leírom, kicsit másképp: amíg nem (közel sem) az OpenSSL lesz a leglassabb egy softverstack-ben, addig máshol fogják keresni a dollármilliók megtakarításának lehetőségeit.

Vannak helyzetek amikor igenis szamit, pl. az ujabban elterjedt/terjedoben levo streaming szolgaltatasoknal nem mindegy, h 1 v. 0.1s alatt titkosit a koceraj, de meg a sima web kiszolgalasnal sem mindegy, nem egy statisztika es benchmark keszult az utobbi idoben pl. az ssh handshake lassusagarol es mikepp lehet tetemes (akar 30%) betoltesi idot nyerni egy kis ssl tuninggal.

---
pontscho / fresh!mindworkz

"egy kis ssl tuninggal" :D

Orulok, h sikerult leszurni a lenyeget. :)

---
pontscho / fresh!mindworkz

Az volt a lényeged, hogy ahol számít és kimérték, ott szoktak rajta tuningolni. Ez tök jó, meg örülök a példádnak, csak nem erről beszéltünk.

Tudom mirol beszeltetek, azert is batorkodtam megemliteni, h de, ott is szoktak ezzel szarakodni ahol a backend joval problemasabb. Ha nem igy lenne, akkor peldaul a hardver aes cipherek sem nottek volna bele az Intel vasakba.

---
pontscho / fresh!mindworkz

Jo lenne a mondandodat alatamasztani is valamivel. Most nagyjabol azt mondod, hogy a HW SSL gyorsito kartyak csak ugy poenbol keszultek.

Ugye nem kevered az SSL accelerátort a HSM dobozokkal?
Ha nem: SSL-t hol használnak nagy tömegben? Ismereteim szerint VPN-hez és https protokollhoz. Előbbihez valószínűleg jól jöhet bizonyos esetekben egy ilyen gyorsító kártya, de az igazán nagy tömegben használt https esetében...
Nem tudom, igaz-e, de épp ma olvastam, hogy _állítólag_ a googlenél a https-re való áttérés kb. 1%-os CPU használat növekedést okozott. Ez persze akár UL is lehet, de weben nem okoz akkora plusz terhelést, hogy emiatt szükség legyen ilyen gyorsításra. (vagy tudsz ellenpéldát?)

Nem tudom, igaz-e, de épp ma olvastam, hogy _állítólag_ a googlenél a https-re való áttérés kb. 1%-os CPU használat növekedést okozott.

Egyreszt nem mindegy gepparkon, az 1% is mocskos sok tud lenni. Masreszt valozinuleg ez koszonheto vagy egy hw ciphernek es/vagy a mar elvegzett optimalizacionak. Nyilvan nem egy nyers koddal fognak dolgozni, foleg ha mar az utolso putter via c3-ban is ott figyel egy padlock.

---
pontscho / fresh!mindworkz

> de az igazán nagy tömegben használt https esetében...

A YouTube elképesztő sávszélességen tolja ki a HTTPS forgalmat. Ott például 1% költségcsökkentés is marha nagy tétel. Kliensoldalon nyilván mindegy, de a szerverparkokban nagyon nem.

Ha egy kliens egy weblapot használ, a teljes időnek illetve a teljes számítási kapacitásnak vajon mekkora része esik az OpenSSL-re?

Nem mértem ki, mivel nem fejlesztettem ilyesmit, de feltételezem, hogy kevés.

Pl. arra számítanék, hogy a UI renderelés, illetve a másik oldalon az adatbázisból az adatok előkeresése illetve magának az adatnak a hálózaton áttolása több nagyságrenddel lassabb, mint a titkosítás szőröstül bőröstül.

De ettől függetlenül, ha most konkrétan az OpenSSL-t akarnánk gyorsabbá tenni, szerinted valaki kimérte azt, hogy az adott függvény a lassú, és éppen a segédváltozó miatt, vagy egyszerűen a programozó eldöntötte, hogy így írja meg, mert szerinte így gyorsabb?

Nem tudom a választ, de az a sejtésem, hogy a második.

Volt olyan kollégám, aki mindenféle trükkökkel írt C-ben kódot elsőre, merthogy úgy gyorsabb lesz. Aztán amikor megnéztük, kiderült, hogy a gcc pontosan ugyanarra az assembly programra fordította le, mint az agyontrükközetlen változatot.

Na ez az, ami szerintem nagyon rossz megközelítés.

Egyébként a kérdésedre válaszolva, hogy mi az, ahol szerintem szempont a sebesség:
az én múltamban ezek fordultak elő:
- játék - adott hw követelményből kihozni a legjobbat. Férjen bele még több pont, még több 3D effekt és számolás, de ne essen az FPS x alá adott procival és videokártyával; a video lehessen még nagyobb felbontású és hosszabb de a 4x sebességű CD-ről azért le lehessen játszani; az AI tudjon tovább előre gondolkodni, több esetet megvizsgálni, hosszabb utat keresni anélkül, hogy a neki engedélyezett időnél többet használna.
- real time rendszer, hálózat minőség mérése, adatfeldolgozás - minél több mérőeszköz adatáramát tudja feldolgozni egy számítógép
- adatok tárolása adatbázisban (fájl betöltés és eltárolás legyen meg 15s alatt, pl. amikor alapból 30 percnél indult az első változattal, másik esetben néhány fájl betöltése max. 2 óra alatt, miközben a régi rendszernek 24 óra nem volt elég).
- adatok visszakeresése adatbázisból (pár tíz millió adatrekord, egy időben 1000 kérés, 1 másodperc alatti válaszidő weblap rendeléssel együtt). Aztán folyamatosan jönnek az új kérések, bonyolítva a lekérdezést, de az NFR nem változik.

Ezekben az esetekben mindenhol jól azonosítható volt egy konkrét szűk keresztmetszet, amit javítani kellett.
Hiába javítottunk volna más rendszerkomponenst, vagy csak még több félig feldolgozott adat gyűlt volna fel az igazi problémás elem előtt, vagy amikor végre valami kijött, az gyorsabban ért volna el a cső végére - de az idő még nagyobb részében várt volna az a feldolgozó sor.

C) Igy írta meg, mert igy találta szebbnek.

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

Ahogy azt korábban is írtam:

Amíg egyedül dolgozik, hobbi projekten, addig úgy írja meg, ahogy tetszik.

Ha többen dolgoznak, használják, karbantartják, akkor érdemes megbeszélni, hogy milyen stílust kövessen mindenki.

A fenti példában az az egy ember a közösen megbeszélt stílustól eltért, és erre az volt a magyarázata, hogy mert így majd gyorsabb lesz.

"segédváltozó"

Naja, csak az emberek nagy része akkor kezd el gotot használni, mikor a segédváltozó bevezetésére csillió helyen át kellene szerkeszteni az if-eket. Arról persze, megint el lehet vitatkozni, hogy mi a szebb: 1(+) segédváltozó bevezetése vagy egy jól definiált pontra ugrani. Véleményem szerint bizonyos esetekben sokkal szebb az utóbbi.

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

Ez viszont +1.

Valahol a segédváltozó a szebb, valahol a goto, az a max 4 bájtnyi segédváltozó meg semmin nem fog változtatni, főleg alacsony szintű nyelv normálisan optimalizáló fordítóprogramja esetén.

Elképzelhető.

Amíg a kód olvasható és karbantartható marad, addig nekem nem fáj, ha van benne egy goto is.

Én annak idején nem használtam goto-t, inkább máshogy oldottam meg.

vicces

Már csak azt nem értem, hogy voltak képesek weboldalt készíteni ezzel a ronda betűtípussal.

OpenBSD "humor". Lap alja.

"This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags"

--
trey @ gépház

Zsír ez az anti-dizájn, de miért kezdődik az oldal egy <table>-lel és <tr>-rel, mikor utána semmi táblázat nem jön, és a tagek sincsenek bezárva? :)

Így marad hely a végére :)

Érdekes humor - én akkor inkább leszek hipster, de pénzt nem kapnak :)

szóval ezután ami open volt, az libre lesz. Már várom a következőket: librearena, librebsd, libregl, libredns, libressh, libreelec, librejdk, librettd, librevpn, librewrt, ...

és természetesen hívjuk ezeket libresource alkalmazásoknak :)

Az OpenSSH-t az OpenBSD Foundation csinálja, azt nem fogják átkeresztelni :)

Jönnek fel a latinok... :)

Az lesz jo, amikor a FOSS-t (Free & Open Source Software) mar FLOSS-nak (Free, Libre & Open Source Software) fogjak hivni, es a FOSDEM -et is atkeresztelik FLOSSDEM-re.

A fogkremgyartok nagyot fognak kaszalni.

--
|8]

Kihagytad a libretard-ot :)

"It was clear that a fork was the only solution and that working with upstream would be a futile effort."

http://www.tedunangst.com/flak/post/origins-of-libressl

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."
Instant Coelho

http://arstechnica.com/information-technology/2014/04/openssl-code-beyond-repair-claims-creator-of-libressl-fork/

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."
Instant Coelho

Na akkor mikor fog kifingani az OpenSSL projekt?

Könnyen meglehet. Vagy nem. Eleinte senki sem tett volna egy lyukas garast sem arra, hogy az XFree86 mellett az X.Org-ból lesz valami. Az előbbire már talán ez a generáció nem is emlékszik.

--
trey @ gépház

Fele annyit mint eddig :D
_____________________________
Powered by 1,3,7-trimetilxantin

Legkésőbb 2038-ban. :)

Troll: most jöttem rá, hogy ez az egész egy L-es méretű intim betétről szól. :D
Update: lehet, hogy nem csak itthon divat a "tisztább, szárazabb, biztonságosabb érzés" szlogen? Még a végén kiderül, hogy én trollkodok, ők meg pont ezért választották ezt a nevet... :D

Hát, sajnos a Libre szót és származékait Magyarországon igencsak lejáratták.

Az emberek 99%-ának egy szakállas piros-zöld szemüveges okostojás jut eszébe, aki kiáll a TV-be és elmeséli, hogy minden embernek jogában áll az étteremben tele szájjal zabálni. Miért is ne csámcsoghatna, ha őt ez teszi boldoggá?

Namost a Liberofiszról, meg LibreSSL-ről nekem rögtön a félhülye liberális megmondóemberek jutnak eszembe és igencsak nehezemre esik a programra ezek után ráklikkelni. Szerencsésebb országokban talán nincs az embereknek efféle komplexusa a Libre szó hallatán.

Érdekes, hogy te belelátsz az emberek 99%-ának a fejébe és belevetíted a saját sztereotípiáidat.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

+1

Azt értem, hogy te mire asszociálsz a libre szóról, de azt nem tudom, hogy honnan jött az asszociáció.

Én a konkrét szóval csak portugál nyelvet tanulva találkoztam, hasonló szó lehetett esetleg a libress betét márka meg a libri könyvesbolt.

De szakállas piros-zöld szemüveges okostojásra nem emlékszem, aki ezt a szót használta volna.

Miről maradtam le?

Magyarországon a liberálisok valahogy fejjel lefelé látnak mindent. Az átlag ember tudja, hogy mi a jó, mi a rossz, de ezek mintha a Marsról jöttek volna és egyáltalán nincsenek képben a helyi viszonyokkal. Piros-zöld szemüveges idióták, akik ontják magukból a bölcsességeket.

Gondolj a jogvédőkre (pl. TASZ), akik felemelik a szavukat a gonosz férfi ellen, aki szegény ártatlan romát fagyállóval mérgezte meg, mert rászorultságában lopott a borából...

De veheted a szocialistákat is, akik Borsod megyében a demokrácia és sajtószabadság védelméről papoltak. Arra nincs pénz, hogy újságot vegyenek.

Nyilván nem kell csodálkozni a Jobbik eredményén, csak azon, hogy még volt, aki rájuk szavazott.

Á, leesett. Szóval a libre szóról a liberálisok jutottak eszedbe.

Valóban közel áll egymáshoz a kettő, én kérek elnézést, hogy nem jöttem rá magamtól.

A portugál nyelvtudásom lehet az oka.

-- dupla --

Igazi tortúra megnyomni a LibreOffice ikont. Szólni kellene nekik, hogy a program neve nem elég polkorrekt és sok másként gondolkodó emberben komplexusokat szül.

Megyek is Strasbourgba panaszkodni. :)

Emberek, akik mindenhova odagondolják a saját politikai véleményüket…

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Erről a hozzászólásról nekem is egy félhülye humanoid jut eszembe.

Ha már...
"Szerencsésebb országokban talán nincs..."

Nem tudom, szerinted Németország a szerencsésebb országok közé tartozik-e, de a liberálisokra (mint politikai mozgalomra) ott is úgy néz a többség, mint a véres takonyra, amit éppen a vasárnapi levesbe tüsszentettél. Elvtelenek, elitisták, haszonlesők, stb. A Libre szó mégsem vált ki ilyen görcsös reakciókat, még a nácizmus szülőföldjén, Münchenben sem.

Amúgy nagyjából nekem is az a véleményem, mint a németeké.

________________________________________
"The vision of Christ that thou dost see
Is my vision’s greatest enemy."

^ offtopic, bullshit, témáhozvalami?

Doktor Jacobyra gondolsz? :-)
Tényleg mélyen hathatott a tudatalattira Lynch mesterműve ha még két évtized után is archeképek ugranak be onnan.

http://twinpeaks.wikia.com/wiki/Lawrence_Jacoby?file=Doctor_Jacoby.jpg

Mik vannak! Pont most rakta műsorra az M1 a teljes Twin Peaks sorozatot.