Balhé a PHP Suhosin patch körül

 ( trey | 2010. március 4., csütörtök - 11:51 )

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.

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

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

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

Miért ne tehetné meg? Hobbiból csinálja a dolgot, nem fizetik ezért, úgyhogy lehet 1000+1 jobb elfoglaltsága.

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

leszarom az elfoglaltsagait. akkor ne hobbizzon, ha nem kepes egy emailre valaszolni 2 honapig.

ertsd: ezt a patchet SOKAN hasznaljak. nem arrol van szo, hogy irt valaki egy helloworldot "hobbibol".

A nyílt forrás tudod, biztonságosabb, mert mindenki beletekinthet, és javíthatja hibákat.
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

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

igen, ha vegigolvastad volna a szalat, lattad volna :)

Tyrael

hat milyen hosszu mar, vegigolvasni nem fogom, de rakerestem verziora, arra nem volt talalat ugyhogy bepostoltam, meg itt felul jobban nez ki;]

Ha végigolvastátok volna a szálat, láthattátok volna, hogy nem erre gondolok. ;)
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

> ezt a patchet SOKAN hasznaljak

Akinek fontos hogy működjön is, az BSD-n.

Majd ha azok a SOKAN akik használják pengetnek a project vezetőnek, akkor elvárható lesz, hogy olvassa a leveleit. Addig azt csinál amit akar.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Azért szerintem ennek nem így kellene működnie. NagyZ-nek igaza van. Ha valamit elvállal, akár ingyen, akkor foglalkozzon vele. Ha nem, akkor adja át másnak.

Van egyáltalán valaki, akinek átadhatja?

KisKresz

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

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$%#$#%^*^"

amig van valaki aki megfelelo minosegben csinalja, addig nem fogjak forkolni, de ez nem jelenti azt, hogy ne lennenek mas fejlesztok, akik ilyen, vagy magasabb minosegben meg tudnak ugyanezt csinalni.
ahogy peldaul tortent a XFree86=> X.org eseteben is.

Tyrael

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?

> Az számít, hogy elvállalta, nem az, hogy mennyiért.

Lássuk azt a rendelkezésreállás-vállalási szerződést.

es ha nincs, akkor lehet hisztizni? :)

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. "

jobb pelda: kipublikalok egy kodot, karbantartom, aztmondom hogy milyen fasza, hasznald. aztan valaki jon, hogy szar az egesz, en meg le se szarom.

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. "

+1

Amugy meg a debianosoknak minden adott volt h jobban megcsinaljak, v - mint bizonyos helyeken ilyenkor - visszaallnak az elozo verziora

Ezt az összes szabad szofveres projektre ráhúzhatjuk. :D

Várjunk csak: s/kipublikálom a kódot/eladom a binárist/ , máris lefedtem a kereskedelmi szoftvercégeket is. :D

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

azert en feltetelezem hogy aki megcsinal 0 rol 1 jo szoftot az jobban erte hozza mint a packagerek

Megteheted, a lesemszart illető meg forkolhat egyet.

Nem is lenne ennek ekkora éle, ha nem épp valami aktuális ueber opensource szekuriti lenne a topic.
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

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.

Minden egyes mondatod igaz, és pontos! Egyetértek!

"(ismétlem: köteles)"

Akkor pereld be. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

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. "

Egri bikavér néven kapnál két szőlőfajtából összerakott házasítást helyben összeöntve egy harmadik fajtából készült borral.

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

> akkor szerinted mit kellene tenni?

úgymond érteni hozzá

Te már remekül értesz hozzá, amíg nem kell tenned semmit:)

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

meg mindig nincs bugtrackere a suhosin-nak, de mar legalabb elkezdte Stefan keresni valamit a celra, csak semmi sem eleg jo neki)

Meg nekem is van: JIRA

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

"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.

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

hahaha


No rainbow, no sugar

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

szerintem semmire sem koteles, mint ahogy te sem vagy koteles hasznalni a termeket/patchet/akarmiet. Ha neked nem tetszik valami akkor nem hasznalod, neki meg ha nem tetszik valami akkor nem foglalkozik vele.

+1
Asszem a flame-ben ezután részt sem kell vennem, ez egy teljesen jó kifejtése ugyanannak, ami az én véleményem is.
--
- Jó estét - zökkent le nehézkesen a tomporára. - Én vagyok a konyhamester ajánlata. Felajánlhatom önöknek a testrészeimet?

Nem tudom melyik univerzumból jöhettek, ha az a véleményetek, hogy egy fejlesztő a saját hobbi projektjét köteles fenntartani teljesen ingyen, ha mások érdeke azt kívánja... :)

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.

együttműködni köteles

és ugyan miért lenne köteles együttműködni bárkivel is a saját projektjén?

a hobbi projekteket nem szokták kiadni.

LOL, szólj Linusnak, hogy elkúrta! :)

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 :)

http://hup.hu/cikkek/20100304/balhe_a_php_suhosin_patch_korul#comment-971313

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

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

Aki kiadja az alapvetően jófej, de aki nem szereti a debiant az bármikor, ótvar stílusban, publikusan számonkérhető. Remélem így már világos. :)

ebben a mondatban az az egyetlen pozitívum, mégha ez igen nagy pozitívum is, hogy nem szerepel benne a debian ssl string...

Debian meg ssl? Ez a kettő eléggé kínos dolog egy mondatban együtt... Több szem, többet lát, Több debian maintainer több sz@rt kavar...

úgy érzem, pár lényeges dolog most kimaradt neked...

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

> tudtommal ha valaki akadályozza a közösséget

A szemét, security patch-et csinált a php-hez! Szabotőr! Áruló!

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

Helyesen: Turing

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. "

Esetleg dd-wrt?

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

http://en.wikipedia.org/wiki/Cdrkit
forkoltak.
ION-t nem ismertem, de
http://en.wikipedia.org/wiki/Ion_%28window_manager%29
alapjan, nekem nem tunik kocsognek, csak azt szeretne, hogy amit mas belerak, azt ne vele supportaltassak.

Tyrael

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. "

Azt hittem olyan peldat fogsz irni, ahol a kocsog fejleszto szopatja a kozosseget, aki ezt tetlenul turi.
Ehhez kepest ugy tunik, hogy nem jok a peldak, vagy nem ertem.

ps: a wikit olvastam, hiszen en linkeltem.

Tyrael

Nem ezek olyan peldak, amikor a kocsog kozosseg szopatja a fejlesztot, amitol aztan ok felvesznek "egyfajta" stilust, amitol a kozosseg szemeben kocsogge valnak.

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

akkor felreertetted a kerdest:
"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)."

Tyrael

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

ahol nagykepu kocsog fejleszto van, es megis elturi a kozosseg(OpenBSD-t nem er mondani).

Ez tetszett ... :-)

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

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

És ez pont azért van, mert az open source fejlesztőkön nem lehet számonkérni, hogy fixálják a bugot, implementálják a kért funkciót. Ezért ha a maintainter nem lép az ügyben, akkor a probléma nem lesz megoldva.

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

Így van, nem lehet számonkérni senkin semmit. Mert az open source fejlesztés és felhasználás egy szimbiózis, ha nem teljesül az, hogy mindkét fél számára van hozadéka az együttműködésnek, akkor nem fog működni.

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

te kussolj és takarodj vissza mplayert kódolni, mert nem engedtük meg - mi, a Közösség -, hogy odébb állj!

neked ez kötelességed, hogy kiszolgálj minket!

Sir, yes sir!

(Kar, h nem erdekel, mert mplayer fejlesztesbol tok jol megeltem amig tanultam, bar teny, h az akkori es mai igenyeim kozott kb. fenyevnyi kulonbseg van. Ma mar nem eleg egy zsirosdeszka es ket fel pohar viz vacsorara.:)

---
pontscho / fresh!mindworkz

hát el is híztál azóta! :P

A', azota mar megoldotta ezt a kerdest a remek allapotban levo maganeletem.

---
pontscho / fresh!mindworkz

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

A developer biztonságossá teszi a php-t
A debian meg sebezhetővé

Tényleg érthetetlen hogy miért pont a debiant anyázza ;)

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.

Viccelsz? Még mindig ugyanaz az OpenSSL karbantartó...

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

Jó hallani, hogy a Debian is magyar disztró! (párhuzamot vonván a következmények nélküli ország és ez között)


suckIT szopás minden nap! Solaris Itaniumon

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

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

A kérdés valami olyan volt, hogy debug céllal kikommentezhető-e? Ha jól rémlik a dolog...

5 év 32 hete regisztráltál

Tyra3l szerint ezek a számok valamiféle érvek a vitában. Kérdem: most mit érzel?

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...

+1

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

"Asshat is a slightly trendier and less severe variation of asshole"

Miért van az a téveszméd, hogy egy IT biztonsági beszélgetésben a vitapartnered leseggfejezése rád nézve pozitív dolog?

ehhez szotar kellett?
azt hinne az ember, hogy irc-n nap mint nap megkapod ezt a jelzot.
miert van az a teveszmed, hogy egy ezer eves leragot csont tema allando felemlegetese ervkent szolgalhat minden IT biztonsági beszelgetesben?

Tyrael

Igazad van.

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.

Már megint a debianról beszélsz egy debian topicban. Te sssszemét!

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

Igen, pont ezt mondtam.

Pedig nem.

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

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, hogy más véleményed van, okot ad a személyeskedésre?

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. szerintem a velem való személyeskedés nem tartozik ehhez a témához, úgyhogy kezdd azzal, hogy leszoksz róla.

> 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 ;).

Subscribe :)


suckIT szopás minden nap! Solaris Itaniumon

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.

Ez zsir volt, koszi :)

--------------------------
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

etalon
+1

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

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 ;).

Idézet:
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?

Az a baj, hogy nem kért Közösségi Engedélyt az újratelepítés időpontját, és a minimálisan egyszerre olvasott mailboxok számát tekintve. Sssszemét.

lol :)

Elindulhatunk abba az irányba is, hogy egy ilyen embernek hány olyan számítógép van a környezetében, amelyen meg tudja nézni a leveleit.

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

Egy bizonyos érettségi szint elérése után az ember már nem mutt-olásra alkalmas gépeket gyűjt maga köré "szabad"idejében.

Értem. Akkor biztosan csak az az egy gépe volt.
De ezt a thread-et meghagyom nektek, csak pár kérdés felmerült bennem.

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

A számolás egyszerűsítése végett számoljuk inkább azokat a gépeket, ahol NEM tudta volna megnézni.

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

ha mar annyira emlegetted, hogy biztonsagi szakember, akkor esetleg leeshetett volna, hogy nem veletlenul olvas bizonyos leveleket csak bizonyos kornyezetben. just some food for thought... ;)

Értem. Mondjuk egy levelező-, vagy issue-lista valóban tartalmazhat érzékeny adatokat. :)

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

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."

Énb meg a programozás oktatását, mielőtt bármilyen nyelvhez nyúlna...

Nem kell, de akkor drámakirálylányt se kell játszani.

Meg nyafogni se kell ha nem tetszik. ;)

Akkor ne nyafogj. Mondd szépen: OpenSSL, debian mindent elront.

Ezt baromijol lesummaztad, kosz

--------------------------
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

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

szellemisege

Erre egy LOOL keves.
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

+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. "

Azzak a különbséggel, hogy itt már a szellemiség is egy vicc.
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

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

temahoz vmit?

--------------------------
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

Ez nem az a topic.
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

Forkolj, azt' leadeld jobban a projekted! :^P

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

+1...

de sajnos ez az opensource/foss/hup igy mukodik

lehet, hogy inkább SMSt kellett volna írni neki:)

omg

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

Az egó a FOSS halála :/

ne legyel ilyen szigoru a debian-hoz

--
NetBSD - Simplicity is prerequisite for reliability

:P

ne legyen felszólító a mód?

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

Hogy mondhatsz ilyet?
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

Megver a zisten!!1!

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

nagy szarból csináltak kisebb szart.

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

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.

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."

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

És ott folytatódott, hogy a debian fejlesztők a bug-ból vulnerability-t csináltak. Megint. (bár az OpenSSL-nél még bug se volt)

-1

/* miert lett oly divatos manapsag a debian fejlesztoket leszolni? */

mert a debian mar regen se volt jo :))

te aztán tudod...

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

ha eppen tudni akarod, 3-4 evig debian juzer voltam, szerveren, desktopon. most hogy ezt leirtam, jobb valamivel? ;-)

problema: stable agban regi minden, testing/unstable meg nem stabil.

+1

Elég gyors a felfogásod :)

jobb :)

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

es gondolom akkor habzo szajjal vedted azt, es fikaztad a tobbit.
legalabbis teged ismerve biztos igy tortent.

Tyrael

igazabol akkoriban a laptopomon gentoo volt, ... :)

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.

Idézet:
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.

lol
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

Dehátaztnemlehetmegkülönböztetni, megmondták a linuksz fejlesztők is!!!

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

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

> azt vagod, hogy nem lett sebezhetobb a php attol amit csinaltak

De, a php+suhosin védtelenebb, sebezhetőbb lett, mint előtte. De az alapprobléma nem is ez, hanem hogy a debianban ezt a csomagot se hozzáértők rakják össze.

read only memoriat szeretne irni es valamifele memory error/segfault-ot kap. szerinted ezt hogy lehetne ekszplojtalni? :)))

--
NetBSD - Simplicity is prerequisite for reliability

Nem folytam én bele ebbe, nem is igazán érdekel. Érdekelje azt, aki a bugot lekódolta. Ahelyett, hogy eljátssza a hattyú halálát.

--
trey @ gépház

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.

Kimaradt, hogy a hisztérika letiltotta a kommenteket, illetve megnyirbálta, átfogalmazta az egész blogbejegyzését, mert vállalhatatlan volt számára.

A többi stimmel.

--
trey @ gépház

Akkor javítom.

3. az opensource fejlesztő ideges amiatt, hogy inkompetens emberek patchelik tönkre a kódját ---> "hisztérika!"

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

Nem tudom mire jó, hogy leostobázod az alap PHP fejlesztőit.

Na kezdődik a szokásos terelés. Innentől kezdve itt magaddal beszélgetsz.

--
trey @ gépház

Olyannal nehéz is, aki szerint egy patch megváltoztathatja az alapprogram licenszét.

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.

Semmi baj, joga van véleményt alkotni, vagdalkozni, zacc blogbejegyzéseket írni, másokat hibáztatni, hisztizni, majd blogbejegyzést átírni, megnyirbálni, méltatlankodni. Max. befeszülve hülyének fogják nézni.

--
trey @ gépház

Itt legfeljebb te vagy a hisztis.
Beszívtad a bugot, s feltörték miatta a szervered, azért vered ennyire a nyálad?

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

Ennyi ideje regisztrált felhasználó
3 nap 23 óra

De azért aktívan töltötte el ezt a kis időt is, már több topicban is olvastam tőle ilyen kirohanásokat......

Dehát állítólag nem is segít a feltörésben... :/ :?

Ezért nem értem, miért nyáladzol ennyire ezen a témán.

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

és ez akkor is megtörtént volna, ha egy nagy megaszoftvercég alkalmazásában áll, és ott kódol egy zárt proprietary projekten, ha két hónapig nem válaszol a kódját érintő emailekre. plusz ebben az esetben jó eséllyel ki is rúgnák a sajátos levelezési szokásaiért:)

http://twitter.com/PierreJoye/status/9824692262
"Don't patch my patch!" I'd to say, don't patch our softwares! use the src, get it here:
http://www.php.net/downloads

Tyrael

"3. az opensource fejlesztő ideges amiatt, hogy inkompetens emberek patchelik tönkre a kódját": hát akkor patkolja meg saját kezűleg.

ennyi.

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 :)

Jobb amúgy az ilyen, mint az esti szappanopera, komolyan mondom!
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

Ja, csak itt nem Alfredo és Lucilia a nick :)

> másokat szőnyeg alá söpörve (testing/unstable)

Ha ez valóban jelentéktelen körülmény, akkor miért van a hupon róla cikk? :O

Nem vagyok tapasztalt újságírás terén, de úgy veszem észre, hogy nem csak arról szoktak hírt lehozni, aminek gyakorlati jelentősége is van.

A hup trey saját különbejáratú portálja. arról van benne cikk, amiről trey akarja, hogy legyen.

Ez meg a másik.

vagy arrol aminek a szoveget le tudja forditani osnews-rol :)

--
NetBSD - Simplicity is prerequisite for reliability

Hát, de tényleg.
--
- Jó estét - zökkent le nehézkesen a tomporára. - Én vagyok a konyhamester ajánlata. Felajánlhatom önöknek a testrészeimet?

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 debian pancsolása előtt volt ilyen (szerintem sebezhetőség, szerinted feature) lehetőség abban a kódban, vagy sem?

Nem tudni, senki sem próbálta még ki.

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

Sajnos zárt forrású, úgyhogy tényleg nem tudni.

Mi?

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

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.

en felteteleztem, hogy elolvastad azt a blogbejegyzest, amirol allitolag "cikket irtal" (ugyanis korrekten le volt irva benne mindez)

--
NetBSD - Simplicity is prerequisite for reliability

"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

Ő másról beszélt. Én értettem miről.

--
trey @ gépház

ja, tehat az eredeti crashnek lehetett-e biztonsagi vonzata, bocs, felreertettem, itt termeszetesen igaza van Replaced-nek, may annyi tortenhet, hogy elszall az alkalmazas mikor megprobal irni a helytelenul read-only-va tett memoriateruletre.

Tyrael

nem jott at a mondanivalod

--
NetBSD - Simplicity is prerequisite for reliability

hint: Követni kell a linket.

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

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 ! -

jézus ne hagyj el

umm ize, php c-ben van irva es foleg linuxon es bsd-n futtatjak (nem mellesleg mprotect/mmap is csak posix rendszereken van, lasd az ifdefeket a patchben, hth), tehat amit linkeltel annak semmi koze a temahoz, de azert nice try

--
NetBSD - Simplicity is prerequisite for reliability

/o\

hol talalod hibasnak a gondolatmenetet?

- Use the Source Luke ! -

szinte az lenne a kérdés, hogy hol nem

nem lattal olyan exploitot (googleben pedig irjak par helyen)?
vagy a linux kivetelkezelese tokeletes, csak a windows-e nem volt mindig az?

- Use the Source Luke ! -

kedves szakmai denes!

C-ben miota van "kivetelkezeles"?
mellesleg, ahhoz hogy ez mukodjon kellene egy masik bug is, hogy atirhassa

--
NetBSD - Simplicity is prerequisite for reliability

1. x86-on amikor software hiba miatt szakad meg a futas, mint pl. a general protection fault eseten, azt kivetelnek hivjak - egyebkent meg megszakitasnak
2. ebben teljesen 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 ! -

-

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

Oszt most miért is?

melyiket nem erted, a toketlenkedest, vagy a kritikus rendszert nem php felhasznalasaval fejleszteunk?:)

OpenBSD 4.6/i386 theo for the prezident:D

#define kritikusrendszer + miert kilove innen a php?

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

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

"the number of whining Debian fanboys is growing and growing.They cannot accept that if you don't tell the vendor about a bug he can't fix it"

aztirtak itten kerlek hogy a debianosok kuldtek emailt a sracnak, o meg nem olvasta. szoval innen csak fapfapfap az egesz

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

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

timeout :)

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

Kiküldjük noveriat, ő elég profin kommunikál:PPP

lol :D

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

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.

FYI

"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.

elmeletileg mar javitotta is
http://twitter.com/i0n1c/status/9969612290

Tyrael

igazából jobban elrontotta, mert így az egész config rw maradt (elfelejtette dekódolni a ptr-t), de szerencsére jött "valaki", aki szólt, hogy nagyon nem jó és most sesser veri a fejét az asztalba... ;)

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

nekem nem szimpatikus (más, korábbi dolgai miatt), de ennek ellenére elismerem munkáját és a tudását. jelenleg a legnagyobb php security szakértő és az a híres-neves közösség - amelyik most is kutyázza - rohadt sokat köszönhet neki...

FUD! :]

---
pontscho / fresh!mindworkz

> rohadt sokat köszönhet neki

nemis, mer' mexegte Az Egyezményt!

:DDD

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)

Világossá vált már korábban is (és mások is említették már), hogy az olvasási és szövegértelmezési képességed szelektív, ezért újra:

"Esser-nek vannak érdemei, évekkel ezelőtt már említettem is, "

--
trey @ gépház

Remek kis absztrakt félmondat, csakhát a cikkben nem nagyon fellelhető, és egy 222 hozzászólásos flametopic kellett egyáltalán a felbukkanásához is. Nem tudom ez miért van.

Sőt, időgéppel visszamentem 2008-ba és oda is becsempésztem egy hozzászólást Esser-ről, hogy lehessen rá hivatkozni. Egy jó tanács: fejezd be a céltalan kötekedést, mert nem éred meg az egy hetes regisztrációt. ;)

--
trey @ gépház

Nyugi csak vicceltem, illetve kötekedtem. Céltalanul. Valójában mindvégig igazatok volt.

Nem, nem vicceltél. Négy napja próbálsz trollkodni és lázítani minden topikban. Nem te nem vicceltél, hanem én nem vicceltem, amikor azt mondtam, hogy utolsó figyelmeztetés.

--
trey @ gépház

\O/
 |
/ \

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

/o\

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.

+1. Meg egy csomagkarbantartó a csomag karbantartását végezze, és ne a kódot hegessze (Ez szereptévesztésnek tűnik, és nem csak nekem...)

+1.

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.

"upstream-mel sem képes érthetően kommunikálni"
Ez fordított irányban is elmondható.

Sorrendiség. Hülye kérdésre hülye válasz. Nincs min meglepődni.

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

+1. Egy hatar felett lehetetlen emailben kezelni az issue-kat. Btw. mar keresi, lehet, hogy az mtrack lesz az...

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

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.

> programoztok, elfogultak vagytok

Mi lett volna a második tipped?

troll?:))))

TROLL: Ha valakinek a közösséggel nem megegyező önálló véleménye van a témával kapcsolatban

az én felfogásom szerint troll az, akinek a józan ésszel nem megegyező önálló véleménye van.
mert ha csak annyi a troll definíciója, hogy a közösséggel nem egyezik a véleménye, akkor nyugodtan trollozz le engem, igazad lesz.

> az én felfogásom szerint troll az, akinek a józan ésszel nem megegyező önálló véleménye van.

az eddigi amokfutasod a szabadidos fejlesztokrol boven kimeriti a sajat troll definiciodat. bar oszinten szolva az 'onallo' reszrol nem vagyok 100% biztos.

bizonyára objektíven ítéled meg a dolgokat, miután nyilvánvaló, hogy melyik oldalon állsz.

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.

Idézet:
10 eve nem eppen barati viszonyban valtak szet az utjaink, es hasonlo okok miatt, amiert most sok debian fanboy fuj ra

Hogy nem olvassa a leveleit? :)

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