Java 7 0-Day sebezhetőség, exploit

Java

A hírek szerint súlyos sebezhetőség található a Java 7-ben. PoC exploit kering szabadon. Korlátozottan már ki is használják a hibát. A Metasploit Exploit team nem tétlenkedett, tegnap este neki is látott a cucc feldolgozásának. A PoC felhasználásával néhány órán belül működő exploitot gyártottak. A javaslat: a probléma súlyos problémaként kezelése és a Java teljes letiltása a javítás megérkezéséig.

[ Windows 0day exploitation with Internet Explorer, Firefox and Chrome | Ubuntu 12.04 exploitation with Firefox ]

( saxus | 2012. 08. 27., h – 22:26 )

És most akkor kit, hogyan fogunk felelősségre vonni? :)

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

"The Oracle patch cycle is 4 months (middle of February, June, October) with bugfixes 2 months after the patch. The next patch day is October 16 - almost two months away. Oracle almost never issue out-of-cycle patches"

Nem tudom, de pont az ilyen trógerkodásokból van elegem.

--
trey @ gépház

Amikor meg jön egy out-of-cycle patch, akkor meg minden admin hőbörög, hogy de ezt most miért kell most rögtön azonnal, meg miért figyeljem folyton, hogy van-e új patch, akkor geci programozók szemétládák, mert javítani merik a szoftverüket.

Tipikus van-e rajta sapka esete.

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

Mellébeszéd. A programozó/vendor kötelessége kellene, hogy legyen, hogy késlekedés nélkül javítsa a hibát. Azt majd én eldöntöm, hogy mikor terítem le.

Amiről te beszélsz az egy bizonyos redmondi cég mellébeszélése arról, hogy mi az a patch kedd és az miért úgy van.

--
trey @ gépház

Miért kellene? Kötöttem bármilyen szerződést az Oracle-al, hogy neked azonnal javítanak Java bugokat? Akkor mi alapján lenne bármiféle kötelezettsége? Mert te azt mondtad?

Igen, létezik ilyen, kössél rá support szerződést. Velünk is kötöttek anno, ha volt bug, javítottuk.

Egyébként látszik, hogy fingod nincs a szoftverfejlesztésről, az ott felmerülő projektszervezési problémákról, akár műszaki, akár humán oldaláról. Marha vicces elvárni a most rögtön azonnal hibajavítást, aztán meg hőbörögni, hogy szar, mert neked azonnal kell és nem maradt idő normális tesztelésre. (persze, te "ráérsz eldönteni, hogy mikor rakod fel").

Pont az MS-sel kapálózni meg egyébként vicces az Oracle-al szemben, mivelhogy egy hét még mindig jóval kevesebb és azért elő-előfordul ott is soron kívüli javítás.

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

"Hogy a szarát feltakarítsa. "

Kötelezett valaki, hogy használd? Fizettél érte?

Szerk.: Egyébként meg szó nem volt arról, hogy nem javítja. Ugyebár megvan mikor, milyen ütemen mit csinál az Oracle és, hogy mit vállal. Elvileg ezzel tisztában kellett, hogy legyél.

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

Nem lehet mindent pénzre lefordítani. A cégek közül a korrektebbek az ilyen problémákat rendkívül komolyan veszik. Gondolok itt a Google security reward programra, ahol az _ingyenes_ Chrome hibákkal nem elzavarják az ügyfelet, hanem még fizetnek is neki, ha hibát jelent be.

Szerencsére lehet választani. A szerencsétlenség a szerencsében az, hogy bizonyos dolgokat nem lehet megkerülni. Törekedni lehet rá. Én is azt teszem. A nem korrekt cégektől és termékeiktől igyekszem magam minél távolabb tartani.

Lehet ganékodni, magas lóról ugatni, csak nem biztos, hogy az kifizetődő.

--
trey @ gépház

A Javát olyan sokan használják, hogy a vendornak komoly felelőssége van az ilyen bugok esetén. Közveszély forog fenn.

És mellesleg ugyebár a vendor őrülten nyomatja kifelé a JDK 7-et, hogy használd, hiperszuper. (Az neki jó üzlet, mert konzultanciát el tud hozzá adni vastag pénzekért... *racle ilyen-olyan napok, regisztrálj most kedvezményesen)

Na ezért illik neki izzadva azonnal kijavítani az ilyen csúf hibát. Mert rád tukmálta.
(Ez nem arról szól, hogy nem vagy köteles használni, ui. azt mondták neked, hogy tök jó és biztonságos.)

"Like any other piece of software (and information generally), djbdns comes with NO WARRANTY."

http://cr.yp.to/djbdns/install.html

Magyarul lehet, hogy garantálják, hogy nincs benne sechole, de attól még garanciát ők sem vállalnak. "like any other pice of software". :)

Bocs, de ez nekem a "nem szartam bele, csak mellé és beleraktam" kategória még mindig.

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

Kötöttem bármilyen szerződést az Oracle-al, hogy neked azonnal javítanak Java bugokat? Akkor mi alapján lenne bármiféle kötelezettsége? Mert te azt mondtad?

Nem tudsz ilyen szerződést kötni azzal a céggel :D
Ez - emlékeim szerint - még a Sunos időkben sem működött, az Oracle-nál pedig kb. esélytelen, hogy bármit vállaljon a cég. A support arról szól, hogy az Oracle megengedi, hogy fizess neki, aztán vagy kapsz érte valamit, vagy nem. Ez egyébként a cég egyik alapfilozófiája: fizess, és örülj, hogy az ügyfelünk lehetsz :)

"A programozó/vendor kötelessége kellene, hogy legyen, hogy késlekedés nélkül javítsa a hibát."

Tündéri a naivitásod. Az esetek döntő többségében órákon esetleg napokon belül tudnának neked javítást adni. Amint a programozó a hibát elő tudja idézni és felfogja, kitalál egy javítást, felrakja, lefut sikeresen a regression és már mehet is ki. Ha te saját kockázatodra felvállalod, hogy ezt az felteszed a saját rendszeredre, az tök jó, annak örülnének a fejlesztők, mert lenne egy jó kis feedback. Az a baj, hogy néhány eset után rájönnél, hogy inkább vársz egy-két hónapot, mint hogy rajtad kísérletezzenek. Egyszerűen a szoftverek komplexitása olyan, hogy nincs senki, aki átlátná egy változtatás lehetséges kihatásait. A rengeteg teszt fázis miatt lassú és költséges egy hibajavítás kiadása. Hidd el, a programozók legalább annyira dühösek és frusztráltak a lassú kiadások miatt, mint te. Ha felakasztod a fejlesztőket, azzal viszont biztosan nem jutsz előrébb.

Komoly nemzetbiztonsági kockázatokat rejtő hibáknál legfeljebb annyit lehet tenni, hogy kevesebb teszttel, hamarabb adják ki a javítást. Ebből születnek általában a teljes rendszerleállások...

Pedig épp most javítottam ki egy vevő által ma talált hibát. Még Bugzilla ID-ja sincs, olyan friss. De eltart egy ideig, mire minden vackon leteszteljük és kimehet, pedig a unit tesztek szépen lemennek rá. A vevőnk pedig ugyanúgy fog szidni engem, mint te a Java fejlesztőit.

Hmm, szoval ha hianyzik egy pontosvesszo, azt is kethetes intervallumban javitod, mert hatha szar a Java compiler parzere? Kicsit nagyon nincs koze annak amit irsz ahhoz, amirol szo van.

"Egyszerűen a szoftverek komplexitása olyan, hogy nincs senki, aki átlátná egy változtatás lehetséges kihatásait."

Hat pont ezert vannak a minel bonyolultabb testsuite-k, nem? Hogy a leheto legtobb esetet lefedve minel pontosabb kepet kapjunk, nem csak arrol, hogy most hogyan mukodik a rendszer, hanem hogy a korabbi hibak kozul egyet sem hoztunk vissza azzal, hogy javitottunk valamit a rendszerben.

Illetve, erzesre mas prioritassal kellene menjenek a security hibak (foleg az aktiv serulekenysegek) mint az egyeb tipusu hibak. Ez kb. olyan, mintha nekem rossz lenne a zaram, a lakatos meg azt mondana, hogy hat kerem, korulbelul ket honap mulva jovok az uj zarral, mert addig tesztelem. Es azalatt a ket honap alatt mi a francot csinaljak?

Sajnos a Java nem egy cserelheto valami, amit kidobok ha hibas.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ez olyan, mintha egy lakatos ingyen osztogatna - nyilván nem azért mert a Máltai Szeretszolgálat, hanem mögöttes szándékkal (az Oracle se jószívből terjeszti a Java-t) - egy általa csinált zárt, ami beszart, neked meg olyan állapotban van az ajtód emiatt, hogy a rosszindulatú betörő megrúgja a sarkát, az meg kinyílik. És sajnos a betörő azzal tisztában is van, hogy a lakatos ezen zárjaival probléma van. Közben a lakatos azt mondja, hogy csak akkor megy hozzád javítani idő előtt, ha fizetsz, vagy kivárod, amíg hajlandó veled 2 hónap múlva foglalkozni.

Ez morálisan a lakatosnak kellemetlen kellene, hogy legyen.

--
trey @ gépház

Vannak cégek, akiket érdekel az ügyfelek megelégedése. Jómagam is találkoztam már olyannal. Olyannal is találkoztam, aki saját belső használatra - nem marketing, nem parasztvakítás - méri az ügyfélmegelégedést és próbálja azt minél magasabb szinten tartani.

Az ilyen hozzáállás ezen nem segít. Meg az ilyen se.

--
trey @ gépház

Az Oracle jelenlegi koncepciójától a lehető legtávolabb áll minden olyasmi, ami az ügyfél kívánságainak a figyelembevételét jelentené. Mondhatni policy, hogy leszarjuk az ügyfelet: van egy halom pótolhatatlan monopol-jellegű termékünk, ha valakinek kell, leszurkolja szépen azt a zsetont, amit kérünk érte, mindenki más meg le van ejtve.

Mivel ez a stratégia túl látványosan működik a monopoltermékeknél, így sajnos arra jutott a cég vezetése, hogy ez így van jól, hiszen bizonyította magát az elmélet. Ezután a nem monopoltermékeknél is pont ugyanezt a koncepciót működteti a cég. Ez pedig tökéletes stratégia a nullához közelítő eladások eléréséhez.

Ha a dologba "morális" kérdéseket próbálna valaki keverni, nagyon hamar a cég jelenlegi jólétét jelentő stratégiával kerülne összeütközésbe...

Én morális dolgokat is keverek. Nekem sikerül jól elkerülni őket és volt már rá példa, hogy beszerzésnél az ügyfél "Sun" vasat akart, de lebeszéltem róla. Éppen ezért nem mondanám, hogy biztosan ez nem működik.

Nyilván az Oracle leszarja, hogy azt a néhány ügyfelet elveszítette. Viszont én meg nem ajánlok jó szívvel olyan céget, ami megkérdőjelezhetően viselkedik a piacon. Egyrészt mert, az ügyfél elégedettsége nekem is fontos, másrészt én sem vagyok a magam ellensége. Lásd: firmware pénzért. A világ vicce.

--
trey @ gépház

Tipikusan az a hiba, amit nem pénzért kéne javítani. Ez zsarolás. Az, hogy egy funkcióbővítést egy programozó pénzért ad, az elfogadható. Ezek szerint az is duma, hogy idő kell a teszteléshez, hiszen a javítás pénzért már előbb elérhető.

Mondjuk az Oracle-től, aki a saját szervereihez a firmware frissítést - amiben többnyire az általuk elkövetett hibákat javítják - is pénzért adja, mi a faszt várjunk? Csoda, hogy az emberek elgondolkodnak arról, hogy ez a szoftverfejlesztés egy romlott valami?

--
trey @ gépház

Teljesen komolyan gondolom, illetve azt is, hogy nyilván nem a programozókat kell megkérdezni arról, hogy akarnak-e a kifogásolhatóan végzett munkájuk után számonkérést, mert a válasz egyértelműen "nem" lesz. Ezzel semmi baj, értem én, hogy senki sem a saját maga ellensége. Mindenesetre szórakoztató a kapálózás ;)

--
trey @ gépház

"akarnak-e a kifogásolhatóan végzett munkájuk után számonkérést, mert a válasz egyértelműen "nem" lesz"

Speciel egy szóval sem mondtam, hogy nem kell felelősségre vonni, (ismételten megjegyzem: jobb helyeken történik olyan is mifelénk, maximum te mást tapasztaltál a Szintézisnél, mittudomén).

Azonban mai napig nem kaptam választ, hogy mégis miféle felelősségre vonást vársz el, helyette csak hebegés-habogás volt meg terelés.

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

Mint ami minden normális helyen történik: szart csinálnék, kereshetnék másik munkahelyet. És ugyanúgy van számonkérés, hogy mit miért csinálok. Ha meg valami gixer van a rendszerben, jellemzően amúgy is nálam csörög a telefon, maximum FWD-zve lesz.

"Mi lenne, ha a gagyi személyeskedésedet félretennéd?"

Nagyon már nem tudtam mit reagálni arra, hogy szerinted nincs számonkérés, gondoltam hátha így megy nálatok, aztán innen ez a fene nagy "tapasztalat".

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

Igen, mint ahogy lehetett ellened is akkor, amikor valakinek összetörted az autóját. Csak az élet azt mutatta meg, hogy volt olyan nem is kevés eset, amikor nem volt mit elperelni (szépen el volt rejtve). Vagy évekig ment egy-egy per. Ki is találták a kötelező felelősségbiztosítást izibe'.

Egyébként hozzáteszem, a programozószakma megtisztulását is hozná valami olyan intézkedés, ami biztosítaná az ügyfelet, hogy a pók munkájáért valaki/valami kártérít. A programozók által gyakran emlegetett Pistikék feltehetően nem áldoznának ilyesmire.

Mielőtt jön a szar szöveg, igen, ilyesmi üzemeltetői oldalon is értelmes lehetne. Elvégre nem szarral gurigázunk, ezekben a szakmákban milliókkal, akár milliárdokkal játszunk.

--
trey @ gépház

Igen, mint ahogy lehetett ellened is akkor, amikor valakinek összetörted az autóját. Csak az élet azt mutatta meg, hogy volt olyan nem is kevés eset, amikor nem volt mit elperelni (szépen el volt rejtve). Vagy évekig ment egy-egy per. Ki is találták a kötelező felelősségbiztosítást izibe'.

Igen, de ehhez kellett az is, hogy valakik elkezdjenek perelgetni. Ha csak forumon huszarkodnak a rendszergazdak/uzemeltetok akkor nem fog valtozni semmi.

Egyébként hozzáteszem, a programozószakma megtisztulását is hozná valami olyan intézkedés, ami biztosítaná az ügyfelet, hogy a pók munkájáért valaki/valami kártérít. A programozók által gyakran emlegetett Pistikék feltehetően nem áldoznának ilyesmire.

Egyetertek, egy ilyen rendszer mukodhetne, de akkor ez is "kötelező felelősségbiztosítás" legyen. Ne legyen kibuvo/kiskapu hogy "dehat benne van a licencben" (lasd osszes OSS licence), vagy kizarja az EULA(ilyet is biztos lattal mar). Legyen kotelezo, es legyen meg minden bugnak a felelose.

A felelőségbiztosításra reagálnék.
Magyarországon nem nagyon lehet programozási tevékenységre felelőségbiztosítást kötni. (Ha valaki tudja, melyik biztosítónál lehet, milyen feltételekkel, ne tartsa magában.)
Évekkel ezelőtt több hónapnyi biztosítókkal/ügyvédekkel történő beszélgetés/levelezés vége az lett, hogy egyik biztosító sem vállalja, mert nem tudnak kockázatelemzést végezni a tevékenységre. (Vicces módon arra van biztosítás, hogyha az ügyfelünk a szoftverünket használva harmadik félnek testi sérülést okoz. pl. szoftverünk behatására a monitor ráesik az ügyfelünk ügyfelének a lábára)
Megsaccolni se tudják, hogy mekkora kár keletkezhet, egy esetleges "hibás" kód eredményeként. Illetve, hogy szinte lehetetlen megtalálni, hogy ténylegesen ki a felelős a kár bekövetkeztéért, a fejlesztő, a user, vagy hardver, vagy stb. Egyértelmű javaslat a következő volt: ki kell kötni, hogy nincs felelőség.

Egyfelől, igaz, hogy a szoftverrel okozott kár nem lineáris függvénye semminek.
Ugyanúgy néz ki az a bug, amitől leáll egy életfenntartó gép, mint amitől rosszul formázva ír ki egy számot a gép. Persze az előbbi rendszert illik jobban tesztelni, de a hiba bekerülése ugyanolyan valószínű.

Másfelől, lehetne olyan biztosítási konstrukció, ahol a díj attól függ, milyen a gyártó cég minőségbiztosítása, tehát pl. a tesztelés minősége.
(Nem mondom, hogy ez könnyű lenne, mert a programozók minőségét is kéne mérni, ami talán még nehezebb....)
De ez csak célszoftverre igaz.
Általánosan használható platformokra, amilyen a Java is, nem lehet ilyet egységesen ráhúzni.

A cégek minőségbiztosítására sok-sok éve bevett szabványok vannak, szokták auditálni meg minden. Tehát ezen pl el lehetne indulni. Kérdés, Magyarországon pl hány sufninál magasabbra auditált cég van (nem tippelnék többre egy tucatnál, de lehet sokat mondtam).
----
India delenda est.
Hülye pelikán

Nem lehet hogy érdemesebb lenne a tesztelés felől megközelíteni a kérdést? Ha lenne egy független komoly tesztelést végző cég, akik adnák a nevüket az általuk bevizsgált / tesztelt szoftverhez pénzért, akkor a fejlesztő cég oda tudná tenni a termékük mellé az auditálást végző cég certifikációját, amely az értékét / minőségét emelné - és ha nem sufni cuccokról van szó, akkor megérhetné kifizetni az audit költséget.

Ha az ISO-ra gondolsz, az csak annyit mond, hogy mindent meghatározott folyamatok szerint végzel. Ez nem jelenti azt, hogy te jó terméket csinálsz,
vagy rosszat, viszont azt, hogy mindent ugyanúgy... ezt a legtöbb komoly sw fejlesztő cég megcsináltatja, mert a customer-ek igénylik, valójában
a sw fejlesztő életét szinte semmiben sem határozza meg...

Vesd össze: "mindent a folyamatok szerint végzel" és "a sw fejlesztő életét szinte semmiben sem határozza meg"
Szerintem ütközik. A szabványok előírják, hogy hogy állítsad elő a terméket. Úgy határozták meg, hogy ha te úgy csinálod, akkor jó lesz a termék.
Mivel a termék minőségét szinte lehetetlen mérni, ez marad.
----
India delenda est.
Hülye pelikán

Alap minőségügyi definíció: minőség az, amit a vevő annak tart.
A minőségbiztosítás azt jelenti, hogy ezt a vevő által fontosnak tartott minőséget mindig ugyanúgy, egyenletesen elő tudjuk-e állítani.
Pl. a McDonald's a minőségbiztosítás királya: akárhová mész a Földön, mindenhol ugyanazt kapod.
Egyáltalán nem arról szól a minőségbiztosítás, hogy az eredménnyel mindenki elégedett vagy éppen arról, hogy az előálló termék (szoftver, étel, ceruza, számítógép) különösebben megütne valamiféle értékmérő szerinti "jó, minőségi" mércét.
A szabványok azt írják elő (mondjuk pl. DO-178B), hogy mi az a minőségdefiníció, aminek minden termékelőállító meg kell feleljen. Ettől függetlenül ez a definíció, lehet hogy nem ér semmit (pl. HTML "szabványok"), míg más esetekben eléggé komoly műszaki feltételeket szab. De ettől függetlenül a minőségbiztosítás nem jelenti azt, hogy "jó" legyen a terméked. Nem erről szól.

Nem ezt írtad.
"Úgy határozták meg, hogy ha te úgy csinálod, akkor jó lesz a termék.
Mivel a termék minőségét szinte lehetetlen mérni, ez marad."
Ezek szerint mégis lehet mérni a termék minőségét: mekkora mértékben felel meg a kritériumoknak. Valamint a minőségmenedzsment nem azt mondja, hogy ha te úgy csinálod, akkor JÓ lesz a termék, hanem azt mondja, ha te úgy csinálod, akkor egyenletes minőséget állítasz elő. A minőségmenedzsment egyáltalán nem arról szól, hogy valamiféle külső kritériumoknak megfeleljen a TERMÉKED, arról szól, hogy külső kritériumoknak megfeleljen a termék előállítás FOLYAMATA. A folyamat megfelelősége még nem garantálja a termék megfelelőségét. Egyáltalán nem.

Megfelel a kritériumoknak az NEM azt jelenti, hogy azt lehet mérni.
Másfelől a KÖZVETLEN célja a minőségbiztosításnak az, hogy a folyamat jó legyen. De NYÍLVÁNVALÓAN a közvetett célja a termék xy tulajdonságainak a biztosítása. Önmaga a folyamat nem érdekelne senkit, ha nem lenne termék a végén.
----
India delenda est.
Hülye pelikán

ha van egy kritériumod, amely előírások halmaza, akkor igenis könnyen lehet mérni, hogy abból a halmazból hány elemet teljesít a termék. q = (teljesített előírások száma) / (összes előírások száma).
Ebből a megfelelőséget akár lehet így is mérni:
(teljesített kötelező előírások száma) / (összes kötelező előírás száma), mivel a legtöbb szabványban vannak opcionálisan teljesíthető kritériumok.

Gondolj bele, a minőség mérése itt a megfelelőség mérése (ugyanis a te definíciód szerint minőség = megfelelőség). Ha nem tudnál megfelelőséget valamilyen módon mérni, akkor nem tudnád azt se eldönteni, hogy a megfelelőség fennáll-e vagy nem.
a kritériumnak való megfelelést általában egy tesztsorozattal ellenőrzik. Egyszerűen mérhető, hogy ennek a tesztsorozatnak hány elemére ment át a rendszered és hányra nem. Ez mérés.
Ha szerinted a szoftver minősége (kritériumnak való megfelelősége) nem mérhető, akkor maga a kritérium értelmetlen.

#define jo. Mert ez az egesznek a lenyege.

Attol, hogy a FOLYAMAT jo, az nem garantalja, hogy jo TERMEK lesz a vege. Csak azt, hogy vagy ugyanolyan jo vagy ugyanolyan szar termek jon ki a folyamatbol MINDIG.

Es egyebkent, honnan lehet tudni, hogy a termek folyamat altal meghatarozott tulajdonsagai egyebkent jok? Mert errol maga a folyamat biztositasa nem szol, nem garantalja. Peldaul az, hogy a levesbe sosem teszek egy meghatarozott mennyisegnel tobb sot, az egyaltalan nem garantalja azt, hogy a vegen nem lesz sotlan a levesem. Mert ha pl. a recept fejlesztese soran kerul bele burgonya, az felveszi a sot, es maris sotlanna valik a leves, mert keves a folyamat biztositasa soran megallapitott somennyiseg. De ez csak egy pelda, annak is santa.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A szoftverfejlesztés FOLYAMATÁRA van az ISO/IEC 90003, de ez csak arra vonatkozik, hogy a fejlesztési folyamatod szervezése megfelel-e bizonyos feltételeknek, de nyilván nem garantálja, hogy a képződő szoftvered bármilyen kritériumnak megfelel. A quality control az a folyamatok szabályozásáról szól, nem a termékek megfelelőségéről. Az a quality assurance.

BTW, ha lenne torveny arra hogy a fejleszto cegnek vallalnia kell a felelosseget a karokert akkor nyilvan belelenne ez kalkulalva az arba es dragabban vennetek a programokat. Tehat csak annyit kell tenni, hogy most is meg kell keresni azokat a fejlesztoket akik hajlandoak vallalni a felelosseget es tolok venni/veluk fejlesztetni.

Ha a fonokeid nem hajlandoak kifizetni a plusz penzt, akkor biztos hogy (csak) a fejlesztok hibaja az, ha a klienseknek eleg a jelenlegi allapot is?

Miután EV, nyilván ő tartja a hátát mindenért, mintha cég lenne, Azt hogy hogyan milyen mértékig, azt meg a szerződésben ugye illik lefektetni. (Nyilván aki okosba' akarja megoldani, az saját magával tol ki.) Viszont egy egyszemélyes magánhadseregtől te ne várj akkora sokrétű tudást, mint mondjuk egy vállalattól.

De nem értem a problémát. Ügyfélnek panasza van -> megy a számonkérés a beszállítónál, értelem szerűen annál, aki képviseli a beszállítót számára.

Ilyen esetekben, ahol még nagyon sokan mások vesznek részt a projektben, nem tudom miért csak és kizárólag a programozót akarod előcibálni. A programozó csak egy eléggé köztes lépcsőfok a folyamatban. Van előtte és mögötte is bőven ember. Azt sem tudom, hogy miért nekem kellene, főleg anyagi felelősséget vállalnom mindenért. Legtöbb esetben nem vállalkozó a programozó, hanem alkalmazott. Arra szerződik, hogy a saját munkáját a tőle telhető legjobb tudás szerint elvégezze, ami pedig szoftverek írása (a tervek és specifikációk alapján) és nem feltétlen biztonsági szakértés. Az egy külön szakma, megrendelő fizesse ki.

És amúgy szerintem itt eléggé félreértjük egymást: szóval nem mondom, hogy nem kell felelősséget vállalni. De kell, mindenkinek a maga szintjén (ami most is működik). Amivel marhára nem értek egyet, hogy minden szarért, húgyért a programozót rángassuk elő.

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

Egyébként eléggé szar helyen van a hiba (http://wiki.javaforum.hu/pages/viewpage.action?pageId=28442766), amelynek a javításának átgondolása után még jópár tesztet le kellene futtatni, hogy van-e regressziós hatása más területeken vagy alkalmazások esetén, és csak utána lehet kiadni egy javítást... aztán még így is előfordulhat, hogy fejre áll a javítástól egy olyan szoftver, amelyet nem az ajánlásoknak megfelelően írtak meg.

Ha elkezd valami kártevő terjedni, akkor nyilván lesz patch, ha pedig szarnak rá a rosszarcúak, mert van n+1 egyéb sebezhetőség a támadandó gépeken, akkor később lesz patch.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( Zahy v | 2012. 08. 27., h – 22:58 )

Jaj de jo, Operat kell hasznalni, es mar jok is vagyunk :-)

<troll>Biztos azon nem megy a Java alapból</troll>
Gondolom mert az első linken nem volt felsorolva. Ami egyébként csak annyit jelent, hogy nem számít a cikkírók szerint mainstream böngészőnek. (Ahogy a Safari sem.)

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

( zrubi v | 2012. 08. 28., k – 07:29 )

A javaslat: a probléma súlyos problémaként kezelése és a Java teljes letiltása a javítás megérkezéséig

Tehát addig ne használjunk IP konzolt, ne konfiguráljunk Blade-eket, Storage-eket, ne használjunk internetbankot???

El is megyek szabira inkább :P

Még jó hogy nincs december, mert akkor a java mikulást is ki kellene hagyni ;)

--
zrubi.hu

Igényelni nem igényli, de :

# yum list |grep jdk
java-1.7.0-openjdk.x86_64 1:1.7.0.5-2.2.1.fc17.9 @updates
java-1.7.0-openjdk.i686 1:1.7.0.5-2.2.1.fc17.9 updates
java-1.7.0-openjdk-demo.x86_64 1:1.7.0.5-2.2.1.fc17.9 updates
java-1.7.0-openjdk-devel.i686 1:1.7.0.3-2.1.fc17.6 fedora
java-1.7.0-openjdk-devel.x86_64 1:1.7.0.5-2.2.1.fc17.9 updates
java-1.7.0-openjdk-javadoc.noarch 1:1.7.0.5-2.2.1.fc17.9 updates
java-1.7.0-openjdk-src.x86_64 1:1.7.0.5-2.2.1.fc17.9 updates

gondolom ezek is érintettek...

Nem állok neki lehegeszteni ezeket, és felhegeszteni valamelyik régebbit.

--
zrubi.hu

Van RHEL 6.3-ban is 7-es Java. Az alábbi a (szerintem) legutolsó 7-es openjdk (java-1.7.0-openjdk-1.7.0.5-2.2.1.el6_3.i686.rpm) changelogja.

2012-06-14 12:00:00
jiri Vanek - 1.7.0.3-2.2.1.el6:
- Used newly prepared tarball with security fixes
- Bump to icedtea7-forest-2.2.1
- _mandir/man1/jcmd-name.1 added to alternatives
- Updated rhino.patch
- Updated java-1.7.0-openjdk-java-access-bridge-security.patch
- Modified partially upstreamed patch302 - systemtap.patch
- Temporarly disabled patch102 - java-1.7.0-openjdk-size_t.patch
- Removed already upstreamed patches 104,108,109,301,110:
- java-1.7.0-openjdk-arm-ftbfs.patch
- java-1.7.0-openjdk-system-zlib.patch
- java-1.7.0-openjdk-remove-mimpure-opt.patch
- systemtap-alloc-size-workaround.patch
- java-1.7.0-fix-gio-detection.patch
- Access gnome bridge jar forced to be 644
- Added patch303 - java-1.7.0-openjdk-jstack.patch which resolved RH804632 for openjdk6
- Resolves: rhbz#828759

De az Oracle féle se különb.(java-1.7.0-oracle-1.7.0.5-1jpp.1.el6.i686.rpm)

2012-06-13 12:00:00
Jiri Vanek - 1:1.7.0.5-1jpp.1:
- automatic update by JavaRpmUpdater 1.3
- buildver changed from 4 to 5
- Release: changed from 1jpp.2dist to 1jpp.1dist
- Resolves: rhbz#828757

Viszont az is tény, hogy elérhető nem csak a 7-es java hanem a 6-os is. Még egy apró kiegészítés, FC17 nem létezik, hivatalosan az F17. Fedora 7-től már nincs ott a "Core" szó a név mögött.

Pl. az Ubuntu 12.04-ben levő cucc AFAIK Java 6 SE Update X.

A Java 6 nem érintett. Szerintem csak akkor vagy érintett, ha leszedted az openjdk-*-ot, és kézzel feltelepítetted az Oracle-től (vagy máshonnan) letöltött Java 7-et. FIXME.

Szerk: van openjdk-7-* is. Akkor elképzelhető, hogy akinek az van telepítve, az érintett.

--
trey @ gépház

Ez sajnos csak ott nem működik, ahol komolyan használják. Sajnos sok helyen elő van írva, hogy nekik _csak_ a java 1.6.0.2.3.b-2 verzió felel meg. Persze ezt most jól jön, de ahol épp 1.7-es javához ragaszkodnak, ott esetleg most nagyon komor arccal üldögélnek a managerek. Még akkor is, ha már van valamiféle 3rd party hegesztés a cucchoz, amit viszont épp azért nem lehet feltenni egy komoly helyen, mert 3rd party :D

( sz332 v | 2012. 08. 28., k – 11:39 )

Oké, arról van szó, hogy lehetséges olyan applet-et írni, ami ki tud törni a sandbox-ból, és elindít a gépeden egy tetszőleges programot.

Megoldás: tiltsd le a java applet támogatást a böngésződben.

A standard java alkalmazásokat nem érinti ha jól látom, mert abból bármikor
tudtál alkalmazást indítani.

Patch: http://www.deependresearch.org/2012/08/java-7-0-day-vulnerability-infor… itt elérhető egy javítás, amivel ez a bug fixálva van,
bár nem hivatalos, de érdemes felrakni...

+1
az exploit annyit csinál hogy aplpetből elindítja a calc.exe-t. Egy nem appletként futó java program ezt bármikor megtehetné amúgy is, szóval ha az ember leltiltja az appleteket a böngészőben akkor máris nincs semmi gond.

Lehet abbahagyni a rinyálást -.-

--
CyclonePHP

( kubi | 2012. 08. 28., k – 14:27 )

Egyszer mar csak abbahagyjuk ezt a java dolgot.

Minden felnott ferfinek lehet egy alma...

Mármint a futtatókörnyezettel. Másnál nem is nagyon lehet ilyen hibád mert nincs is lehetőség böngészőben futtatni. A Java-nak van egy jó sandboxing megoldása, ami helyesen implementálva véd az ilyenektől. Hiába csinálnál valami mást a Java helyett, ha azonos szintű funkcionalitást akarsz biztosítani, akkor ott is meglenne az ilyen hibák lehetősége.

A futtató környezeten a JRE-t ill. a java plugint érted, gondolom. Azt maga a fő vendor implementálta. Azon kívül meg kb. az openjdk van, de arra meg sok a teljesítménypanasz.

Nem vagyok biztos benne, hogy ha kiküszöbölnék a letöltött binárisok futtatását (dedikált és védett végrehajtható ill. bytecode memória, index ellenőrzés, stb.) az mennyiben korlátozná a funkcionalitást. Feltételezném, hogy meg lehetne oldani.

Van :)
Tipp: googlizz erre: openjdk vs sun jdk

- Nem működik vele minden, http://theaccidentalcoder.com/content/swapping-openjdk-sun-jdk-ubuntu

- Használhatatlanul lassú, főleg a grafika, tipikusan Eclipse, http://askubuntu.com/questions/61558/whats-the-difference-between-openj…
"Suns JDK is much faster for many applications using advanced graphic capabilities (2d and 3d), to the point that some applications are actually not usable using openjdk. "

"Nem működik vele minden, http://theaccidentalcoder.com/content/swapping-openjdk-sun-jdk-ubuntu"

Tudjuk, hogy nem működik vele minden, főleg azok a programok, amelyek kinyúltak a JDK dokumentált funkcióinak a határain... de az undocumented featureset használata nem jelent jót az álmoskönyv szerin, Java esetén legtöbb esetben például com.sun.* vagy sun.* osztályok használatát jelentette, amelyek bármikor kikerülhettek a JDK-ból. Soha egyik keretrendszer vendor se támogatta és nem garantálta a megfelelő működést undocumented feature használatánál.

"Használhatatlanul lassú, főleg a grafika, tipikusan Eclipse"

Az Eclipse speciel SWT, ami nem natív Java, hanem C-ben megírt grafikus magra épül és pont ezért vannak vele gondok... továbbá ezért nincs gond a megfelelően megírt natív Java GUI-ra épülő programokkal...

Értem én, hogy nagyon szeretnél fogást találni a Java-n, de akkor nézz utána annak, hogy mi hogy működik... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Értem én, hogy nagyon szeretnél fogást találni a Java-n, de akkor nézz utána annak, hogy mi hogy működik... :)

A netbeans GUI ablakom egy keresés közben most épp 5 perce nem frissül, kimázoltam az egészet szürkére.
A java bináris letöltés-végrehajtás exploitok rendszeresen előforulnak.
Szóval ne akarj meggyőzni róla, hogy nem találtam fogást a javán.

Az a Java hibája, ha az előírásokat megszegve (SwingWorker használata) az UI Threadben csinál valamit a Netbeans? Programozói hiba. Ugyanúgy, mint amikor UI threadben dolgozol C#-pos, C-s alkalmazásban, független ez a technológiától, onnan ered ez a dolog, hogy a UI mindenképpen egyszálú (alkalmazásonként egy event dispatch thread van), függetlenül attól, milyen ablakozó rendszert használsz. Sehol nem tudták hatékonyan megoldani ezt, lásd bővebben itt:
http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
http://msdn.microsoft.com/en-us/library/ms741870.aspx
http://doc.qt.nokia.com/4.7-snapshot/thread-basics.html

Nem a Javan találtál fogást, hanem siekrült beazonosítanod egy szarul megírt programot, amit éppenséggel Javaban írtak.
Ne csúsztass.

Az a Java hibája, ha az előírásokat megszegve (SwingWorker használata) az UI Threadben csinál valamit a Netbeans?

Nem ez történik, mert nagy néha van valami frissülés (percek!), hanem egy mammut, és úgy megeszi a memóriát, hogy fuldoklik alatta a gép.
Tehát ez szabályosan megírt java kód mellett fordul elő, és nem egyedi.

"Tehát ez szabályosan megírt java kód mellett fordul elő, és nem egyedi."

1, Ezt a forráskód ismeretében jelented ki, vagy a forráskód ismerete nélkül általánosítasz?
2, Ha találok hibásan működő C/C++ programot, akkor a C/C++ platform rossz vagy az adott program?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Tehát ha találok egy szarul megírt C programot, akkor meg tudunk egyezni abban, hogy szar a C? :)

"A java bináris letöltés-végrehajtás exploitok rendszeresen előforulnak."

Hát igen. Linux kernel exploitok is rendszeresen előfordulnak.

"Szóval ne akarj meggyőzni róla, hogy nem találtam fogást a javán."

Pedig nem a Java-n találtál. Ha úgy gondolod, hogy igen, akkor azzal a lendülettel a C-n is találtál fogást.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Azon kívül meg kb. az openjdk van, de arra meg sok a teljesítménypanasz.

Meg leginkább az, hogy random java-s programok nem mennek vele. Nincs kedvem nézegetni, hogy mi igen és mi nem.

Nem vagyok biztos benne, hogy ha kiküszöbölnék a letöltött binárisok futtatását (dedikált és védett végrehajtható ill. bytecode memória, index ellenőrzés, stb.) az mennyiben korlátozná a funkcionalitást. Feltételezném, hogy meg lehetne oldani.

Semmi akadálya nincs annak, hogy a browseredben ne legyen java támogatás (én pl. standard módon flash és java támogatás nélküli operát használok).

Semmi akadálya nincs annak, hogy a browseredben ne legyen java támogatás (én pl. standard módon flash és java támogatás nélküli operát használok).

De van, sajna sok rendszer (céges doksikezelő, ...) csak Javával működik. Nem lehet megúszni, csak akkor ne legyen önveszélyes mutatvány.

(Flash ellen meg flash blockert használok, mert néha a flash is kellhet. Te speciel hogy szoktál youtube-ot nézni flash nélkül ?)

"standard módon" = random site browse-olásához.

A youtube (meg más hasonló cuccok) számára van egy firefox is a gépemen.
De az operában is csak egy kattintás visszakapcsolni a plugineket.

De van, sajna sok rendszer (céges doksikezelő, ...) csak Javával működik.

Akkor arra a célra másik browser. Rendes oprendszereken (lásd: Hungarian Unix Portal) annyi browsert használok, amennyit nekem jólesik.

Én is így teszek, ama okból, hogy a csodás javás doksikezelő firefox/seamonkey alatt nem megy, de chrome alatt igen.
Csak az a bibi, hogy a chrome a seamonkey által használt java plugint használja. Ha emezt letiltom, amazzal sem megy.

Meg aztán, ahány brózer, annyiszor fél v. 1 giga memória... nincs nekem annyi fölösleges RAM-om. (vagyis: mivel de facto külön brózereket használok, megeszi szépen a memóriámat.)

Persze, mert az nem virtuális gépen fut. Ott egy túlcímzést nem tudsz elcsípni. (bár már van CPU szintű executable memory support, tudtommal)

Viszont egy virtuális gépnek pont ez lenne a lényege. Ha már lassabb, akkor legalább legyen biztonságos. De nem az :((

A Java per def. virt. gépen fut, tehát ennyiből nyelv = jvm.

Van erről saját bizonyítékod ?
Ezt a mítoszt már én is hallottam, de saját tesztjeim (C-ben ill. Javaban implementálva ugyanaz a referencia algoritmus) 2-3-szoros C előnyt mutatott.
Amit én látok ebből:
A Java-s GUI-k még mindig azt művelik, amit rég, hogy memória elfogytán szemétgyűjtés, és akkor nem reagál pár másodpercig semmire. C GUI meg nem csinál ilyet.

"Ezt a mítoszt már én is hallottam, de saját tesztjeim (C-ben ill. Javaban implementálva ugyanaz a referencia algoritmus) 2-3-szoros C előnyt mutatott."

Lepörgettük már egyszer a hup-on is (http://hup.hu/cikkek/20090517/az_androidra_alapozza_a_jovot_az_amerikai…), és máshol is. Akkor mutat a referencia algoritmus előnyt C oldalon, ha C szerűen íródik meg Java nyelven is. Fortran programozó ugye minden nyelven képes Fortran programot írni...

"A Java-s GUI-k még mindig azt művelik, amit rég, hogy memória elfogytán szemétgyűjtés, és akkor nem reagál pár másodpercig semmire. C GUI meg nem csinál ilyet."

Nap-mint-nap használok Java GUI-t és nincs olyan, hogy nem reagál... milyen programról van szó?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Akkor mutat a referencia algoritmus előnyt C oldalon, ha C szerűen íródik meg Java nyelven is. Fortran programozó ugye minden nyelven képes Fortran programot írni...

1. Kiváncsi vagyok, egy FLAC kódoló referencia interface használata hogy tud annyira C-szerű gondolkodással készülni, hogy ez rontja a teljesítményt.

2. A tucat/tipikus java programozó vszleg C-szerűen gondolkodik. Akkor a tucat/tipikus java alkalmazás lassabb, mint uaz C-ben, nemde ?

Nap-mint-nap használok Java GUI-t és nincs olyan, hogy nem reagál... milyen programról van szó?

Oracle Solaris studio, avagy Netbeans. Fürge, mint egy bálna. C++-ban írt IDE-t még nem láttam ennyire lassúnak.

"Kiváncsi vagyok, egy FLAC kódoló referencia interface használata hogy tud annyira C-szerű gondolkodással készülni, hogy ez rontja a teljesítményt."

Forrás?

"A tucat/tipikus java programozó vszleg C-szerűen gondolkodik. Akkor a tucat/tipikus java alkalmazás lassabb, mint uaz C-ben, nemde ?"

Nem, kevés Java programozó gondolkodik C-szerűen, mivelhogy a C-t kevesebben "beszélik", mint a Java-t... :)

"Oracle Solaris studio, avagy Netbeans. Fürge, mint egy bálna. C++-ban írt IDE-t még nem láttam ennyire lassúnak."

Én NetBeans-t használok a 3.6 óta (lassan 10 éve) és messze nem tűnik bálnának... hasonló featureset-tel rendelkező IDE egyrészt nincs C++-ban, másrészt a C++ nem varázsszer, amely a programozóktól függetlenül hibátlan programot eredményez.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Nem, kevés Java programozó gondolkodik C-szerűen, mivelhogy a C-t kevesebben "beszélik", mint a Java-t... :)"

Jah, agybajt kapok, amikor friss "C++ programozók" MINDEN szart new-al akarnak létrehozni :D Nagyon átüt a C#/Java háttér.

"hasonló featureset-tel rendelkező IDE egyrészt nincs C++-ban"

Meglepődnék, ha a Visual Studiot nem C++-ban írták volna. Mi hiányzik belőle?
----
India delenda est.
Hülye pelikán

"Jah, agybajt kapok, amikor friss "C++ programozók" MINDEN szart new-al akarnak létrehozni :D Nagyon átüt a C#/Java háttér."

Jellemzően ezeket oktatják. Mondjuk sokszor sajnos hibás OOP alapokkal. :(

"Meglepődnék, ha a Visual Studiot nem C++-ban írták volna. Mi hiányzik belőle?"

Szerintem a Visual Studio nagyon-nagyon-nagy része már C#. Meglepődnék, ha C++ lenne.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Szerintem a Visual Studio nagyon-nagyon-nagy része már C#. Meglepődnék, ha C++ lenne."

UI-t a 2010-ben átírták WPF-re (.NET) - az amúgy igen jót tett neki - és egyre több része van menedzselt kód alatt. Ettől függetlenül még rengeteg natív kód dolgozik benne.

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

"UI-t a 2010-ben átírták WPF-re (.NET) - az amúgy igen jót tett neki - és egyre több része van menedzselt kód alatt. Ettől függetlenül még rengeteg natív kód dolgozik benne."

Akkor most van vagy nincs C++-ban megírt IDE szükséges featureset-el? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ez baromsag. Nagyban fugg attol, mennyi funkcionalitast hasznalsz, hany plugin van betoltve, mekkora fileok vannak betoltve (pl. 8 megas, 3 millio soros generalt kodok, vagy esetleg mas).

Nem lehet azt mondani, hogy "ennyi kell az eclipsenek". Egyrészt korlátozhatod a JVM számára elérhető memória méretét, és akkor aggresszív lesz a GC, másrészt előfordulhat OOME, de általában elmondani, hogy "ennyi kell az Eclipse-nek", nem lehet.
Eclipse RCP alapú alkalmazás rengeteg van (pl. Zend Studio, Apache Directory Studio, Spring Tool Suite), mindegyiknek más a szállított plugin-halmaza, a pluginok memóriahasználata.

Valamint természetesen a sok 3rd party plugin lehet memory leakes, de arról meg nem az Eclipse tehet.

Nem, egyáltalán nem kevés, meg ebbe nyilván beletartozik az is, hogy mi fut még mellette. (Amit sokan szeretnek elfelejteni pl. egy OS memóriaigényénél, hogy talán a programoknak is kell ram.)

Önmagában olyan 100-400M között, átlag 250-300M-al szokott menni nekem önmagában az Eclipse. Egyébként meglepően jól összerakott, annak ellenére, hogy Java-s és igazából a korábbi Java-s tapasztalataimat ez változtatta meg pozitívan. De azért átlagsebességre érezhetően lassabb, mint mondjuk egy VS2010 (igaz, annak is vannak nagyon trágya részei.)

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

Egyrészt: http://shootout.alioth.debian.org/u64q/which-programming-languages-are-…
Eszerint kb. 58% a kbség sebességben, nem 2-3 szoros.

Másrészt van pauseless garbage collector, valamint amikor malloc()-ot használsz meg free()-t az is szép szüneteket tud okozni, főleg mivel sok malloc() implementáció lassú.

Másrészt JVM-hez is érteni kell, ugyanúgy, ahogy C-hez is. MIndegyikben lehet szar, és mindegyikben lehet jó programot írni.

"Másrészt JVM-hez is érteni kell, ugyanúgy, ahogy C-hez is. MIndegyikben lehet szar, és mindegyikben lehet jó programot írni."

A JVM-nek kb. 600 paramétere van, amelyek egy része jelentősen befolyásolja a működésmódját a futó programnak.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( trey | 2012. 08. 30., cs – 15:36 )

Oracle knew about critical Java flaws since April

Legalább annyit ugathattak volna, hogy "figyi, ugyan javítás nincs, de figyelj már jobban, mert benézhet a ló az ablakon".

0day kering a világban, de a cégtől még egy figyelmeztetés sem érkezett. Vagy lemaradtam valamiről?

--
trey @ gépház