Balhé a PHP Suhosin patch körül

Debian

A PHP-hoz kifejlesztett Suhosin biztonsági patch egyes rendszereken crash-t okozhat. Egy, a Debian fejlesztők által elkészített patch ugyan javítja ezt a megbízhatósági problémát, ám cserébe olyan változtatást is hoz, amely potenciális biztonsági sebezhetőségnek tekinthető. A napokban vita kerekedett arról, hogy ki, mit és hol kuszált össze.

A Debian projekt fejlesztői észrevették, hogy a Suhosin patch egyes architektúrákon összeomlást okoz. Hogy orvosolják a problémát, egy patch-et készítettek, majd megpróbáltak kapcsolatba lépni Stefan Esser-rel, a Suhosin patch megalkotójával. Egy levelet küldtek neki a patch-csel kapcsolatban február 10-én. Esser azonban egy későbbi blogbejegyzésben (Patch breaks Suhosin Security Feature in Debian Unstable/Testing) bevallotta, hogy két hónapja nem nézett rá a Hardened PHP projekt e-mailjeire. A válasz hiányában a Debian projekt úgy döntött, hogy elfogadja a patch-et. Ezzel az összeomlások megszűntek.

Később, ahogy Esser elolvasta leveleit, belebotlott a Debian által készített patch-be. Közelebbről megvizsgálva arra jutott, hogy a patch valóban megoldja az összeomlás problémát, de ugyanakkor sérülékenyebbé is teszi a biztonsági megoldást.

Szóval "sz.r került a palacsintába". Esser azonban ahelyett, hogy segített volna a hibát gyorsan orvosolni, blogbejegyzésben kezdte ecsetleni az esetet a saját szemszögéből, a Debian viselkedését az OpenSSL ügyben tapasztaltakhoz hasonlítva. Esser blogbejegyzése nyomán nagyrészt feltételezésekkel és sértett hiúsággal fűszerezett, túlfűtött vita kezdődött. Ennek folyományaként Esser törölte a blogbejegyzés egyes részeit, más részeket újraírt, majd lezárta a hozzászólási lehetőséget. Emellett visszavonta a javított patch elkészítésére tett korábbi javaslatát.

Az ügy jelenleg ott tart, hogy nincs olyan patch, amely megszüntetné a crash-t és egyben ne hordozna magában biztonság szempontjából kifogásolható "feature"-öket.

A részletek itt.

( NagyZ v | 2010. 03. 04., cs – 10:57 )

projectlead, de nemolvas emaileket? az ilyen minek csinal ilyet? menjen kapalni

ugy latom mar javitva van a 0.9.9.1 verzioban:
http://www.suspekt.org/2010/03/05/suhosin-patch-0991/
- fixed some crashbugs for IA64 architecture
- check return value of mprotect() to ensure that memory is read only - credits: PAX Team
- fixed mprotect() call - encrypted pointer was used in revoked 0.9.9 - credits: PAX Team
- added additional hardening to destructor protection
- added pointer obfuscation to memory manager

Azt nem tudom, biztosan.

Ha lenne olyan szemely, mely magat alkalmasabbnak erezne erre a feladatra es erdekli a projekt, mar forkolt volna.

De nem ez a lényeg, hanem az illető felelőssége és viselkedése. Nálunk az ilyet bunkónak hívják.

"You get what you pay for", remelem ertheto... ;^)

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Akkor lenne igazad, ha alapvetően fizetős software -ről lenne szó, amiért senki sem fizet. De ez ingyévan.
Ha pedig, valaki ingyen elvállal egy feladatot, akkor ne legyen felháborodva rajta, hogy ugyanúgy lesznek, akik számon kérik ezt rajta. Akárcsak egy fizetős szolgáltatás esetén.
Az számít, hogy elvállalta, nem az, hogy mennyiért.
--
- Jó estét - zökkent le nehézkesen a tomporára. - Én vagyok a konyhamester ajánlata. Felajánlhatom önöknek a testrészeimet?

ROFL. Tudod a világ a kommie fejekben működik így, a valóság picit más.
Annó, elvállalta vagy rámaradt a projectvezetőség. Aztán senki nem tette szóvá, hogy nincs is vezetőség, mivel a kutya nem foglalkozott vele. Most, hogy balhé van megy a felelős keresés.
Egy emberen csak annyit kérhetsz számon, amennyiben ellentételezted az ő munkáját. Ez az ellentételezés lehet anyagi vagy nem anyagi, de semmiért nem kérhetsz érte számon semmit. a szükség lett volna a projectnél egy jobb projectvezetőre, akkor már rég átvette volna valaki az irányítást.

Pl. Megírsz egy kódot mert szükséged van rá. Kipublikálod ingyen, hogy mások is használják. Aztán 3 hónap múlva jön egy arc és számon kéri rajtad, hogy miért nem tartod karban és miért nem fejleszted. Jól esne ez neked? Ugye, hogy nem...

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Bocsi, de miért ne tehetnéd meg?

Fizettek azért, hogy a kódodat használhassák? NEM.
Fizettek, azért, hogy karbantartsd a kódod? NEM.
Azért fizettetek, mert elhitték, hogy fasza a kódod? NEM.
Szabadon hozzáférhető a forrás, hogy kijavíthassák a hibát? IGEN.
Rámutatott a szerző arra, hogy ez a javítás hibás? IGEN.
Ez alapján készült újabb javítás vagy fork? NEM.

Az egész történet jól példázza a FOSS minőségbiztosításbeli életképtelenségét.
Addig amíg nincs fix megállapodás arról, hogy hogyan és milyen formában van ellentételezve egy adott fejlesztő munkája és ezért mit kell nyújtania, az egész csak emodráma.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Téves. A dolog mindig úgy működik, hogy látod a feladatot, látod az ellentételezést, eldöntöd, hogy vállalod-e vagy sem. Az sem igaz, hogy ingyen csinálta, ez neki nagyon jó reklám lett volna, ha nem üt be ez a krach.

Tehát tudta, hogy mennyit fizetnek, elvállalta. Innen kezdve viszont egy másik szabály számít: együttműködési kötelezettsége van, úgy kell viselkednie, ahogy az adott helyzetben az elvárható. Aki nem olvas két hónapig emailt, az nem úgy viselkedett, mert:
1. vagy unja már az egészet, akkor köteles szólni, hogy keressenek a helyére mást (ismétlem: köteles)
2. vagy átmeneti időzavarba került, ez most mindegy, hogy ki akarta venni a szabadságát, a főállásában borult rá egy halom munka vagy beteg lett, akkor meg neki kellett volna gondoskodnia helyettesítésről.

Az ilyen lapítunk, mint (insert kedvenc szólás here) módszer helytelen, mert a dolog nem megy előre, akinek meg előre kellene lendíteni, az meg nem tud róla, hogy valamit lépnie kellene.

úgyhogy ezt a balhét a két hónapig emailt nem olvasó viszi el teljes mértékben. és nem azért, mert rossz patchet adott ki, hanem azért, mert nem működött együtt.

van a projektnek vezetője, majd eldönti, mit kell lépni.
beperelni nyilván nem fogja, leginkább azért, mert az unstable ágban elkapott bugból ekkora hisztériát kavarni az vihar a biliben.
van a projektnek szabályrendszere, általam legvalószínűbbnek tartott "büntetés" az, hogy megvonják a kommit jogát, de ezt eldönti, aki illetékes.

én nem használok testinget, unstable-t meg pláne nem, ergo engem kár nem ért. a reakcióm pedig az okozott kárral arányos.

Nem tudom, de ugye te is érzed, hogy mennyire érzik a project résztvevői fontosnak a projectet, ha olyan project vezetőt tartanak aki hónapokig nem olvas leveleket.

Egy open source projectet nem kéne összekeverni egy céges projecttel. Mert ahogy nincs planning az open source mögött, ugyanígy nincs előre definiált management struktúra. Ha megnézed, a legtöbb project vezetője az aki a projectet elindította, szimplán csak azért, mert eleinte ő olvasztotta bele más fejlesztők munkáját, és ő volt az aki valamennyire koordinálta az egészet.

Továbbra is kénytelen vagyok azt ismételgetni: Amíg nincs egy írásos szerződésed a project kapcsán, addig NINCSENEK kötelességeid, NINCS felelősséged, NEM kérhetnek rajtad számon semmit.

Egyetlen járható út ha nem tetszik a project menete, hogy forkolják. Ezt nem tették meg, innen kezdve nincs értelme miről vitatkozni.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Miért ne lenne planning? Miért ne lenne előre definiált management struktúra? Hivatalosan választott vezető van, hivatalosan választott menedzsment van, hivatalosan korrekten kitűzött projekt célok vannak, nem értem, miről beszélsz.

Az írásos szerződést csak kelet-balkánon erőltetik, a fejlett világban elég az adott szó is. Másrészt meg miből gondolod, hogy nincs írásos szerződés vagy legalább valami ezzel egyenértékű? Ilyen szintű patcheket nem küldhet be akárki, amely patchek közvetlenül mennek a forráskód verziókezelőbe, sokkal értelmesebb lenne azt feltételezni, hogy aki commit jogot kapott, az kapott előtte írásos szabályzatot is, amit nyugodtan felfoghatsz szerződésként.

Én, veled ellentétben, azt gondolom, hogy azzal a két hónapos hallgatással az illető megszegte azt a megállapodást, amit korábban, mint patch kommiter, elfogadott. A balhé az ő sara.

Remélem, hogyha alaposabban megismered a debiant, elmúlik a kényszer az ismételgetésre.
Az meg, hogy átdolgozták a patch-ét, az nem egyenértékű a forkolással?

Hogyne, olyan sokat ér a fejlett világban az adott szó, hogy a legnagyobb autógyártók egyike is szimplán kihátrált a szerződéskötés mögül, amikor a cégvezetés megkérte, hogy akkor legyen ez írásba foglalva. Régi mondás: Szó elszáll az írás megmarad!

Egy ingyenes project esetében, hülye lenne a fejlesztő bármilyen felelősséget vállalni. Nem véletlenül van majd az összes open-source kód liszenszében, hogy a fejlesztők semmiféle felelősséget vagy garanciát nem vállalnak.

A legtöbb FOSS projectnél a commit jog sokszor bemondás, gesztus alapú. Különösen, ha olyan featuret akar committelni az illető ami záptojás a többi fejlesztőnek, vagy jelentősen növeli az alkalmazás epenisz faktorját.
Nem egyszer van, amikor egy lelkes fejlesztőnek adnak commit jogot, mondjuk fordítás commitálására, és mire észbe kapnak már a kódban turkál.

Ha átdolgozták a patchét és ez egyenértékű a forkkal, akkor miért is rinyálnak a fejlesztőnek és miért ugyanazon a néven futtatják?
Ha valaki forkolná bármelyik kódomat és utána azt ugyanazon a néven futtatná, akkor simán rálépnék a tökére és hanyatt lökném, függetlenül, hogy javított vagy rontott rajta, mert ez a felhasználók megtévesztése lenne. És ha arról van szó, a felhasználók megtévesztésében a Debian projectnek igen nagy gyakorlata van (lásd: cdrtools-wodim mizéria).

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"Nem véletlenül van majd az összes open-source kód liszenszében, hogy a fejlesztők semmiféle felelősséget vagy garanciát nem vállalnak.": nem véletlenül van az összes program licenszében, hogy a fejlesztők semmiféle felelősséget nem vállalnak. Ha az ms megteheti, hogy a pénzért árult programért nem vállal felelősséget, akkor a debian is.

A sorrendet nem kellene elfelejteni. Jött a patch, nem jó, keresték, próbáltak kapcsolatba kerülni vele, nem válaszolt, ezek után átdolgozták.

De összességében egy dolgot tudok javasolni: nem tetszik a debian (vagy a debian projektben valami), akkor ne használd. Az nem viszi előbbre se a világot, se a te meg még pár kollégád sorsát, hogy nagy erőfeszítéseket tesztek üres fikázás terén, csak az időtöket viszi el.

A problémát ott érzem, hogy az átdolgozás után, azonos néven committelték a Debianban. Ha átütik a csomag nevét a kutya sem foglalkozott volna vele.

Attól, hogy az ember használ valamit még nem köteles szeretnie is azt.
Speciel favágáshoz baltát használok, holott a bozótvágókést sokkal jobban szeretem. Ettől nem fogok bozótvágókést használni favágásra és utána rinyálni, hogy milyen szar. Ugyanígy ha a bozótvágókés alkalmatlan bozótirtásra, akkor ugyanúgy fogom fikázni, pedig sokkal jobban szeretem, mint a baltát.

Az üres fikázásnak lehet az a célja, hogy az ember ideje gyorsabban és szórakoztatóan teljen. Mindössze fogadóképes fórumitákra van szükség. Hogy ez nekik idő és agysejtvesztést okoz az már az ő problémájuk. ;)
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

ugye tisztaban vagy vele, hogy nagyon sok(ha nem minden) disztro maintenerei peccselik a csomagokat.
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
itt pl. ossze van szedve, hogy miert erdemes varni/egyuttmukodni az upstream-mel, es leirja azokat az eseteket is amikor erdemesebb az azonnali intezkedes.

Tyrael

A patcheléssel egyetértek, ha:
a, az csak rendszerintegritáshoz szükséges mértékben módosítja az alkalmazást
b, kritikus hibát javít stabil ágban
c, elfogadott és beemelt az upstream által
Tehát, ha valamit patchelnek egy disztróban, az csak akkor kerüljön stabil ágba ha az az upstream által elfogadott. Ehhez, kooperáció kell.

Minden egyéb esetben, a patchelt verzió, legyen könnyen és egyszerűen megkülönböztethető.
Az általad linkelt részben nem értek egyet a szoftver szabadalmi, "egyszer majd beolvasztásra kerül a patch" és a "döglött upstream" kifogással. Ez esetben mindig fork legyen, mégha ez csak átnevezést is takar! Pl.: Firefox néven ne Iceweasel induljon, mert EZ megtévesztés. Oylan mintha bemennél egy szórakozóhelyre és kérnél egy coca-colát, mire kapnál egy pepsit egri bikavérrel felöntve és közölné a csapos, hogy náluk a patchelt coca-cola.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

most kerdojelezted meg a suhosin letjogosultsagat.
upstream nem fogadta be, megis terjesztik stable patchset-kent.

de visszaterve az eredeti problemara, ha talalt valaki egy kritikus bugot a suhosinban (mondjuk azt, hogy crashel IA64-en), es erre az upstream azt valaszolja, hogy
- nem valaszol/nem elerheto
- szerinte ez nem hiba(leszarja hogy mukodik-e IA64-en)

akkor szerinted mit kellene tenni?
- dobni a debian eseteben a teljes IA64 supportot, mondvan az upstream szerint senki sem hasznalja (btw. asszem a php.net szerverei is azon futnak)
- dobni a suhosin supportot a teljes IA64 agon.
- patchelni es atnevezni (ami esetben szerintem a csomagkezelo nem fogja frissiteni a "php5-cli"-t a "php5-cli-forkjavitott" csomagra, meg hatalmas kavarodast fog kivaltani a userek kozt)
- vagy megpatcheled, es varod hogy reagaljon valamit az upstream (beolvasztja a patchet, vagy csinal jobbat)

Tyrael

Suhosinnak azert van letjogosultsaga, mert nem akarjak beolvasztani. Mint ilyen nem is PHP neven fut.

Debian eseteben tobb lehetoseguk is van:
- Dobjak a teljes security fixet IA64 vonalon, a PHP.net pedig szopjon a sajat security policyjaval. (Ez kb. az lenne mikor a kigyo a sajat farkaba harap.)
- Patchelni, atnevezni, dummy csomagot hozza letrehozni. Ehhez a maintenerek rohadtul ertenek Debiannal. (Lasd:korabbi csomagok)
- Patchet elkuldik a maintainernek es addig a IA64-es agat security nelkul hagyjak, majd beolvasztas utan releaselik.

A tortenethez az is hozzatartozik, hogy emlekeim szerint egy olyan levlistara kuldtek a patchet, amin nincs forgalom.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

pont azt irtad, hogy ami jo, azt olvasszak be, es varjak meg az upstreamet, ne patchelje mas.
itt a suhosin a pelda arra, hogy valami lehet jo ugy is, hogy az upstream nem akarja tudja (atmenetileg, vagy soha) befogadni.
amugy jokat szoktal irni, sajnalom, hogy most ennyire nem (akarod) erteni, amit irok.
amugy lehet hogy mar irtam is, de a suhosin eredetileg hardened-php neven futott, csak a php license nem engedi, hogy a derived work-ot php neven terjesszek, ezert lett suhosin belole.

- Dobjak a teljes security fixet IA64 vonalon, a PHP.net pedig szopjon a sajat security policyjaval. (Ez kb. az lenne mikor a kigyo a sajat farkaba harap.)
* Debiannal asszem nem lehet bent olyan csomag a stable agban, ami nem letezik es vagy nem stable minden altaluk supportalt architechturan, es amugy sem tehetik meg, hogy menet kozben megszuntetik egy addig supportalt csomagot vagy hagyjak javitas nelkul.
a php.net emlegeteset itt nem ertem.

- Patchelni, atnevezni, dummy csomagot hozza letrehozni. Ehhez a maintenerek rohadtul ertenek Debiannal. (Lasd:korabbi csomagok)
* ezt 2 verzio kozott meg lehet csinalni (etch - lenny), de menet kozben kaoszt okozna, es nem is biztos, hogy megoldhato, hogy apt-get update apt-get upgrade felajanlja, hogy frissiteni fogja A csomagot, aminek soran leszedi A csomagot (php) teljes fuggosegevel es felrakja B csomagot (patkolt-php) es felrakja a teljes korabbi fuggoseget, persze ehhez az is kellene, hogy minden php-ra dependelo csomag frissitve legyen, mert a dependecia listajat at kell irni, hogy ne csak a php, hanem a patkolt-php csomag is kielegitse, es ha elfogadjuk az ervelesed, minden csomagra meg kellene csinalni, minden upstream altal nem (azonnal) befogadott nelkulozhetetlen patch eseten.

- Patchet elkuldik a maintainernek es addig a IA64-es agat security nelkul hagyjak, majd beolvasztas utan releaselik.
* Nem tehetik, ok nem ilyen PHP pistikek akik php-nuke-ot fejlesztenek, ha ezt megtennek egyreszt nem tartanak be a sajat support policy-juket, masreszt emiatt lemorzsolodna a felhasznalobazisuk.
Ki akarna olyan disztrot hasznalni, ahol egy lehagyott pontosvesszo miatti crash javitasa mondjuk eltart 3 napig, mert az upstream hetvegen lent van pecazni toparton, es csak o rakhatja bele.

Es azt is tudni kell ugye, hogy altalaban a debian-nal ugy mennek a release-ek, hogy kivalasztanak egy verziot, ami x ideig ha kritikus hiba nelkul fut unstable-ben, testing-ben, akkor bekerulhet a stable-be, de ott mar nem jonnek a kov release-ig verzio frissitesek, csak security bugfixek, amiket az upstream nem is ad ki kulon, mert azt mondja, hogy frissits verziot, hanem a distro maintainerei backportolnak vissza az altaluk hasznalt verziora.

Amugy ezt az egesz patcheljen a disztributor dolgot is linus inditotta utjara, nyugodtan lehet ot is szidni ilyenkor. :D

"A tortenethez az is hozzatartozik, hogy emlekeim szerint egy olyan levlistara kuldtek a patchet, amin nincs forgalom. "

lentebb irtam hogy tortent:
a suhosin sajat weboldalan a "ha bugot talaltal itt jelezheted" emailcimre kuldtek a debian-osok a patchet, ezt nem olvasta Stefan arra hivatkozva, hogy altalaban nem ott jelzik neki a hibakat (hozzateszem meg mindig nincs bugtrackere a suhosin-nak, de mar legalabb elkezdte Stefan keresni valamit a celra, csak semmi sem eleg jo neki)

Tyrael

"Az írásos szerződést csak kelet-balkánon erőltetik, a fejlett világban elég az adott szó is"

Ez eros sarkitas es speciel ugy igaz, hogy uzleti megbeszeleseken eleg a szobeli megallapodas is, nem kotelezo az irasba foglalas. Nem csak a "feljett" nyugaton, nalunk is. Aki vezeto, az ilyet altalaban tud.

be is utott.
a sajat cege/munkahelye egeszen veletlenul egy security consulant ceg:
http://sektioneins.com/en/index/
a php-security csapatban vegzett munkaja, es a hardened-php/suhosin fejlesztese miatt keresett eloado, rengeteget utazik konferenciakra eloadni (koltsegteritessel), illetve -gondolom- rengeteg megrendelest hoz az ismertseg, amit ezzel a munkaval szerzett.
szoval lehet hogy ellenszolgaltatas nelkul csinalta/csinalja, az is lehet, hogy onzetlenul, de hogy nem kifizetodo a munkaja, azt ketlem.

Tyrael

te láttál itt olyan véleményt, hogy köteles karbantartani a hobbiprojektjét?
az a vélemény hangzott el, hogy együttműködni köteles, ezt pedig elég nehéz lenne cáfolni.

persze azon is vitázhatnánk, hogy amit produkciós területre, ilyen nagy felhasználásra szánnak, az hobbi projekt-e. a hobbi projekteket nem szokták kiadni.

az mióta saját projekt, amit "a világ minden debian gépére" kiraknak?
az együttműködés nem feltétlenül azt jelenti, hogy javítja a patchet, csak annyit, hogyha keresik, válaszol és megegyeznek, hogy ki mit csinál. Akár el is tilthatja a debianosokat a patch használatától, csak legyen kimondva és az érdekeltek tudjanak róla, hogy mi a döntés. Ez az együttműködési kötelezettség.

Az, hogy lapítunk mint sz.r a fűben, nem együttműködés, az meg pláne nem, hogy utána meg borogatjuk a zománcos edényt.

az mióta saját projekt, amit "a világ minden debian gépére" kiraknak?

nem hiszem, hogy kérte, pláne kényszerítette volna a debian-t, hogy márpedig használják fel a patchét :)

Ez az együttműködési kötelezettség

a K-PAX bolygón lehet, mifelénk nincs ilyen kötelezettség :)

az a vélemény hangzott el, hogy együttműködni köteles, ezt pedig elég nehéz lenne cáfolni.

Tudtommal ha valaki ingyen csinal valamit csak ugy, es azt kiadja jofejsegbol a kozossegnek, akkor valojaban a kozossegnek kellene megkoszonni, h ilyen jo arc. Legalabbis valami ilyesmit mondanak errefele mindig mikor valaki szamon mer kerni egy FLOSS projecten valamit. :)

ilyen nagy felhasználásra szánnak, az hobbi projekt-e. a hobbi projekteket nem szokták kiadni

Amig nem erkezik a munkajaert cserebe egy zsiros osszeg minden honapban, az bizony hobbi project.

---
pontscho / fresh!mindworkz

tudtommal ha valaki akadályozza a közösséget, akkor nem köszönet jár érte, hanem seggberúgás. az nem jófejség, hogy eltűnik és utána az özönvíz. azzal, hogy kiadta a patchet, felelőssége is keletkezett.

Nem az a kérdés, kap-e érte pénzt, az a kérdés, amikor elvállalta/hozzáfogott, akkor megegyeztek-e a pénzben. Uyanis nem az számít, hogy mennyiért csinálod, az számít, hogy az előzetesen kialkudott feltételekhez tartja-e magát mindkét fél. Ha ingyen vállalta, akkor ingyen kell együttműködnie. Ha ingyen nem vállalja, akkor nyisson vitát erről az illetékesekkel.

Egyébként meg aki ebből él, az nem ingyen vállalta, mégha nem is mindig onnan érkezik a lé, ahova a munkája eredménye ment.

De vegyünk egy egyszerű példát. Megkér testvéred/apósod/rokonod, hogy ugyan menj már át segíteni megszögelni a kerítést és te megígéred. Tudod, hogy baráti segítségről van szó, nem pénzért mész. De megígéred. Majd nem mész át. Dühösek lesznek rád? igen. Joggal? IGEN.

az előzetesen kialkudott feltételekhez tartja-e magát mindkét fél. Ha ingyen vállalta, akkor ingyen kell együttműködnie. Ha ingyen nem vállalja, akkor nyisson vitát erről az illetékesekkel

miféle illetékesekkel? :)))

komolyan mondom bohóc vagy

Megkér testvéred/apósod/rokonod, hogy ugyan menj már át segíteni megszögelni a kerítést és te megígéred

nem kérte meg senki semmire és ő nem ígért meg semmit senkinek, HTH

az nem jófejség, hogy eltűnik és utána az özönvíz.

Es ha mondjuk az edesanyjat gyaszolja valaki es azert tunik el ? Nem hogy egy FLOSS projectet, de egyeb minden mast is leszarnek egy ehhez hasonlo foku problema eseten... de ennel joval kisebb eseten is.

azzal, hogy kiadta a patchet, felelőssége is keletkezett

Nem azert van a kozosseg, h ha valami tortenik a lead-del akkor at tudja venni a fejlesztest ? Mert ennek most jol ellent mondtal.

Nem az a kérdés, kap-e érte pénzt, az a kérdés, amikor elvállalta/hozzáfogott, akkor megegyeztek-e a pénzben. Uyanis nem az számít, hogy mennyiért csinálod, az számít, hogy az előzetesen kialkudott feltételekhez tartja-e magát mindkét fél. Ha ingyen vállalta, akkor ingyen kell együttműködnie. Ha ingyen nem vállalja, akkor nyisson vitát erről az illetékesekkel.

Ha en kirakom a honlapomra a HelloWorld legujabb atom valtozatat, akkor kivel allapodtam meg ? Magammal tuti, de magammal szemben meg is tartok minden megallapodast amit magammal kotottem. Attol, h valami elerheto ingyen, attol meg nem jar hozza automatikusan support. Plane, h a FLOSS melletti egyik legnagyobb erv, h akadalyoztatottsag illetve egyeb problema eseten a kozosseg siman atveheti a cucc fejleszteset. A lehetoseg adott. Viszont ha valami 3rd party luzer elcsesz benne valamit, akkor ne az eredeti szerzo legyen mar a hibas.

De vegyünk egy egyszerű példát. Megkér testvéred/apósod/rokonod, hogy ugyan menj már át segíteni megszögelni a kerítést és te megígéred. Tudod, hogy baráti segítségről van szó, nem pénzért mész. De megígéred. Majd nem mész át. Dühösek lesznek rád? igen. Joggal? IGEN.

Van egy hatalmas kulonbseg a csaladom es nehany blob kozott akik meg sem kertek arra, h tegyek meg valamit, hanem en adtam nekik onzetlenul.

---
pontscho / fresh!mindworkz

"Es ha mondjuk az edesanyjat gyaszolja valaki es azert tunik el ? Nem hogy egy FLOSS projectet, de egyeb minden mast is leszarnek egy ehhez hasonlo foku problema eseten... de ennel joval kisebb eseten is. "
ezert jo, ha nem 1 ember visz egy-egy projectet, es egyetertek azzal, hogy ilyenkor a munka az utolso.

"Nem azert van a kozosseg, h ha valami tortenik a lead-del akkor at tudja venni a fejlesztest ? Mert ennek most jol ellent mondtal."
valami tortent, 2 honapig nem valaszolt a hibabejelentesre.

"A lehetoseg adott. Viszont ha valami 3rd party luzer elcsesz benne valamit, akkor ne az eredeti szerzo legyen mar a hibas."
Persze, de itt arrol volt szo, hogy debianek talaltak egy bugot, amit kidebugoltak, adtak egy patchet, hogy naluk ez javitja a problemat, elkuldtek ahova kell, csak ugye az upstream sajat hibajabol nem kapta meg idoben a patchet, es utolag nekiallt mocskolodni.
nem is hibaztatta senki a suhosint, Stefan kezdett mutogatni, pedig nagyobbreszt az O hibaja a keletkezett helyzet.

Tyrael

> Persze, de itt arrol volt szo, hogy debianek talaltak egy bugot, amit kidebugoltak, adtak egy patchet, hogy naluk ez javitja a problemat, elkuldtek ahova kell, csak ugye az upstream sajat hibajabol nem kapta meg idoben a patchet, es utolag nekiallt mocskolodni.

Helyesen:

Persze, de itt arrol volt szo, hogy debianek talaltak egy bugot, amit a szokasos inkompetens módon ki próbáltak debugolni, adtak egy patchet ami sebezhetővé teszi a kódot, hogy naluk ez javitja a problemat, elkuldtek ahova kell, csak ugye az upstream sajat hibajabol nem kapta meg idoben a patchet, es utolag nekiallt mocskolodni.

a "szokasos inkompetens" a szubjektiv, de ugy latom, hogy te valami rosszul sikerult captcha toro robot vagy, vagy ilyesmi, de hogy nem vagy touring-complete, az biztos.
reszemrol itt lezarva a szal, nem teszel hozza erteket a beszelgeteshez.

szerk:
obazzeg, ha ezt elobb latom:
Ennyi ideje regisztrált felhasználó
4 nap 6 óra

Tyrael

ROFL

Azzal, hogy valaki kiad valamit, nincs neki semmiféle kötelezettsége, ez pusztán az ő jófejsége, hogy megoszt valamit. Ugyanígy a fejlesztő az aki a feltételeket meghatározza és ezt a közösség vagy elfogadja vagy nem. Ha a közösségnek ez nem tetszik akkor forkolnak és csinálják maguknak. Ezen felül a közösség a fejlesztők irányába csakis egyvalamit tehet: Letérdelnek a fejlesztő elé, és fogazás nélkül, bő nyállal...

A rokonságot és közösséget ne vedd már egy kalap alá, mint ahogy a közösségi segítség sem azonos a rokoni segítséggel.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

marmint 2 dolgot, leterdel, vagy forkol.
altalaban az utobbi, mondj 1 olyan projectet, ahol nagykepu kocsog fejleszto van, es megis elturi a kozosseg(OpenBSD-t nem er mondani).
nem ertem miert kell ennyire elszallni a fejlesztoktol, egy csomoan csinaljak normalisan, onzetlenul, de mindig elokerul par ilyen hozzadhasonlo emberke, aki a felhasznalot egysegsugarunak hivja, es mindenki bekaphatja MERT EN VAGYOK A FEJLESZTO, NELKULEM SEMMI NEM LENNE.
elkepzelem, ahogy az osszes ilyen onkentes munkas igy adna elo magat, amikor hajlektalanoknak etelt oszt, vagy jotekonysagi gyujtest rendez.
pedig ott is ugyanugy a szabadidejet aldozzak az emberek masok megsegitesere, megsem szallnak ennyire el maguktol, mint egyesek itt a szoftveriparban.
mintha egyenesen a rakot gyogyitanak, vagy nemtom.

Tyrael

Kérlek:
ION ablakkezelő.
CDrtools
Kettőt mondtam, soroljak még?

A 90-9-1 modell mond valamit? Pont azért tűrik meg az egoista, nagyképű fejlesztőt mert a nagybetüs közösség (aka. a 90%) cseszik bármit is csinálni, max. rinyál.
A ingyenes szoftverfejlesztés nem jótékonykodás, pontosabban annyiban jótékonykodás, hogy az elkészült szoftvert megosztják azokkal retardokkal, akik képtelenek megírni ugyanezt.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

az elkészült szoftvert megosztják azokkal retardokkal, akik képtelenek megírni ugyanezt.

Latom, ezen a ponton mar tenyleg segitenek neked.... :-) Ha igaz lenne ez a hulyeseg (bocs), akkor az azt is jelenti, hogy az osszes fejleszto is retardalt. Mert ahany programot egyedul hasznalok, az embernek egyszeruen kapacitasa se lenne mindent maganak megirnia. Szoval ez most rendesen mellette volt egy arasszal. Arrol nem is beszelve, ha lenne kozod a fejlesztok eletehez, akkor tudnad, hogy ugyan valoban jotekonykodas a kod kozzetetele, de az a nagy halom teszteles, bug report, feature request, howto keszites, amit 'a retardaltak' (sic!) csinalnak, siman osszemerheto a fejlesztok munkajaval.

Amikor a levlistan kerdeztek a felhasznalok, hogy hogyan tovabb, akkor elmondtam nekik, hogy belepatkoltam egy csomo dolgot a spamszurobe, de nem vagyok olyan okos, hogy _mindent_ en talaljak ki. Ugy ertem, a kodolast en csinalom, es (egyelore) en dontom el az iranyt, de az otletek jo reszet, amire en nem is gondoltam (miert is kellene mindenre nekem egyedul rajonnom??), a felhasznalok (=community) adtak.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

A cdrkit azóta sem működik rendesen, ugyanis a fork ez esetben azt jelentette, hogy a cdrtoolsba belegányoltak és ő ezt nem volt hajlandó elfogadni, amitől a Debian maintainerek besértődtek. De ez le van írva a wikiben is:
"Jörg Schilling stated on the cdrecord website that the whole licensing issue is a "fairy tale" fabricated by people after a patch to support UTF-8 on mkisofs was rejected by Schilling (few years before) because "the code quality of this patch was lousy" (without explaining many details of the alleged act of offense), and called the fork an attack on the cdrtools project.[7]"

Tuomoról meg csak annyit, hogy pont a disztró maintainerek (találd ki vajon melyik nagy disztroról van szó) miatt követeli meg, hogy a cuccához ne nyúljanak. Emögött az áll, hogy Mr.Valkonen ne tűri el, hogy belegányoljanak a kódjába, és az elképzeléseivel nem összeegyeztető kódot implementáljanak benne. Gecinek hangzik, de az még viccesebb, amikor Tuomon kértek számon olyan dolgokat amit nem is ő írt bele. Az már csak hab a tortán, hogy a T. maintainerek nem voltak képesek követni a fejlesztés menetét és emiatt sokszor nem teljes verzió került a releasebe.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Tipikusan nem a fejlesztő a köcsög, hanem a közösség, épp ezért térdelhetnek le a fejlesztő elé, mert ha nem fizetnek és nem adják meg neki a tiszteletet, legalább így szerezzenek neki egy kis örömet.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

szerintem ez inkabb azt igazolja (marmint az, hogy nem nagyon van ilyen), hogy keves annyira jo szakember dolgozik az opensource vilagban, akinek a helyet ne tudna betolteni egy hasonlo kepessegu szakember ha az illeto valami oknal fogva abadonolna a projectet (akar ugy hogy telnylegesen otthagyja, akar ugy, hogy a kozosseg altal vallalhatatlan modon teszi a dolgat).
az meg mindig latszik, hogy jol mutat a CV-ben, hogy "En vagyok az xy elterjedt open source alkalmazas fejlesztoje" illetve szeretik az emberek, hogyha hasznaljak azt a kodot, amit irnak.
en halas vagyok minden onkentes fejlesztonek a munkajaert, de aki popsztar akar lenni sztarallurokkel, az menjen popsztarnak, es ne opensource fejlesztokent viselkedjen ugy.

Tyrael

Ha annyira sok hasonlo kepessegu szakember lenne, akkor tucatszamra lennenek hasonlo celu jol mukodo alkalmazasok. A valosag az, hogy sok szemet van es keves hasznalhato.

"az meg mindig latszik, hogy jol mutat a CV-ben, hogy "En vagyok az xy elterjedt open source alkalmazas fejlesztoje" illetve szeretik az emberek, hogyha hasznaljak azt a kodot, amit irnak."
Kulonosen a Microsofthoz beadott CV-ben. ;)

Pedig a fejlesztők az open-source rocksztárjai.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

amig a feladatat ellatja, az adott potencialis-fejleszto igenyeit kiszolgalja, addig nem fog nekiallni valaki lefejleszteni megegyszer ugyanazt.
tehat lehet hogy tudnek jobb bugtracking rendszert irni, mint ami most a piacon levok kozul legjobban lefedi az igenyeimet, de nincs se kedvem, se idom, ha valami nagyon kell, akkor feature request, vagy megcsinalom es bekuldom a peccset.
de ha nem lenne ilyen, vagy abadonolnanak egy nekem must-have software-t, aminek a tovabbvitelehez meglenne a tudasom, akkor elgondolkoznek rajta.

Tyrael

Már bocs, de honnan veszed, hogy tisztán karitatív alapon kódol bárki is opensource? Teljesen biztos vagyok benne, hogy azért kódol a fejlesztők 99%-a, akár hobbiból is, mert az, amit ír, az neki valamiért fontos, Egy sor opensource kódot nem írtam volna, ha nincs rá okom, ha nem valami olyan funkciót valósítok meg, ami nekem hasznos lesz, vagy csak simán jól esik megírni.

Szerinted van olyan ember, aki azt mondja: Na most karitatívan fogok kódolni, itt van 300 open source project bugzilla 300000 buggal, random választok tizet és megoldom őket. Vicces lenne :)

nade akárhogy is számoljuk még mindig több köcsög közösségi tag van - akár ebben az egyetlen topikban :P - mint amennyi köcsög fejlesztő van...

nekem egyébként az véleményem - nem mintha lenne értéke :) - hogy a legtöbb probléma és flame forrása az ehhez hasonló szájtépéseknél az az hogy a különböző adminok/maintainerek/ hajlamosak fejlesztőnek képzelni magukat és bugreport helyett nekiállnak lelkesen kódolni...

No rainbow, no sugar

az open source felhasználókon se lehet soha semmit számon kérni mert akkor a fejlesztő egy köcsög...

melyik projekt is volt az ammi felháborító módon megkérdezte a kedves felhasználóit hogy milyen jó lenne ha támogatnák x év után a vatikáni valutát leszámítva végre egy kis kenyérre valóval?

No rainbow, no sugar

Hadd tegyek hozza egy masik nezopontot is a dologhoz. En is fejlesztek egy kozelebbrol meg nem nevezett projektet. Open source a cucc, es a fejleszto (=ez en volnek) es a felhasznalok (=akik letoltik) kozotti szerzodest a licence tartalmazza, ami nalam zlib/png. Ez egyebkent kb. annyit tesz, hogy csinalj vele amit akarsz, de no warranty.

Az elso fele egyszeru, a masodik egy kisse tricky. A no warranty azt jelenti, hogy az eg vilagon semmire se vagyok koteles, es semmivel sem tartozom [a projekt kapcsan]. Kicsit kifejtve: ne nezz csunyan, ha nem keszitek sec./bug fixeket, akkor se, ha abbahagyom a fejlesztest, es nem adom at a projekt jogait egy 3. felnek, hogy tovabbvigye, stb.

Noha igy is viselkedhetnek, de nem ez az erdekem, hanem az, hogy a felhasznalok elegedettek legyenek, es hasznaljak a spamszurot. Fix-eket ezert teszek bele, uj feature-oket meg azert, hogy minel jobb es hasznalhatobb legyen a cucc.

Ha azonban valaki support/whatever szerzodest kot velem (=ad egy kisebb zsak penzt) [mert az open source modell ezt nem tiltja], hogy 1 evig biztosits nekem sec. fixeket, vagy ha valami nem mukodik, akkor csinald meg x idon belul, whatever. Na az egybol mas.

A keriteses peldad azert santit itt, mert ld. egy tanulmanyt, a sourceforge/freshmeat projektet 99%-a abandonware. En is irtam egy toolt, amit aztan letettem. Majd 3-4 ev mulva jott egy nemet fazon, es kerdezett, hogy akkor ezt most hogy... Ehhh, azert adtam neki 1-2 tippet....

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

ugye tudod, hogy a debian staff is ingyen csinalja amit csinal, afaik.
szoval nem ertem, hogy miert kell pont neki(aki szinten peccseli az upstreamet), pont ebben az esetben(volt ertesites az upstream fele) ilyen hangon beszolni a debian-nak, es 3 napig dolgozni a javitason meg a blogbejegyzesen, hogy megfeleloen foldbedongolos legyen...

Tyrael

ez ilyen altalanos kijelentes?
tudsz mondani fejbol meg mondjuk 3 olyan esetet az elmult 8 evbol, amikor a debian sebezhetobbe tette a php-t?
vagy csak ervek/tudas nelkul trollkodsz?

amugy neha a developer teszi sebezhetove:
http://twitter.com/i0n1c/status/9988110645
http://twitter.com/i0n1c/status/9988144253

amugy en is mindenhol a dotdeb-es php-t hasznalom debian-on, nem az oveket, de ugy latom, hogy sok ember, koztuk te is, zsigerbol szidja a debian-t, pedig most ok voltak a kissebb hunyok a dologban, Stefan belerakott egy tervezesi hibat(az o megoldasaval nem lehetett platformfuggetlenul megvalositani amit akart, ezert crashelgetett a php bizonyos architekturakon), amit a php-sek kijavitottak, egy teljesen jo patchel, csak igy az eredeti koncepcio(read-only suhosin-config a memoriaban) sebezhetove valt, de utana Stefen sem tudott a pointer-nel jobb megoldast (csak ezt a verziot obfuszkalta), es meg ezt is sikerult ugy elbassznia, hogy nala TELJESEN irhatova valt a fent nevezett valtozo a memoriaban.

es o kezdett flamelni ugy, hogy a debian mar 2 honapja elkuldte neki a hibajelzest 1 mellekelt patchel, a suhosin weblapjan megadott email cimre, amit Stefan sajat bevallasa szerint nem surun olvas, mert keves level jon ra.
ez olyan, mintha en nem olvasnam az abuse@ vagy postmaster@ cimeimet, vagy ha a mentoszolgalat nem 7/24-be mukodne, mert ritkan(de akkor kurvara) van rajuk szukseg.

Tyrael

amit a php-sek kijavitottak, egy teljesen jo patchel

azt írni rá, hogy teljesen jó patch azért elég nagy túlzás... ugyanúgy hibás megvalósítás volt, mint az openssl entrópia forrás kikommentelése, hogy eltűnjön a lint warning és sesser ezt jogosan vetette a szemükre, hisz az ember azt gondolná, hogy a debianosok egy openssl fiaskó után már kicsit óvatosabban patchelgetik a security megoldásokat és nem pedig "nem crashel, jó lesz így" módon.

bugreportnak teljesen jo patch.
tehat ha nekem mint fejleszto kuldtek volna egy patchet, hogy az eredeti crashel, ha ezt atirom akkor nem, akkor mar latom, hogy mi a hiba, es termeszetesen nem ezt a patchet olvasztom be, hiszem upstream leven tudom, hogy az elbaszna valamit.
de ettol meg bugreportnak tok jo volt, gyakorlatilag kidebugoltak az upstream helyett hibat.

szoval amikor azt irtam, hogy teljesen jo patchel, akkor igy ertettem.
nemtudom, hogy tudod-e, de a kodhoz 0 doksi van, es ha jol lattam, akkor commentelve sem volt az a kodreszlet, es azert igy third party-kent belenezni nem olyan, mintha te lennel a fejleszto.

btw: az openssl-les dologrol is megvan a sajat velemenyem, parametert hol inputnak, hol outputnak hasznalni nem egeszseges comment nelkul, ugyancsak nem egeszseges comment nelkul allokalatlan memoriacimrol olvasni, valamint az sem segit, ha arra a kerdesre, hogy kikommentezhetem-e a masik helyen is ezt a fuggvenyhivast egy xyz@openssl.org os emailcimmel rendelkezo ember a hivatalos levlistan azt irja, hogy igen.
ott sem tortenhetett volna meg az a fiasko a megfelelo korulmenyek egyuttallasa nelkul.

Tyrael

Engem nem érdekel, hogy ki, mikor regisztrált ide, én régen, más még régebben, megint mások meg pár napja. Az adott nick mögött lévő ember szakmai szintjéről ez nem mond szinte semmit, max. azt, hogy legalább x ideje érdeklődik a hup-on előforduló témák iránt. Szerintem legalábbis...

egyetertenek, ha nem rolad lenne szo.
vegignezve a hozzaszolasaidat semmi mast nem csinalsz, csak trollkodsz, es nem is tul valtozatos modon.
Az osszes hozzaszolasod szavainak felet kb. a Milton debian es az openssl szavak teszik ki.
Vagy csak a mocskolodasert regeltel, vagy valakinek a masodik(sokadik) kamu regje vagy, mert mar mindenki raragasztotta az Asshat jelzot, es nem allnak le veled vitazni.

Tyrael

de ettol meg bugreportnak tok jo volt, gyakorlatilag kidebugoltak az upstream helyett hibat

nem volt jó a bugreport sem, ugyanis annyiból továbbra se tudta sesser, hogy mi volt a hiba, miért crashelt...

de nem is azzal volt a baj, hogy nem jól bugreportoltak, hanem azzal, hogy utána fogták és be is olvasztották a forrásfájukba.

nem egeszseges comment nelkul allokalatlan memoriacimrol olvasni

nem egészséges egy security megoldásnál agyilag zokninak hinni a fejlesztőket kapásból és okosabbnak lenni (maintanerként), hogy nem kell az az entrópiaforrás oda...

os emailcimmel rendelkezo ember a hivatalos levlistan azt irja, hogy igen

debug erejéig igen, azt irta

"nem volt jó a bugreport sem, ugyanis annyiból továbbra se tudta sesser, hogy mi volt a hiba, miért crashelt..."
marpedig leirta a blogjaban, hogy mit akart az eredeti patch, mi volt a sajatjaban a hiba, es hol jelentkezhetett.
ebbol nekem az jott le, hogy a patchbol o mar tudta, hogy mi volt a gond.
"de nem is azzal volt a baj, hogy nem jól bugreportoltak, hanem azzal, hogy utána fogták és be is olvasztották a forrásfájukba."
meddig kellett volna varniuk?
a jelen allas szerint 2 honapig.

"nem egészséges egy security megoldásnál agyilag zokninak hinni a fejlesztőket kapásból és okosabbnak lenni (maintanerként), hogy nem kell az az entrópiaforrás oda..."
tudod, hogy ez sem egeszen igy tortent.
felment ott is levlistara, rakerdezett, es valaki beirta hogy kommentezd ki, aki irta ugy ertette, hogy amig debugolsz, a srac meg ugy, hogy vegleg.
de ez mar FUD, ugy gondoltam hogy te utanaolvastal anno, es nem ferditesz szandekosan.

Tyrael

ebbol nekem az jott le, hogy a patchbol o mar tudta, hogy mi volt a gond

később derítette ki, nem a bugreportból tudta meg

meddig kellett volna varniuk? a jelen allas szerint 2 honapig.

őszintén? szerintem nem lett volna nehéz más elérhetőségen is próbálkozni... beírod sesser nevét a keresőbe és kiad egy rakás email címet, még a twitter usere is ott van az első találatok között. egyszerűen a debianos gyerek szart bele igazából.

de ez mar FUD, ugy gondoltam hogy te utanaolvastal anno, es nem ferditesz szandekosan

ne haragudj, de pontosan azt írtam ami történt... ezt a választ kapta, kikerestem neked:

"Not much. If it helps with debugging, I'm in favor of removing them."

úgyhogy nem én ferdítek szándékosan, hanem te.

kozben en is megtalaltam, szar hogy nem lehet threadet listazni. :/
csak hogy itt legyen a teljes idezet:

> What I currently see as best option is to actually comment out
> those 2 lines of code. But I have no idea what effect this
> really has on the RNG. [/b]The only effect I see is that the pool[/b]
> might receive less entropy. But on the other hand, I'm not even
> sure how much entropy some unitialised data has.
>
Not much. If it helps with debugging, I'm in favor of removing them.
(However the last time I checked, valgrind reported thousands of bogus
error messages. Has that situation gotten better?)

Szoval igazad van, tenyleg szerepelt a mundatban a debugolasra valo utalas _O_, viszont a debianos arc a valaszbol azt is leszurte(hibasan), hogy nem jelentos merteku az az entropia, amit az a 2 sor(igazabol csak az egyik) tesz bele a pool-ba.

a tortenethez hozzatartozik(ezt is ismered biztos), hogy az openssl-dev, az nem az openssl fejlesztoi lista, hanem az openssl-re alkalmazastfejlesztok listaja, es az openssl-es email cimes csoka sem volt a helyzet magaslatan.
nem teged akartalak szemelyesen baszogatni, csak utalom, hogy par ember ugy probalja azt az esetet(is) beallitani, mintha a debian-os arcok nekialltak volna szandekosan kivagni maguk alatt a fat.
az atlaguser meg nem ert semmit az egeszbol, csak szajkozza, hogy debian openssl, debian openssl.
sok mindent bizonyit ez az eset, tobbek kozott azt is, hogy hiaba a nyilt kod, meg a sok felhasznalo, nagyon kevesen neznek bele, hianyzik a profi QA, es normalis komment nelkul aki belenez, sem veszi eszre a kodban a hibat.

Tyrael

Ezt nem tudom minek hoztad fel, ez egy "egy ezer eves leragot csont", viszont az szomorú hogy még mindig fogalmad sincs miről beszélsz, tudniillik nem csak azt az entrópiaforrást kommentelte ki az inkompetens debian maintainer, hanem az egész entrópia _frissítést_. Gondolom egyfajta memóriajáték keretében az összes hasonlító utasítás elé odavágott két perjelet, és akkor megvolt az aznapra rendelt developz.

"Gondolom egyfajta memóriajáték keretében az összes hasonlító utasítás elé odavágott két perjelet, és akkor megvolt az aznapra rendelt developz."
osszesen 2 sort kommentezett ki, az egyikkel nem is lett volna para, de a masik toltotte fel entropiaval a poolt, igy ez lett az egyetlen forras ami az entropia poolt feltoltotte.
de ez mind le van irva a http://wiki.debian.org/SSLkeys cimen, olvasd el nyugodtan.
be van linkelve a patch, a levlistas beszelgetes, a hiba leirasa, etc.

Tyrael

2 honapja nem kapcsolta be azt a gepet, amin a hardened-php leveleket olvasta, a bugot/patchet 3 hete kuldtek csak. aztan meg mi akadalyozta meg a debiant, hogy mas modon utolerjek? rohadt nehez feladat lehetett nekik, mert szemmel lathatoan nem sikerult (elarulom, hogy en honnan talaltam ki a cimet, tessek rohadtul figyelni, mert nagy titokrol lebben fel a fatyol: benne van a suhosin patch-ben! nem is 1, hanem mindjart 2 cim is...). aztan lorian pontosan tudta, mi a gond a koddal (ami mellesleg nem tervezesi hiba, mert az o modszerevel is meg lehetett volna oldani, hogy menjen 64k-s lapmerettel is), szepen szerepel is az adott helyen (elolvastad egyaltalan???), hogy /* hack that needs to be fixed */. a debianosok nem csinaltak mast, mint kiszedtek a hack-et. vagyis csak probaltak, mert ugye nem jott ossze anelkul, hogy elbasztak volna az egesz dolog ertelmet (ismeros momentum, gondolom nem kell nekem is leirni ;). az mas kerdes, hogy lorian a sok eves php-s security kuzdelme utan kisse idegesen kezelte a helyzetet, na de ahogy a mondas tartja, nehogy mar a farok csovalja a kutyat (ez szol a bambino fele hozzaszoloknak is).

az itteni par hozzaszolasod eleg egyertelmuen megvalaszolja a kerdesed. mellesleg nem velemenyt irtam, hanem tenyeket, de ahogy elnezem, a szovegertes eddig sem volt erosseged, bar *velemenyed* azert mindenrol van (most biztos megint szemelyeskedtem, mi? ;). ha esetleg van a *temahoz* valami mondanivalod, akkor hajra, ne tartsd vissza, meg van popcorn.

> maradjunk annyiban, hogy semmi nem indokolja a személyeskedést.

maradjunk annyiban, hogy legkozelebb kovesd a sajat tanacsod, ha mar ugy szereted osztogatni.

> szerintem a velem való személyeskedés nem tartozik ehhez a témához

szerintem a barkivel valo szemelyeskdes sem tartozik a temahoz, de latom nem szereted, amikor a fagyi visszanyal. akkor most olvasd szepen ujra, amiket ebbe a szalba irtal.

> úgyhogy kezdd azzal, hogy leszoksz róla.

latom nagyon szeretnel te engem utasitgatni. szerinted mennyire erdekel? majd ha megtanulsz normalisan kommunikalni, akkor en is aszerint foglak kezelni. kerdes persze, hogy ket off-topic 'hozzaszolasod' utan mirol fog szolni a kovetkezo, bar nincsenek nagy remenyeim ;).

en ugy latom, hogy a debian-osoknak be kellett vezetniuk egy pointert, aminek a bevezeteset Stefan szetfikazta, majd megis ezt a megoldast(pointer) valasztotta a vegleges patches o is.
ha olvastad a blogban a hozzaszolasokat, akkor tudod, hogy ott tobb javaslat is elhangzott, de a vegen Stefan elismerte, hogy sajna nem tudja/akarja/lehet megcsinalni enelkul platform fuggetlenre a megoldast, es inkabb magat a pointert fogja vedeni mas modon (obfuscation).
egyertelmu, hogy a temaban nagyobb szakertelemmel rendelkezel, ezert ha hulyeseget irok, nyugodtan javits ki, de attol nem fogom belatni, hogy neked van igazad, hogy leirod, hogy hulye vagyok.

Tyrael

nem irtam senkirol, hogy hulye, csak a tenyeket, hogy mi es miert volt. mellesleg lorian ugyanugy tevedett (mindjart leirom akkor reszletesebben), mint ahogy a tobbiek is, akkor most ezert o is hulye lenne? szerintem egy szoval nem allitottam ilyet.

na de a lenyeg. minden procinak mas es mas lehetosegei vannak a virtualis->fizikai memoria lekepezes megvalositasara. az ezt a lekepezest kihasznalni akaro kodot eleve nem lehet architektura fuggetlenre megirni (tessek megnezni, hogy mi tortenik RISC prociknal a futasidoben generalt PLT stub-ok irasakor: cache flush, ami asm kodot igenyel, az az eletben nem lesz architektura fuggetlen, megis az ELF alapu userland-ek eleg sok procin elfutkaroznak). amit lorian szeretett volna az egy futasideju alacsony szintu vedelem a suhosin konfiguraciojara (marmint arra, amit abbol a memoriaban tarol). hogy ez az egesz egy ertelmes cel-e vagy sem, most lenyegtelen (szerintem amugy nem, mert van kismillio mas dolog, amit egy memoriat irni kepes hiban keresztul ki lehet hasznalni, sot akar az egesz mprotect alapu vedelem visszacsinalhato), az izgalmasabb kerdes, hogy mi modon lehet ezt elerni.

a megoldas erre a fent emlitett lekepezes kihasznalasa ugy, hogy a kerdeses memoriateruletet csak olvashatova tesszuk (az, hogy ezt egyaltalan meg lehet tenni, mar eleve feltetelez bizonyos processzor meg kernel kepessegeket, nem veletlen, hogy a POSIX-ban is opcionalis a mmap es tarsai tamogatasa). a kovetkezo kerdes az, hogyan lehet ezt megtenni. erre alapvetoen a kernel belso mmap/mprotect interface-e valo, de oda tobb ut is vezet.

az egyik, amit lorian eredeti megoldasa hasznalt, az ELF loaderen keresztul volt: minden ELF file-ban a PT_LOAD szegmensekhez tartozik tobbek kozott egy hozzaferesi jog (rwx valamilyen kombinacioja) ill. egy alignment mezo. minden ilyen PT_LOAD szegmenst a kernel (a fo exe meg ld.so eseten) vagy az ld.so (konyvtarak eseten) tolt be memoriaba a mmap() segitsegevel, ahol a parameterek osszeallitasakor figyelembe veszi a PT_LOAD mezoket (tehat pl. a vegrehajthato kodot tartalmazo PT_LOAD-ot azert mmap-eli PROT_EXEC jogot (is) kerve, mert ennek a PT_LOAD szegmensnek r-x a hozzaferesi jogokat tartalmazo mezoje, readelf -l szepen megmutatja, akit erdekel). az alignment mezo arra jo, hogy biztositsa, hogy az ilyet igenylo adatstrukturak valamilyen 2 hatvany tobbszorosenek megfelelo cimre keruljenek a virtualis memoriaban (pl. lebegopontos szamok szeretnek 8/16 byte-os hatarra esni). a suhosin konfiguracio eseteben azt csinalta lorian, hogy a konfiguraciot tartalmazo (es lap meretu) valtozot explicite laphatarra kerte igazitani a toolchain-tol (gcc/linker/kernel/ld.so egyuttmukodese mind szukseges ehhez). ezek utan egy egyszeru mprotect (ami laphatarra igazitott cimet var el) az adott valtozora szepen csak olvashatova tette az egeszet, mission accomplished. vagy legalabbis ez volt az elkepzeles, ami x86-on (meg ugy altalaban 4k-s lapokat hasznalo architekturakon) szepen mukodott, nagyobb lapmeretek eseten meg tulbuzgo modon mas, irhatonak szant valtozokat is csak olvashatova tett (amik pechjukre epp a suhosin konfiguracioja utan voltak a memoriaban), amit a kernel sigsegv-vel honoralt az elso irasi kiserletnel (ez lett volna a debian bugreport lenyege). meg egy aprosag ehhez a megoldashoz: a konfiguraciot tartalmazo valtozo globalis valtozo, ezert minden eleres hozza egy pointeren keresztul tortenik, amit a GOT tarol. ezt a pointert nem a C szintu kod hozza letre, hanem a fordito/linker maga (PIC-hez szukseges), de alapvetoen ugyanazt a szerepet tolti be, mint a mindjart leirt masik megoldasban az explicit pointer. es persze ugyanugy tamadhato lenne, ha nem letezne a RELRO vedelem.

a masik megoldas hasonlo az elozohoz, annyi elteressel, hogy a konfiguraciot tarolo memoriat nem implicite a toolchain allokalja, hanem C szintu kod direkt mmap hivassal, aminek megvan az az elonye, hogy pontos lapmerettel lehet kerni, igy elkerulheto a nem kivant atlapolodas mas valtozokkal. cserebe viszont a valtozo eleresehez direkt pointer valtozo kell, amit viszont nem lehet a (RELRO eseten irasvedett) GOT-ba tuszkolni (az a toolchain belugye), igy mas vedelem kell, erre talaltak ki a XOR-olast (ezt is lehetett volna maskepp csinalni, de most mindegy).

na akkor most a kritika az egeszrol: az elso modszer megcsinalhato tetszoleges lapmerettel, es mivel a php/suhosin veges sok architekturan fut, nem (lett volna) nagy kunszt megtalalni a legnagyobb tamogatando lapmeretet, ranezesre 64k ment volna mindenhol (vagy be lehetett volna tenni par ifdef-et, a lenyegen nem valtoztat). a pointer titkositas meg nem security, hanem obscurity (mint az ASLR), annal sokkal jobb lett volna, ha a GOT/RELRO modszernel marad, vagy legalabb leellenorzi, hogy a celmemoria tenyleg read-only-e es a konfigot tartalmazza.

Köszönjük szépen.
Most nem azt írja egyébként, hogy fordítás időben fog eldőlni a lapméretnek megfelelően a pointer? Ez számomra az első verzióra utal.

Szerintem neked kéne csinálni egy Akadémiát fejlesztők számára. Kötelezővé tenném.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

a legujabb patchbol (amire te is ranezhettel volna ;P):

suhosin_config = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);

eleg egyertelmu szerintem ;).

a direkt oktatasrol meg az a velemenyem, hogy az emberek elenyeszo kisebbsege kepes ertekelni, a tobbseg azt jegyzi meg, amit magatol tanul meg, gyakran a sajat karan. vagyis a motivacio nelkuli ember oktatasa falrahanyt borso, a motivalt embert meg nem oktatni kell(ene), hanem iranyitani a felfedezo utjan (en se veletlenul szortam tele a fenti postom mindenfele varazsszoval, a motivalt olvasoknak kapaszkodot adnak, ha tovabb is akarnak olvasni ezekrol a dolgokrol). szoval eloszor ezen kene valtoztatni, ha egyaltalan lehetseges/erdemes. na de ez egy evezredes problema es erosen offtopic ;).

2 honapja nem kapcsolta be azt a gepet, amin a hardened-php leveleket olvasta

Nem akarok offolni, de az is érdekes, ha valakinek a mai "cloud" meg "minden a netre megy" világban külön gépet kell bekapcsolni azért, hogy egy adott címre beérkező leveleket (vagy levelezőlistát) elolvasson. Különösen, ha ő egy nagynevű, köztiszteletben álló elismert biztonsági szakember.

De ezt csak úgy megjegyeztem, magamban. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

nem akarmilyen geprol van szo, hanem a sajat desktopjarol, amit 2 honap nemhasznalat utan ujratelepitett, es akkor nezett ra a hardened-php mailboxra (amire amugy is ritkan jon level), akkor latta meg az akkor kb. 2 hetes debian levelet. mindekozben aktiv ill. elerheto volt millio mas helyen (blog, dailydave, twitter, stb), ugy is mint "nagynevű, köztiszteletben álló elismert biztonsági szakember", csak persze ehhez valakinek egy kis faradtsagot kellett volna vennie. csak ugy megjegyzem, ha te vagy a debian packager, ket het hallgatas utan nem probalkoztal volna ujra/maskepp?

A nem olyan tul regi (1-2 evvel korabbi) ITBN-en hallottam, egy HP-s(?) sec. fazon coming out-jaban, hogy 'amikor az outlook / (v.) IE-ben csinaltam valamit, es jol megfertoztek a gepemet'. Elso kerdesem: 'Ke?' Security whatever + IE/O(e) ugyanabban a mondatban, ehhh....

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Stallman univerzumból.

Stallman univerzum a Microsoft badszectorral határos, gandzsa ködfelhőben rejtőző, önmagába nyúló spirálgalaxis.
Eredetileg, a Gonosz Birodalomból menekülő lázadó kóderek népesítették be, akik a Stallmani eszméket követve ingyen szoftverről és szexről álmodoztak. A szex elmaradt, mert a menekültek közt sok volt a pingvin és kevés a nő, ezért a lázadók egy idő után mindent magukévá tettek, és ekkor kezdett a spirálgalaxis magához nyúlni. Az első és másodgenerációs telepeseket még igazi tökös kóderek voltak, kik kólán és chipsen élve, vagy akár puszta nyers tészta rágcsálással is képesek voltak kernelt írni, és virágzóvá tenni a kietlen merevlemez szektorokat. Sorba szökkentek szárba a különféle disztribúciós kolóniák, mely ugyan azonos terraformáló magból szökkentek szárba, más és más kultúrát hordoznak.
Ezen felvirágzás árnyakat is hozott. Tömegesen áramlottak a fiatal köztársaságba objektum orientált és script nyelveken, windows GUIn nevelkedett kóderek, kik nem értették mily keserves munkával lettek eme oázisok bitjei létrehozva.
Közben újabb csapás érte a telepeseket. Vezetőjük, az isteni RMS elméjét az univerzumot körülölelő gandzsafüst megbontotta, és billentyűzetét eldobva, a kódolástól elfordulva, az ismert IT szektor felszabadítását tűzte ki céljául. A Gonosz birodalmának legyőzéséhez annak tükörképét próbálta megalkotni, melyhez felhasználta a legsötétebb politikai és ideológiai eszmerendszerek praktikáit, és elvakult fanatikusokat gyűjtött zászlaja alá.
A háborúra való készülődés szele megérintette a Gonosz birodalmának lázadni kívánó, tudatlan ifjait, kik Shuttleworth kalózkapitány Ubuntu hajóján léptek be a Stallmani univerzumba. Ezen ifjak mit sem tudva a világról alkották a FOSS hadsereg ágyútöltelék hadtesteit, míg az igazán fanatikusaik misszionáriusként liveCDkkel térítettek a határvidékeken.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

nem kene annyit gombazni...

--------------------------
The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do.

"Understanding the Linux Kernel" on page frame reclaiming

"objektum orientált és script nyelveken, windows GUIn nevelkedett kóderek" +1
- kötelezővé tenném az asm és ANSI C oktatást mielőtt bárki OOP-s, vagy interpreter nyelvhez nyúlna.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Igen, csak a nyiltforras nem arrol szol hogy csinalok egy felkesz szart es utana aki nem fizet az rohadjon meg. Kicsit mas a szellemisege, de latom ez a TE ertelmi szintednek magas.

--------------------------
The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do.

"Understanding the Linux Kernel" on page frame reclaiming

+1

A nyílt forrás szellemisége ott ér véget, hogy publikusan hozzáférhetővé és valamilyen szinten felhasználhatóvá teszed a forrást. Pont, vége, finitó.
Minden egyéb csak rárakódott/rákényszerített ideológiai maszturbáció. Kb. mint ahogy a marxi eszmék viszonyulnak a megvalósított kommunizmushoz.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ebben igazad van. Viszont ilyenkor _illene_ atadni a stafetat annak aki tud es akar vele foglalkozni. Mert azt ugy illik. Tudom, odivatu vagyok.

synapse

--------------------------
The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do.

"Understanding the Linux Kernel" on page frame reclaiming

( nevergone v | 2010. 03. 04., cs – 11:10 )

omg

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( noveria | 2010. 03. 04., cs – 11:25 )

Már megint a felszínre bukkant a Debian GNU/Linux-ban terjengő inkompetencia.

( uid_228 | 2010. 03. 04., cs – 11:28 )

A napokban vita kerekedett arról, hogy ki, mit és hol kuszált össze.

A PHP megalkotói kezdték. :))

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

( Dwokfur v | 2010. 03. 04., cs – 12:17 )

Azért a blog bejegyzés végén úgy tűnik, hogy lesz megoldása a porblémának. Fordítási időben fog eldőlni, hogy mi a megfelelő PAGE_SIZE az adott arhitektúrán. És az inkriminált pointert védelmét erősíteni próbálják.

Remélem lecsillapodnak a kedélyek.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( mchalls | 2010. 03. 04., cs – 12:22 )

Ez a vege ha a userek a tesztelok egyben es a supported platform lista csupan a vagyalombol szuletik. Tanulsag: minden patchnel megvarni mit okoz, majd par honap utan alkalmazni. Oh wait, de akkor lassabban javul, mint a zart forras es nem lehet trollkodni. :-)

[Szerk:] ha belegondolok ezek utan ertheto hogy miert ott eletkepes csak a dolog, ahol masolnak valamit es nem kritikus az hogy mukodik vagy sem... :-)

Azért a sztori ott kezdődött, hogy a Suhosin patch fejlesztője csinált egy ordenáré hack-et, aminek a tesztelése jól elmaradt és crash volt a jutalma egyes architektúrákon. Ami crash-nek a biztonsági vonzatát is érdemes lenne esetleg górcső alá venni, hátha ott is lenne mit tenni még.

Esetleg még annyit érdemes lenne megjegyzeni, hogy ez az egész a Debian _unstable_/_testing_ ágában történt a blogbejegyzés szerint, tehát ezt pontosan a tesztelés szakaszban érték tetten.

--
trey @ gépház

bug? inkább használom kisebb sekuricsivel mind egyáltalán nem. Ez nem úgy működik a világban, mint az otthonról hostolt blogoddal, hogy akkor most 300 napig nincs blog, a nemlétező olvasóid nem fogják máshova vinni a pénzüket.

Az meg, hogy valójában mekkora a gond, csak az egyik érintett féltől tudjuk, aki, mint vitás fél, szereti eltúlozni a másik szemében levő gerendát.

De látom, te is ilyen komplexusos bsd júzer vagy.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

> inkább használom kisebb sekuricsivel mind egyáltalán nem

Úgy lenne a fair, ha közölnéd hogy hol nyújtod ezt a szolgáltatásod. Már csak hogy tudjuk hova nem szabad fordulni.

Mivel fogalmad sincs, elmesélem: a világban úgy működik, hogy ha a tesztrendszeren sig11 van, akkor az élesen nem upgradelek. Hű!

> Az meg, hogy valójában mekkora a gond, csak az egyik érintett féltől tudjuk

Remélem ezzel nem azt akarod mondani, hogy a hup részrehajló? ("feltételezésekkel és sértett hiúsággal fűszerezett, túlfűtött vita")

a világban úgy működik, hogy a testing ágból nem teszek fel soha semmit sem éles rendszerre, sem éles rendszer előszobájába. benne van a nevében, hogy testing. meg a világ úgy működik, hogy nem alkalmazok diszlexiás rendszergazdát.

úgy látom, mindig azoknak van baja a debiannal, akik nem úgy akarják használni, amire tervezve lett.

Nyugi, azt a szolgaltatast te nem tudod megfizetni, de ott php sincs.

Hú, ismered a tesztrendszer szót?!

A reszrehajlasrol, amit sugalmazol:
Mivel a cikkben vegig a 2-honapig-nem-olvasok-levelet-utana-csak-rinyalok Esser szovegelese volt, felteszem a Debian team reakcioi senkit sem erdekeltek, ha a cikkiro sem volt kepes megkerdezni oket.

So far, so 'shit happens', but instead of ensuring that the dodgy patch was replaced with something better as quickly as possible, Esser started out by posting a blog entry stating his personal view of the matter.

Ilyen hozzaallassal akar Esser is csinalhatta volna ezt a patch-et. Valszeg megsem olyan nagy a gaz, ha a forinyalo javitas helyett raert blogolni... ironikus nemde?

Ettol fuggetlenul, debian maintainerek ne kodoljanak, egyetertek, de ha a programozo fosik a programjara, ne sirjon, inkabb oruljon, hogy valakit meg erdekel. OpenSSL fiasko meg: FAIL. Tedd be a signature-odbe.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

azt vagod, hogy nem lett sebezhetobb a php attol amit csinaltak, csak a suhosin egyik biztonsagi feature-jet csaptak agyon.
tehat nem exploitalhato vulnerability-t csinaltak, csak erre lehetoseget, mert jelenleg nincs kozkezen olyan exploit a stabil php-ban, ami ellen csak a suhosin memory manager canary protection featurje jelenti az egyetlen vedelmet.

Tyrael

A folyamat:

1. az opensource fejlesztő bugot commitel
2. a debian a bug-ból szokás szerint egy hatalmas vulnerability-t csinál
3. az opensource fejlesztő ideges amiatt, hogy inkompetens emberek patchelik tönkre a kódját
4. a hup-on az opensource fejlesztő egy szemét hisztis, aki előadja a hattyú halálát (ahelyett hogy...?)

Én ezt látom.

Ideges, mert tönkre patchelik _a kódját_?

Akkor nem csak hisztérika, hanem ostoba is, hiszen ő adta ki olyan licenc alatt a kódot, ami lehetővé teszi, hogy úgy patcheljék tönkre, ahogy jól esik.

"Redistribution and use in source and binary forms, with or without
modification, is permitted provided that the following conditions
are met:"

--
trey @ gépház

Te itt valami tévedésben vagy.

A PHP fejlesztői kényszerítették, hogy Stefan Esser készítsen patchet a PHP projekthez, akit ennélfogva belekényszerítettek, hogy használja a PHP licencet. Ez nem Stefan Esser választása volt. Stefan Esser áldozat, aki most szembesült azzal, hogy a kódja olyan licenc alá került, amit bárki módosíthat a saját szájíze szerint és most, hogy valaki megtette, ideges. Ezt szeretnéd mondani?

--
trey @ gépház

Annyit mondtam, hogy az általad idecitált licensz nem veszi el tőle se a méltatlankodás, sem pedig úgy általában a véleményalkotás jogát. Bármennyire is belefeszülsz hogy efölött érzett megrökönyödésedben a portálodon "hisztisnek" és különféle szárnyas madaraknak írd le.

A folyamat:

1. Rühellem a Debiant
2. Debiannal kapcsolatos hírekre rácsapok, mint tyúk a takonyra
3. A hír bizonyos elemeit felnagyítva (vulnerability) másokat szőnyeg alá söpörve (testing/unstable) flame-elek
4. A reflexből felháborodó fórumozókat nagy arccal, rutinból hárítom.

Én ezt látom :)

topikon belul masodszor reflektalok egy hozzaszolasodra, de nem kotekedni szeretnek hidd el:
> a debian a bug-ból szokás szerint egy hatalmas vulnerability-t csinál

ezt hogy tetszik erteni? ideznek a fent emlitett blog bejegyzesbol:

The patch ensures that the suhosin configuration is set to read only, but now a memory corruption exploit can just overwrite the suhosin_config pointer and let it point to a memory area that contains a new configuration.

szo sincs rola, hogy a debianos arcok sebezhetoseget gyartottak volna. pointert hasznalnak az eredetileg fix hosszu karakterlanc helyett. a pointer meg arrol kapta a nevet, hogy memoria cimre mutat - barmi is legyen ott. a sebezhetoseg ugy valik valossa, hogy mashol - nem feltetlenul itt ebben a patchben - esetlegesen elkovetett hiba miatt (pl buffer overflow) az a memoriaterulet ahova a pointer mutat megvaltozhat, azaz rossz indulatu kod - jelen esetben suhosin konfig - kerulhet oda. tehat ez onmagaban meg nem sebezheto.

off: egyebkent meg a debianos arcok neveben kikernem magamnak a 'szokas szerint' es 'hatalmas' jelzoket.

udv, sbalazs.

a blogban kozzetett kodreszekbol es a patchbol az derult ki, hogy ott nem volt ilyen 'sebezhetoseg'. egyebirant nem allitottam, hogy feature volna. egyszeruen tulzasnak erzem azokat a reakciokat amiket - nem csak te - a debian ellenzek produkal az esettel kapcsolatban. ne feledjuk azt sem, hogy a patch a debian unstable es testing repokba kerult be.

udv, sbalazs.

"The Debian maintainers tried to fix the problem by replacing the aligned suhosin_config variable with a pointer. They then allocate a single memory mapped page and set it to read only. While this fixes the possible crash it shows that the Debian PHP maintainers did not fully understand the idea behind that code. The patch ensures that the suhosin configuration is set to read only, but now a memory corruption exploit can just overwrite the suhosin_config pointer and let it point to a memory area that contains a new configuration."
gondolom nem olvastad el.

Tyrael

arra utaltam - szerintem erthetoen -, hogy nem egy exploit volt mar pl. windowsra ami tilos memoriaelerest eszkozolt, hogy a kivetelkezeles valamilyen (biztonsagi) hibajat kihasznalva sajat kododt futtasson.
persze ha arra celoztal, hogy linuxon ilyen hiba lehetetlen, akkor mea culpa (bar ebben az esetben sem biztos sajnos, hogy igazad van).

- Use the Source Luke ! -

> x86-on amikor software hiba miatt szakad meg a futas, mint pl. a general protection fault eseten, azt kivetelnek hivjak - egyebkent meg megszakitasnak

ize, kicsit kevered a szezont a fazonnal. az exception/interrupt/fault/etc szavaknak kornyezetfuggo jelentese van, es te szepen osszekeverted a SEH-fele exception-t a processzor altal generalttal. a ketto alapvetoen fuggetlen egymastol (egyiket lehet generalni a masik nelkul). ha mar mindenaron hasonlatot keresel, akkor a SEH-t a UNIX-fele signal fogalommal lehet tarsitani, es a szamodra fontos kulonbseg a ketto kozott az, hogy a UNIX signal mechanizmus nem hasznal olyan userland-ben tarolt adatstrukturat, amit a SEH igen es amit exploitok eloszeretettel hasznaltak ki (az mas kerdes, hogy egy konkret signal kezelo altal hasznalt adatokat manipulalva esetleg el lehet erni valami hasznosat, de az nem a signal mechanizmus hibaja akkor, es ugyanugy igaz lenne egy SEH-re is vagy barmilyen kodra igazabol). persze a hw/sw exception kezeles kozott lehet kapcsolat, pl. ha egy program egy szamara pillanatnyilag nem lekepzett virtualis cimet akar olvasni/irni, akkor az a procinal kiveri a biztositekot (page fault), amit aztan a kernel vagy lekezel (mert a virtualis cim ervenyes volt, csak nem volt alatta meg fizikai memoria) vagy teljesen ervenytelen virtualis cim eseten valamilyen modon kozol a userlanddel (SIGSEGV UNIX alatt, ACCESS_VIOLATION SEH eseten).

egyebkent nem keverem (csak pontatlanul fogalmaztam), a cpu kivetelkezelo mechanizmusra gondoltam amikor azt irtam "kivetelkezelo", azaz hogy mi tortenik egy cpu exception bekovetkezese utan , ami windowson ezek szerint ebbe az altalad emlitett SEH-be fut, unixon meg a jol ismert signalokba (szerk: mar ami).

- Use the Source Luke ! -

( lzskiss | 2010. 03. 04., cs – 14:10 )

az ilyen ugyek adjak a municiot azoknak, akik arrol meselnek a cegeknek,
miert ne hasznaljanak szabadforrast.
szanalmas toketlenlekdes, semmi mas.
egyebirant meg kritikus rendszert nem php felhasznalasaval kene osszehakkolni.

OpenBSD 4.6/i386 theo for the prezident:D

( Tyra3l | 2010. 03. 04., cs – 14:46 )

Kivalogattam a twitter uzeneteit Stefan-nak ezzel kapcsolatban:

http://twitter.com/i0n1c/status/9584579804
http://twitter.com/i0n1c/status/9743576141
http://twitter.com/i0n1c/status/9771060054
http://twitter.com/i0n1c/status/9772864412
http://twitter.com/i0n1c/status/9773525973
http://twitter.com/i0n1c/status/9775497040
http://twitter.com/i0n1c/status/9776606306
http://twitter.com/i0n1c/status/9777517157
http://twitter.com/i0n1c/status/9780627921
http://twitter.com/i0n1c/status/9781230789
http://twitter.com/i0n1c/status/9787082377
http://twitter.com/i0n1c/status/9915372207
http://twitter.com/i0n1c/status/9963743425
http://twitter.com/i0n1c/status/9963817191
http://twitter.com/i0n1c/status/9969612290

es meg ket gyongyszem egy php fejlesztotol:
http://twitter.com/PierreJoye/status/9824692262
http://twitter.com/PierreJoye/status/9799224991

Szoval az en velemenyem, hogy a debianos php maintainerek idiotak, a bugbejegyzesben minosithetetlen hangnemben utasitanak el egy kerest, keres/kerdes nelkul patchelik az upstreamet, bar nemreg volt egy kiserlet az egyik ujfiu(asszem kevesebb mint 1 eve php maintener) reszerol, osszeszedte, bekuldte a debianos php patcheket az internals-ra, ahol a patchek nagyreszerol kiderult hogy hulyeseg, a maradek reszerol kiderult, hogy felejuk nem reportolt bug, es asszem volt 1-2, amit egybol at tudott venni az upstream.

Tehat eredetileg az volt, hogy Stefan kodjaban volt egy bug, ami miatt pl. IA64-en crashelt a kod, ezt jeleztek a debian-nak, aki irt Stefan-nak egy levelet mellekelve egy patchet, arra a cimre, ami a hardened-php-s weboldalon(a suhosin weboldala) bug-report cimnek meg van jelolve.

Ezt a fiokot Stefan sajat bevallasa szerint ritkan olvassa, mert nem nagyon jon oda level.
Ket honappal kesobb megtalalta a levelet, betweet-elte, hogy nyomik a debianosok, 3 nappal kesobb betweetelte megegyszer mellekelve a blogbejegyzest, amiben lefikazta a debian-t, mellekelve a patchet, es hogy hogy kellett volna javitani valojaban.

Erre jott egy par hozzaszolas, meg retweet, hogy miert nem lehet konstruktivabban megfogalmazni a kritikat, es hogy a fele reszben az O hibaja a helyzet, hiszen ment report fele, arrol nem tehetnek a debian-osok hogy nem olvassa el.
Illetve jott egy hozzaszolas, hogy ez az egesz hiba CSAK A TESTING ES UNSTABLE agban van jelen, ez pedig sehol nem szerepelt a blog bejegyzesben.
Stefan szetflame-lt mindenkit, aki nem az o partjat fogta, es le "debian fanboy"-ozta a hozzaszolokat.
Kozben a latogatottsagatol szetlassult az oldala, ekkor meg irt par vicces tweet-et ezzel kapcsolatban, majd estere/ejszakara letiltotta a blogbejegyzest, majd masnapra atszerkesztette+letiltotta a commenteket, de elnezest nem kert, nem ismerte be hogy elegge kisarkitotta/eltulozta/elszemelyeskedte ezt az egeszet.
Ja, es persze rajott, hogy az altala javasolt javitas sem lett volna jo, helyette obfuszkalt pointer-t akar bevezetni (a fikazott debian patch legfikazottabb resze pont ennek a pointernek a bevezetese volt), amit aztan a tweet-ek tanulsaga szerint nagyobb melo volt, mint eloszor sejtette.

ps: ja, es a commenteket kezzel kellett engedelyezni a megjelenesre, es pl. az en hozzaszolasomat sem engedte megjelenni, pedig nem anyaztam, vagy ilyesmi.

Tyrael

en tudom hogy kuldtek mailt a debianosok, Stefan is elismerte.
a commentek kozott kifejtette, hogy a level amit kapott nem tartalmazta eleg reszletesen, hogy hogyan hol miert crashel a suhosin, csak azt, hogy crashel, es ezt a patchet fogjak belerakni javitaskent.
ezt o nem fogadta el normalis bugreportnak, azt irta, hogy ahhoz nem volt eleg info benne.

Tyrael

"Illetve jott egy hozzaszolas, hogy ez az egesz hiba CSAK A TESTING ES UNSTABLE agban van jelen, ez pedig sehol nem szerepelt a blog bejegyzesben."

Valóban nem szerepelt _benne_, de ez volt a _címe_. Még jó, hogy ki is emeltem cikkben. Ha nem így van, akkor kezdem azt hinni, hogy ez az Esser nem beszámítható.

Patch breaks Suhosin Security Feature in Debian Unstable/Testing

--
trey @ gépház

Öm, az itteni cikkben csak egy link neve emliti, hogy testing/unstable... cikkcímbe be kéne rakni, hogy mindenki megértse, nem lesz gáz^W^Wéles, hanem testing-ben van csak a hiba. Amit tesztrendszerre sem tesznek fel.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

eredetileg nem ez volt a cime, azt csak masnap a tobbi atszerkesztessel egyutt cserelte le.
kb. a 20. kommentben hangzott el ez a megjegyzes, meg is neztem a php forrasat emiatt, hogy tenyleg csak ott van-e.
sajnos nincs mentesem az eredeti blogbejegyzesrol, de ha hiszed, ha nem, igy volt.

Tyrael

( sj | 2010. 03. 04., cs – 16:23 )

Azert tegyuk hozza, hogy egy kicsit professzionalisabb kommunikacio es incident kezeles valoszinuleg mindket oldalon sokat segitett volna........

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

( Lacyc3 v | 2010. 03. 04., cs – 16:43 )

Francért kell hisztizni. Inkább fixálja a kódját és szóljon a Debian-osoknak hogy hé skacok fixáltam a kódot, nincs szükség már a patch-re.

"Az nemtom mennyire esett le, de ha nem szólt volna a szemét rohadék fejlesztő, akkor hamarosan a világ összes debianján vulnerable php/suhosin futott volna."
Marmint a meg kiadasi datummal nem rendelkezo squeeze stable-le valasa utan.
ha pedig nincsenek a debian-osok, akkor lehet, hogy meg jo darabig nem kapott volna Stefan jelzest arrol, hogy a szerinte senki altal nem hasznalt IA64 platformon(meg meg asszem mashol is) crashel a suhosin.

Tyrael

Nem mondtam hogy szemét rohadék a fejlesztő, csak nekem ebből az jött le hogy a Debian-osok csináltak egy - igaz lyukas - hibajavítást a testing ágba, majd ő elkezdett vergődni hogy ilyen lyukas olyan sebezhető (amiben persze igaza van), ahelyett hogy közölte volna hogy srácok ez így szar, de várjatok egy kicsit, dolgozom a hiba javításán.

Gondolom már dolgozik is rajta, csak nem így kellett volna előadni a dolgokat. Aki pedig testing-et használ, az tudja hogy mivel néz szembe.

igen, pont most olvastam, es jottem elujsagolni, de valahogy sejtettem, hogy valamilyen furcsa okbol kifolyolag te leszel az, aki mar informalta a hup-ot errol az esetrol. :D
szerintem szegeny most egy kicsit lejaratta magat.

btw: 2008-as international php confon ultem 2 eloadasan is, szimpatikus volt, mar akkor is be-beszologatott a php core fejlesztok biztonsaghoz valo hozzaallasaval kapcsolatban, de akkor meg be tudott jonni az eloadoterembe. :D

Tyrael

annyira sajnalom pedig, hogy a legzsenialisabb szakemberek mind vagy elszallnak maguktol, vagy alapbol antiszocialisak, Stefan is annyival tobbet elerhetett volna egy minimalis komprumisszumkeszseggel.
siman el tudom kepzelni, hogy ha kevesbe furdoskurvazik a php-security groupnal, akkor ahelyett, hogy sertodve eljott, el tudta volna erni egy kis turelemmel, es normalis hozzaallassal, hogy amiket kesobb a hardened-php/suhosin kapcsan megirt/kiadott, az alapbol bekerulhetett volna a php-core-ba, csak ugye a hozzaallas.
nem kellene sokat gondolkozzak, hogy meg 5-10 ilyen szakembert fel tudjak sorolni a FLOSS scene-bol...

Tyrael

szerintem nem követted te annyira részletesen a történteket... azért ez nem így volt, hogy php securitysként az első probléma alkalmával egyből lelépett megsértődve. rettentő sokáig próbálta elérni, hogy eleve odafigyelten legyenek megtervezve az alrendszerek, alapból biztonságot szem előtt tartva legyenek kialakítva a funkciók, de hiába. évekig (2001-től php core developer volt 2007-ig!) próbálta a fejlesztőkkel megértetni, hogy miért kell odafigyelni a reference counting problémákra, mennyire kritikusak lehetnek akár csak az infoleak bugok is, stb. nyilván csömöre lett belőle egy idő után, hogy basznak a többiek a javaslataira, nem csodálom, hogy párszor el is küldte a fejlesztőket melegebbre.

nem irtam sehol, hogy az elso problemanal.
azt irtam, hogy ha megfeleloen van talalva, akkor sokkal eredmenyesebben keresztul lehet vinni ezeket a dolgokat.
es azt irtam, hogy sajnos sok brillians szakemberhez hasonloan sajnos Stefan sem volt jo az emberi tenyezo kezeleseben.
a 2005-os blogbejegyzeseit ha olvasod, latod, hogy mar akkor is eleg nehez termeszetu volt.

Tyrael

Kit érdekel, ebben az esetben, hogy mit köszönhet neki? Az is kit érdekel, hogy milyen érdemei vannak? Az embereket nem az alapján ítéljük meg, hogy egyszer mit csináltak, hanem a mindenkori viselkedése alapján. Láttam már nem egy évtizedes barátságot rosszra fordulni. Ha a te logikádat követjük - és az emberek véleménye nem változik/változhat - akkor aki egyszer valakit megkedvelt, arról nem mondhat később rosszat. Esser-nek vannak érdemei, évekkel ezelőtt már említettem is, de ettől ebben a szituációban a viselkedése kifogásolható volt.

--
trey @ gépház

> Az embereket nem az alapján ítéljük meg, hogy egyszer mit csináltak, hanem a mindenkori viselkedése alapján.

A többes szám használata nem indokolt. Persze vannak olyan (valamilyen tipusú személyiségzavarban szenvedő) emberek, akik - miközben nyugodt szívvel kaszálnak havi százezreket azzal hogy mások által ingyenesen a rendelkezésükre bocsájtott szoftverekből építenek szervereket - a tisztelet és elismerés bármiféle kinyilvánítására alkatilag teljesen képtelenek. Egyet tudnak csak: nyivákolni, hogy a (számukra!) pénzt kereső developer nem a nekik kijáró nyilvánvaló alázattal szólt hozzájuk. A Magasságos Felhasználóhoz. Úgy érzik, hogy nekik minden erkölcsi alapjuk megvan arra, hogy csoportba verődve publikus fórumokon szörnyülködjenek a Gonosz Fejlesztő stílusán. A Gonosz Fejlesztő természetesen ebből leszűri a valóságot (a felhasználók kielégíthetetlen, tuskó, realitásoktól elrugaszkodott luserek), és a továbbiakban mégjobban tesz rájuk.

Na ki is itt a hibás, aki aggraválja a folyamatot? (Persze, a fejlesztő, tudjuk... a szemét)

mint írtam, szerintem meg a debian maintainer viselkedése volt kifogásolható. ha én elakarok érni valakit (pláne ilyen jellegű probléma kapcsán), akkor nem csak elküldök egy emailt és ülök a seggemen hetekig, majd utána megvonom a vállam... azt a levelet kiszűrhette volna spamszűrő is. ha egy átlag ember manapság már képes ilyenre is gondolni a mindennapi levelezés kapcsán, akkor egy nyílt forráskódú szoftver fejlesztésében résztvevő műszaki ember hogyhogy nem? sesser-t ellehet érni ezer helyen, csak ahogy a mondás is tartja, a nem akarásnak nyögés a vége.

Szerintem meg az is kifogásolható, hogy ha valaki hibázik, akkor nem azon vagyok, hogy segítsek neki, hanem az első dolgom, hogy blogbejegyzésben szénné cinkelni. Majd miután rájövök, hogy azért nekem is van vaj a fejemen (mégis csak az én szaromat próbálták javítani), átírom az egészet.

A Debian a _testing ágban_ bevezetett egy patch-et. Azért testing, hogy ott derüljenek ki, ha valami nem jó. Nem lett jó. Gondolom ez volt a történelem első esete, hogy egy probléma megjavítására tett kísérlet nem sikerült jól. Az elvárható viselkedés nem ez a raplizás a szerző részéről.

--
trey @ gépház

Valóban, ez nem az első eset, hogy a debian maintainer az általa vállalt területen szaktudás nélkül dolgozik, és még az upstream-mel sem képes érthetően kommunikálni (esetünkben a levelet a személynek elküldeni sem).

Én személy szerint megköszönöm a fejlesztőnek, hogy hangosan felhívta a felhasználók figyelmet erre a fontos problémára. A problémák csendben szőnyeg alá söprését nem támogatom.

Személy szerint megköszönöm a Debian projektnek, hogy felhívta a fejlesztő figyelmét a problémára.

Illetve Esser-nek meg kéne fontolnia az olyan technikai vívmányok használatának bevezetését vagy megfelelő használatát, mint a bugtracker. Mert ez a projektkezelés, amit csinál a projektkezelések szégyene.

--
trey @ gépház

ha egy elrontott patch alapján a debian maintainert szaktudás néküli kavarónak jellemzed, akkor ugyanezen okból Esser is szaktudás nélküli kavaró. Mindketten csináltak egy patchet, ami nem lett jó, mi a különbség kettejük között?

Amit csináltok, arra van egy jó kifejezés: kettős mérce.

> mi a különbség kettejük között?

Hogy az egyikük kódja legalább egy architektúrán működik, a másiké viszont egyen se.

> Amit csináltok, arra van egy jó kifejezés: kettős mérce.

Nem tudom, ez azért lehet mert az egyikük kóder, a másik meg csak egy csomagkészítő? Ez lehet az oka.

Nem, szerintem az az oka, hogy te meg azon topictársak, akik Esser pártját fogják, szintén programoztok, így elfogultak vagytok egyik irányba. A két figura megítélése nálatok azon múlik, hogy felhasználói vagy programozói oldalon álltok, amikor nem itt szóltok hozzá.

Mert leginkább azok háborodtak fel a véleményemen, akik programoztak már opensource projektben, tehát őket ott szorította a cipő.

Honnan tudod, hogy a csomagoló nem kóder? Aki rájön, hogy külön pointert kellene használni, meg lefoglalni memóriaterületet, annak a védelmét átfaragni, az nem hétköznapi felhasználó, erre nyugodtan mérget vehetsz.

meselj, melyik 'oldalon allok'? ;) csak mert lorian viselkedeserol nem igazan irtam (nem is olvastam az eredeti blogot), tehat a velemenyem se ismerheted. ez kulonosen azert vicces szamomra, mert en loriant olyan idokbol ismerem, amikor te internetrol meg csak a hiradoban hallottal es mondjuk ugy, hogy kb. 10 eve nem eppen barati viszonyban valtak szet az utjaink, es hasonlo okok miatt, amiert most sok debian fanboy fuj ra. na de nyilvan jobban tudod mint en, homalyosits fel kerlek ;). persze probalj meg nem tul messze kerulni a jozan esztol, mert meg ujfent trollnak talalnak hivni.

engem nem nagyon lehet programozónak nevezni, nem ebből élek, stb. én elvárnám, hogy akik komolyan belefolynak a debian fejlesztésébe, mindegy, milyen szerepkörben, azok álljanak szóba egymással. Nem gondolnám, hogy köteles egy fejlesztő a kódját folyamatosan karbantartani, de mindenképpen beszélniük kell egymással.

Akik itt nagyon fújnak rám ezért a véleményemért, azok nagy valószínűséggel azért fújnak rám, mert ők meg programozók, és azt vélik kiolvasni a szavaimból (jogosan), hogy nekik kötelezettségeik vannak azáltal, hogy a kódjuk ilyen szinten felhasználásra került. És ezt a kötelezettséget nem akarják elfogadni.

Paxteam néven szólsz hozzá, a neved és a weblapod alapján nem nagy tévedés, ha a második kategóriába sorollak be ismeretlenül. Így lettem én troll, a programozók szemében. Pedig csak azt szeretném, hogy akinek hasfájása van, az tárgyalásos alapon, normálisan rendezze azt, nem pedig két hónap csend után atomrobbanás jellegű balhéval. Se a két hónap csend, sem a balhé mértéke nem kívánatos az én véleményem szerint.

FYI

A Debianba bekerulo csomagokat a maintainerek valasztjak be es nem a programozok nyalnak csontig, hogy bekerulhessenek. Mivel az open-source lenyege, hogy kinn van a forras, ezert a maintainer siman megteheti, hogy csomagot gyart es beteszi a repoba. Emiatt elofordulhat az is, hogy az adott fejleszto higtragyat nem ad azert, ki, mibe teszi az o programjat, es ennek megfeleloen kezeli a feedbacket. (pl. mert BSD fanatikus, es a Linuxer maintainerek siramjai hajjal kenegetik sotet lelket)
A maintainer NEM kovetelheti a kod irojatol, hogy foglalkozzon a koddal, mert erre SEMMILYEN alapja nincsen. Tehat siman lehet, hogy jo emokent beul a sarokba es szipog, hogy mekkora szemet a fejleszto.

Tovabbi problema, hogy maintainerek hajlamosak a fejlesztonel "jobban ismerni" a projectet es emiatt orbitalis beleganyolasokat elkovetni. Igen, adott esetben van joga a maintainernek beleganyolni, hiszen ez is benne van az open-sourceban, viszont mas kerdes, hogy ezen ganyolas csak ahhoz szukseges, hogy a kulonfele disztribucios felepitesbeli kulonbsegeket kompenzalja, vagy epp egy komplett backdoor beepitese. Ez utobbira viszont ragnak a fejlesztok, mert az o nevuk van a kod elejen.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> én elvárnám, hogy akik komolyan belefolynak a debian fejlesztésébe, mindegy, milyen szerepkörben, azok álljanak szóba egymással.

amennyire tudom, lorian nem debian fejleszto, sot megsaccolom, hogy a legtobb debianban levo csomag iroja sem az, szoval nem ertem, ezzel mit akartal mondani.

> azt vélik kiolvasni a szavaimból (jogosan), hogy nekik kötelezettségeik vannak azáltal, hogy a kódjuk ilyen szinten felhasználásra került. És ezt a kötelezettséget nem akarják elfogadni.

es ez egy nagy baromsag, csak igy objektive ;). ha hozzam beallitana egy ilyen kis kovetelozo felfogasu user rinyalni, akkor max egy seggberugas erejeig tamogatnam meg. erdekes modon 10+ ev alatt egy ilyenbe se futottam bele, szoval eleg kisebbsegi velemenyed van, ami igy van rendjen. tudod, tovabbra sem a farok csovalja a kutyat.

> Így lettem én troll, a programozók szemében.

valoban programozo is vagyok, de troll max azert vagy, mert nem olvasod el, amit neked irnak, hanem csak dol beloled ugyanaz a hulyeseg (pl. rajottel mar, hogy a 2 honap nem a debian level elkuldeserol szolt, hanem az adott mailbox el nem olvasasarol?).

Látom, még mindig nem azt olvasod, ami írva van.
Ha én lettem volna a karbantartója ennek a csomagnak, akkor nem azzal állítottam volna be, hogy köteles vagy karbantartani, hanem azzal, hogy vagy fixálod x határidőre a bugot vagy tokkal-vonóval kihajítom a patchedet a rendszerből. A döntés a tied, nincs itt semmi követelőzés. Már többször is írtam, nem várom el, hogy megcsináld, amit akarok, azt várom el, hogy szóba állj velem. Millió meg egy vélt vagy valós indokod lehet arra, hogy miért nem csináltad meg rendesen, nekem pontosan elég az a kijelentés, hogy ez most nem lesz meg, oldjátok meg magatok a hibát vagy pedig megcsinálom és kész.

Láttál valami jelét annak, hogy nem tudom, mire vonatkozott a két hónap? Aligha.
A 21. században pedig egy "biztonsági szakértő" tudja már megoldani, hogy értesüljön minden leveléről...

> Millió meg egy vélt vagy valós indokod lehet arra, hogy miért nem csináltad meg rendesen[...]

mint ahogy annak is millio es egy oka lehet, hogy miert nem valaszol valaki egyaltalan. ilyenkor a minimum, hogy az ember ujraprobalkozik, az ertelmesebbje me'g annak is utananez, hogy milyen mas modon lehet utolerni a fejlesztot, plane hogy kozben lathatta sok helyen, hogy o el es virul.

> Láttál valami jelét annak, hogy nem tudom, mire vonatkozott a két hónap? Aligha.

"Se a két hónap csend" vs. "Egy levelet küldtek neki a patch-csel kapcsolatban február 10-én" (amit ra cirka ket hetre, es nem honapra, olvasott el). meg mindig 'aligha'? ;)

> A 21. században pedig egy "biztonsági szakértő" tudja már megoldani, hogy értesüljön minden leveléről...

levelezesi szokasoknak semmi koze a biztonsagi szakerto statushoz (de nyugodtan magyarazd el, miert, ha megis). amugy meg leirta, hogy tipikusan nem ott szoktak elerni, es mellesleg en se surun olvasnek olyan mailboxot, ahol sok ezer spam-re jut egy hasznos level. tudom, oldja meg a spamszurest. miert nem ajanlod fel neki te akkor, hogy tudod a tuti megoldast es meg is csinalod neki, biztos szivesen venne. mert a palank szelerol konnyu tanacsot osztogatni (ugy latom, te ezt nagyon szereted, csak amikor tenni is kene valamit, akkor nagy a csend).

Milyen oldalakat haluzol itt össze-vissza? Meg miért kell a LUG-ban mindenhova "oldalakat" odaképzelni. Értem én, hogy egyes politikai köröknek érdekük, hogy az embereket egymásnak fordítsák, sok birka meg be is dől nekik.

Meg egyébként honnan haluztad be azt, hogy egy fejlesztőnek bármiféle kötelezettsége van arra nézve, hogy foglalkozzon a kódjával valaha is. GPLv2 is csak annyit ír elő, hogy 3 évig köteles elérhetővé tenni a kódját. Se több, se kevesebb.

Mindenféle FLOSS mantra és álomkép kergetése előtt esetleg utána kellene nézni, hogy hogyan is működik...

----------------
Lvl86 Troll

> az első dolgom, hogy blogbejegyzésben szénné cinkelni

megvan meg valakinek az eredeti bejegyzes? mert mar annyit irtatok rola, erdekelne, mi volt (ismerve loriant van sejtesem, de megis ;).

> Azért testing, hogy ott derüljenek ki, ha valami nem jó.

az a baj ezzel az allitassal, hogy ez egy altalanosnak tuno igazsag, de megsem az, pont a mostani pelda ra a bizonyitek. az eredeti problema (es nem bug, mert tudott volt, bele volt kommentezve!) ugye az volt, hogy a lorian altal valasztott lapmeret proci fuggo volt, es 'csak' a vilag legelterjedtebben hasznalt (mar ami a php futtatast illeti) x86 procijain volt biztosan jo, mas, nagyobb lapmeretet hasznalo procikon meg sigsegv lett az eredmenye. erre mondhatna a naiv felhasznalo, hogy a javitas a sigsegv megszuntetese es kesz. a szakember viszont azt fogja mondani, hogy nem, ez nem eleg, mert ugy kell a sigsegv-t eltuntetni, hogy kozben az eredetileg szandekolt feature is megmaradjon. kulonben mi a francnak az egesz ugyebar. a debian testing-bol az derult volna ki, hogy a sigsegv megszunt, az viszont *sosem* derult ki volna testing-ben, hogy kozben az eredetileg szandekolt tamadasok elleni vedelem kvazi elveszett (persze ha be tudod bizonyitani, hogy a testing felhasznalok aktiv biztonsagi tamdasoknak es teszteleseknek vetnek ala mindent, es garantaltan kideritettek volna ezt a problemat, akkor visszavonom. de nyakam ra, hogy meg csak azt se tudjak, mit kellett volna tenni hozza). magyaran a debianosoknak goze nem volt arrol, mit csinalnak, ok a naiv programozo szemevel neztek a problemara, nem a biztonsagi szakemberevel (ismeros helyzet? ;).

szamomra az egesz helyzetbol egy nagy bug derult csak ki: a debian a mai napig nem oldotta meg a hibak korrekt kezeleset, egyszeruen nincs ra belso folyamatuk, amivel az ilyen maloroket el lehetne kerulni. a suhosin eseteben pontosan lehetett tudni, hogy biztonsaggal kapcsolatos az egesz cucc, pontosan lehetett tudni, hogy az adott kod/feature biztonsaggal kapcsolatos, pontosan lehetett tudni, hogy lorian tudta, mekkora hack es ennek ellenere egy emaillel elinteztek az upstream-et, mondvan ok majd jobban tudjak. bocs, de ez minden, csak nem professzionalizmus (igen, meg kellett volna keresniuk loriant es kikerni a velemenyet, akkor is ha ez tobb, mint egy szem emailbe kerul, akkor is, ha mondjuk a bugtraq-en kell lorianra rapiritaniuk. meg mindig jobb, mint szar kodot a felhasznalok nyakaba zuditani). en magamrol ugy tartom, hogy ertek valamit a sajat teruletemhez, de ennek ellenere ha nem vagyok 100% biztos valamiben, akkor inkabb rakerdezek a szakertonel (l. sparc64 NX tamogatas, ami csak par evig volt teljesen hibas linuxban es 10 perc alatt javitotta DaveM, amikor ramutattunk - kb 1 sor kod, de en megse mertem magam belevagni, mert sparc-on nem erzem magam annyira otthon).

Minden egészséges lelkületű emberrel megesik, hogy anyázik valami probléma/feladat kapcsán - talán kissé túllihegve a dolgot, vagy csak szimplán érzelmi reakciót vált ki benne egy olyan probléma, amit második nekifutásra már higgadtabban szemlél, vagy fejlesztés/kódolás/problémamegoldás közben szimultán szeret káromkodni, mert így érzi jól magát.

Szerintem az igazi probléma ez esetben az, hogy valaki káromkodás helyett egyből tweetel. Abba meg bele se merek gondolni, mi lett volna, ha pl az mplayer fejlesztők twitterközelben lettek volna anno.

Why did you start the Hardened-PHP Project?

Stefan Esser: The Hardened-PHP Project was founded in 2004 in response to a number of security bugs I found in the PHP source code. The idea of a hardened version of PHP was actually much older, but it was never implemented until 2004. The problem I saw with PHP was that often some new feature was hacked into it in a dirty way without thinking about the consequences for other areas of the code. Additionally after having fixed a number of remote exploits in CVS versions of PHP before they made it to release versions, I stopped trusting the code at all. Therefore the low-level protections like canaries, safe_unlink were implemented. Additionally it seemed a good idea to stop remote URL includes by completely forbidding them. The HTTP response splitting problem was also killed at the low level by stopping newlines in PHP's header() function. During the time more and more features made it into Hardened-PHP. [That is] until I was ordered by the PHP Group to rename my "fork" because of the PHP license. Because the PHP license actually contains such a paragraph the Patch was renamed into the Hardening-Patch for PHP, although I still don't get why they attack a PHP security extension in such a way. Later that year the Hardened-PHP Project became bigger, when two german security researchers from the PHP community joined the team. We started offering PHP security audits and PHP security courses. The two other team members finished their german PHP Security book and gave several PHP Security talks at various PHP conferences.

http://www.securityfocus.com/columnists/432

Tyrael

amennyire latom, meg a userspace a legjobb resze az egesznek, belul meg nagyobb gany. :)
de sajnos imho mar elerte azt a pontot a php, hogy tul nagy a kozossege, hogy szarjanak a visszafele kompatibilitasra, es tul nagy a kodbazis ahhoz, hogy valaki gyorsan ujrairja/forkolja.
talan majd a soha el nem keszulo PHP6-ban :D

Tyrael

Nem biztos, hogy ez lehetlen. Pl. Python esetén a Google LLVM alapokra próbálja helyezni a CPython implementációt: http://code.google.com/p/unladen-swallow/

PHP-nak is létezik alternatív implementációja (a Facebook-os compileren kívül is, ami azért egy speciális felhasználás): http://www.caucho.com/resin-3.0/quercus/

Nyilván sokan undorral elfordulnak ettől (mert fúj Java), illetve sok esetben nem is lehet alkalmazni, mert hiányoznak natív modulok, máshol viszont, ahol backend rendszerek esetleg Java-ban vannak, akár hasznos is lehet.

A lényeg, hogyha lenne üzleti igény erre (minthogy a Google-nál volt Python oldalon), akkor ez egy belátható méretű, megvalósítható projekt.

Üdv,
Gergely

tudom hogy leteznek alternativ interpreterek, de ott meg megint az a gaz, hogy muszaj userland-ban kompatibilisnek maradniuk az amugy elegge ad-hoc-nak tuno phpvel, raadasul mivel az konzisztensnek/kiszamithatonak/intuitive-nek a legkevesbe nevezheto a php, ezert kurva sok melo, plusz egy csomo dolog nem dokumentalt viselkedes, es akar egy minor verziovaltassal is eltunhet.

Tyrael

( hzsolt94 v | 2010. 03. 23., k – 11:25 )

A Debianosok találtak a patchben egy hibát, kijavították, majd megkérdezték tőle hogy mi legyen vele.
Ő le se szarta a levelet, vagyis nem érdekelte, hogy mi lesz a projektjével.
Ezután a debianosok csináltak amit jónak láttak, vagyis javították.

Majd egyszer csak észrevette a hibás patchet.
A probléma az, hogy ha egyszer nem foglalkozott azzal, hogy mi legyen a patchel, akkor utólag miért, milyen jogon, anyáz bárkit is?
Ha segíteni akar, tegye meg, de ha egyszer megkérdezték, és nem válaszolt, akkor vegye tudomásul, hogy nem érdekelte a dolog.

Ui: Tudom hogy régi, de most ráakadtam, és ezt le kellett írnom.