Hlavní navigace

Web MySQL.com byl hacknut

Sdílet

Pavel Stěhule 28. 3. 2011

Oficiální web MySQL.com byl hacknut pomocí SQL injection. Použita byla zákaznická aplikace, která umožnila útočníkům skrze chybu získat kompletní databázi uživatelů včetně hesel. Hesla byla zveřejněna a už se začalo s jejich prolamováním, které odhalilo slabé čtyřznakové heslo produktového ředitele MySQL.

Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 29. 3. 2011 7:42

    Lenin POWER!

    Kvalita LAMP aplikaci podle toho co nam sem lidi nosi je velmi velmi mala.

    1. SQL injekce - velmi bezne, semtam nejake addslashes pripadne mysql_escape_strin­g. Spis ale vyjimka nez pravidlo.

    2. Parametrizovany prepared statement jsem nikde nevidel

    3. Nepouzivaji transakce

    4. Neosetruji chybove stavy s vyjimkou mysql_connect. Ostatne k cemu osetrovat chyby kdyz pri chybe nemuzeme udelat rollback

    5. Zamykani nevedou vubec

    6. Referencni integrita obcas pouzita je

    7. Pouziti sablon se uz docela rozmohlo. Doba echo "<h1>"; uz skoncila

    8. Cela aplikace je hrozne zprasena, pouziti objektu minimalni. Vse se rve do globalnich promennych.

    9. Prace se zadava jako LAMP aplikace, protoze je na to ultralevna pracovni sila. Bezne se najme tak 3x vic levnych lidi {cinani, indove, rozvojove zeme} nez je potreba a doufa se ze to alespon nekteri z nich uspesne dokonci. Ovsem stejne jako vsude tak i zde plati dostanete to za co jste si zaplatili. Pocita se ovsem s tim ze zakaznik spatnou aplikaci od dobre nepozna a tak je mu to jedno.
    --
    Prekvapilo mne ze crackli tohle - "grankulla".

  • 29. 3. 2011 8:04

    Murděj Ukrutrný

    Zase jeden chytrák, nebo trol? Já používám LAMP i .net, dobře i špatně napsané aplikace se dá narazit u .netu i lampu, nezáleží na aplikaci ale na programátorech.

    Lamp levnější proto že je méně náročnější na systémové prostředky a není potřeba kupovat licence na widle. A z mého pohledu se rychleji vyvíjí v PHP s nějakým slušným frameworkem než v .net.

  • 29. 3. 2011 19:20

    Lenin POWER!

    lamp je nenarocny na systemove zdroje jenom u lowend webu, kterych je vetsina. U high trafik tam jasne vede java se Spring MVC. Jednak je potreba vyrazne mene CPU a pokud soucasny pocet pripojenych uzivatelu se pocita na stovky tak to vyjde levneji i pametove nez php do apache.

    Mam zalozeny tenhle odkaz

    http://grails.1312388.n4.nabble.com/Symfony-2-0-vs-Grails-benchmark-td3094892.html

    Grails == SpringMVC + Hibernate + Groovy.

    Grails framework bych vylozene doporucil zacatecnikum. Ma hezky integrovany maven2, ivy2, tomcat6, hibernate a je pro to mnoho pluginu coz skriptari oceni. Osobne se mi libi integrace springcache kde pomoci @Anotaci staci oznacit ktere metody chceme cachovat a po kterych chceme cache smazat a mame vystarano.

    Ja vim ze mate radi nette, ale to umi toho velmi velmi malo ve srovnani s opravdovym frameworkem jako Springy nebo Railsy. Grailsy muzeme pro jednoduchost povazovat za user friendly nadstavbu pro Springy kde mate porad moznost volat springy primo, kdyz potrebujete neco co grailsy specielne nezpristupnuji.

  • 29. 3. 2011 8:16

    Zopper

    1) Pokud nějaký SQL jazyk umožňuje víc než jen "namísto X dosaďte hodnotu", tak existuje možnost injekcí. To, že je spousta lidí zapomene ošetřit je problém programátorů, nikoliv jazyka/platformy.

    3) Transakce MySQL umí (byť je otázka, na jaké úrovni oproti třeba ORACLE).

    4) Tohle opět záleží na programátorovi, možnosti k tomu rozhodně jsou.

    8) Opět záleží na programátorovi, doporučuji se podívat třeba na Nette framework.

    9) Pokud někdo chce osekat náklady, tak si najme indy na cokoliv. Pokud někdo chce kvalitní aplikaci, zaplatí renomovaným vývojářům.

    Mě to přijde jako typický začátek flame "který jazyk je lepší" - neexistují lepší či horší jazyky. Existují jen jazyky, které jsou pro danou úlohu vhodnější, či které mají rychlou křivku učení, ale to nedělá žádný jazyk lepším oproti jinému.

  • 29. 3. 2011 8:59

    karel (neregistrovaný) ---.net.upcbroadband.cz

    Jestli se používají transakce, záleží na použitém storage engine. Výchozí MyISAM je neumí, InnoDB umí. Ne všechny aplikace transakce potřebují a beztransakční starage engine by měl být z principu rychlejší.

  • 30. 3. 2011 2:24

    Lenin POWER!

    Transakce innodb nemusi nutne zpomalovat, pokud pristupuje do tabulky vice uzivatelu soucasne tak zamykani zaznamu je lepsi nez zamykani cele tabulky jako to dela myisam. Je tedy pravda ze na zamykani zaznamu se nepotrebuji transakce. FoxPro taky umelo zamykat zaznamy a nemelo transakce. To co zpomaluje pri transakcich je flush logfilu na disk po zapisu do tabulky a checkpointy. MySQL u flush logfile podvadi (volitelne dela ho jen 1x za sekundu), coz zvedne vykon ale zase ne tak moc, protoze to flushovani logu je v mysql spatne udelane. PGSQL, ORA ci DB2 ho maji vyrazne s mensi rezii.

    MySQL umi MVCC v innodb engine coz je vyborne pro pristup vice uzivatelu soucasne. Jako obvykle funcionalita je trochu zabugovana. Nevim zda mysql dela lock eskalaci, oracle ne protoze nezamyka radky v pameti ale na disku po blocich / radkach.

    Navic mysql projde ACID testem u TPC-C, PostgreSQL 8.3 jim neprojde takze transakce jsou spravne implementovany. Problem je s vykonem a zabugovanosti. On ten innodb engine neni nejak specialne optimalizovany pro vykon u dlouhych transakci ma taky problemy, ale feature list ma standardni.

  • 30. 3. 2011 6:51

    Pavel Stěhule

    U PostgreSQL je úroveň SERIALIZABLE implementována příliš optimisticky - SELECT neblokuje UPDATE. Lépe se to chová při dlouhých transakcích. MySQL při SERIALIZABLE zamyká celé tabulky, což je podle novějšího chápání správně, ale je to pomalé. V 9.1 je úroveň SERIALIZABLE překopaná - bude to odpovídat tomu, co dělají ostatní databáze - což bude jednodušší pro Oraclisty, Hibernate a hlavně to projde ACID testem. Zase na druhou stranu, SERIALIZABLE bude náročnější - je to něco za něco. Problém je v různém chápání úrovně SERIALIZABLE ACID testu (zamykání a neexistence fantomů) a PostgreSQL (neexistence fantomů) - pg byl optimalizován pro slabší hw, přičemž v určitých několika málo situacích programátor musel explicitně zamykat. Od 9.1 si to o dost víc, ale programátoři nebudou muset řešit explicitní zamykání.

  • 29. 3. 2011 20:37

    xx (neregistrovaný) ---.orange.sk

    "1) Pokud nějaký SQL jazyk umožňuje víc než jen "namísto X dosaďte hodnotu", tak existuje možnost injekcí. To, že je spousta lidí zapomene ošetřit je problém programátorů, nikoliv jazyka/platformy."

    Prosim o test case, ktory podporuje vase tvrdenie, cize inymi slovami dokaz. Samozrejme podmienkou je pouzitie viazanych (bind) premennych.
    Pretoze dovolim si tvrdit, ze sa hlboko mylite.

  • 29. 3. 2011 8:50

    Pavel Stěhule

    Tak aspoň v něčem jsme lepší než v USA :)

    už jsem viděl pár perfektně napsaných aplikací i řadu slušně napsaných. I když to nebyl LAMP ale LAPP. Je to o programátorech, zaměstnavatelech a i o zákazních. SQL injection je tak hloupá chyba a lze se bránit s absolutní účinností, jen o tom programátoři neví :(. Na kurzech o SQL injection 1/3 programátorů netuší o co go.

    Není to jen o LAMP. To, co jsem zažil a viděl, a i sám dělal, když jsem ještě dělal ve VB nebo v ASP byl děs. Částečně omluvou bylo, že to bylo před rokem 2000 a že nikdo nic o SQL injection nevěděl.

  • 29. 3. 2011 22:49

    Lenin POWER!

    Na vas jsem si vzpomel. Delali jsme toto:

    Migrace z 800 Oracle instanci na neco co je zadarmo.

    10 uzivatelu na instanci, asi <1 GB dat na instanci. Velmi mala zatez. Jedna se o pobocku neceho kde uzaviraji smlouvy a pisi si je do databaze. Database musela podporovat inkrementalni backupy. Pres web to nechteli, boji se co by delali kdyby jim nesel net.

    Zvazovalo se:
    Oracle XE
    PGSQL 8.3
    DB2 Express C

    Oracle se vyradil protoze na nej nedavaji security fixy a je omezen na 4GB dat, PGSQL se vyradil protoze zakaznik nema duvery k supportu EDB {jeste o nem neslysel zadne reference}. tak to vyhrala DB2 ke ktery si uzavreli specializovanou servisni smlouvu s IBM.

    Vzpomel jsem si na vas. Kdybyjste si udelal firmu prodavajici PGSQL support (a pomoc s migraci) a poradne se zviditelnil a udelal si jmeno, coz neni tezke ja jsem to dokazal uplne od nuly, tak mi nerikejte ze byste zakazky nemel. Prezentovat umite, aktivni pristup k zivotu mate a organizacni schopnosti by se take nasly. Sice neumite myslet jako obchodnik, ale to ja neumel taky.

    Ja bych vam klidne prihodil tyhle maniky a obcas se mi tu nejaka prace v PGSQL mihne - obvykle je to export/import dat a migrace. Vetsinou ORA->PG. Jsou to dobry prachy. Ja jim uctuju $3k/rok support po 2 roky. To byjste klidne moh pro mne delat, vetsina problemu co maji je stejne HW razu nebo zavirovanych widli.

    Pokud se po PGSQL nechce OLAP tak ma vykon dostatecny. V OLAPu navic narazi na dementni JDBC driver, pravda MySQL ma jeste horsi JDBC driver. Jako backend pro hibernate je to dobry, jako backend pro BIRT ne, jsou tam nejak podivne delany cursory.

  • 29. 3. 2011 23:37

    Pavel Stěhule

    Tak, když nevěří supportu EDB, tak jak by mohli věřit mně? :)

    Firmu mám http://www.pgsql.cz/index.php/Slu%C5%BEby nicméně support 24x7 nenabízím - to je na jednu fyzickou osobu moc. Teď jsem dva roky dělal na baráku, dva roky makal abych to nějak poplatil, a teď bych si docela rád dal dva tři měsíce dovolenou - když to bude v létě možné. Mám před sebou ještě jeden větší projekt, a ještě nemám hotový postgraduál (a na katedře už na vytahují obočí), takže se nijak do ničeho nehrnu. Beru věci, které se dají zvládnout do týdne, případně dvou tří týdnů, nebo školení. Napřed musím pohnout s postgraduálem, a pak uvidím. Možnosti tu jsou - v republice je to tak tak na uživení, ale lze se přidat k několika menším firmám, které se pg věnují a pokrývají větší prostor. Teď to ovšem neřeším, musím dodělat, to co mám - a pak se uvidí. Kontakt na mne je na http://www.pgsql.cz/index.php/Pavel_St%C4%9Bhule.

  • 30. 3. 2011 10:36

    ja (neregistrovaný) 164.61.223.---

    no zkusil jsem klepnout na ten odkaz Kontakt: a obdrzel jsem nasledujici vystup:

    Warning: pg_query() [function.pg-query]: Query failed: ERROR: duplicate key value violates unique constraint "objectcache_ke­yname_key" DETAIL: Key (keyname)=(pgsql_w­iki:messages:cs) already exists. in /data/web/www­.postgres.cz/in­cludes/db/Data­basePostgres.php on line 58

    A database error has occurred
    Query: INSERT INTO objectcache (keyname,valu­e,exptime) VALUES ('pgsql_wiki:mes­sages:cs','..­......')
    Function: SqlBagOStuff::set
    Error: 1 ERROR: duplicate key value violates unique constraint "objectcache_ke­yname_key"
    DETAIL: Key (keyname)=(pgsql_w­iki:messages:cs) already exists.

    Backtrace:

    #0 /data/web/www­.postgres.cz/in­cludes/db/Data­base.php(538): DatabasePostgres->reportQueryE­rror('ERROR: duplica...', 1, 'INSERT INTO obj...', 'SqlBagOStuff::s­...', '')
    #1 /data/web/www­.postgres.cz/in­cludes/db/Data­basePostgres.php(850): DatabaseBase->query('INSERT INTO obj...', 'SqlBagOStuff::s­...', '')
    #2 /data/web/www­.postgres.cz/in­cludes/BagOStuf­f.php(293): DatabasePostgres->insert('objec­tcache', Array, 'SqlBagOStuff::s­...')
    #3 /data/web/www­.postgres.cz/in­cludes/Message­Cache.php(435): SqlBagOStuff->set('pgsql_w­iki:mess...', Array, 86400)
    #4 /data/web/www­.postgres.cz/in­cludes/Message­Cache.php(268): MessageCache->saveToCaches(A­rray, true, 'cs')
    #5 /data/web/www­.postgres.cz/in­cludes/Message­Cache.php(588): MessageCache->load('cs')
    #6 /data/web/www­.postgres.cz/in­cludes/Message­Cache.php(527): MessageCache->getMsgFromNa­mespace('Page­title', 'cs')
    #7 /data/web/www­.postgres.cz/in­cludes/Global­Functions.php(742): MessageCache->get('pagetitle', true, false)
    #8 /data/web/www­.postgres.cz/in­cludes/Global­Functions.php(707): wfMsgGetKey('pa­getitle', true, false, true)
    #9 /data/web/www­.postgres.cz/in­cludes/Global­Functions.php(613): wfMsgReal('pa­getitle', Array, true)
    #10 /data/web/www­.postgres.cz/in­cludes/Output­Page.php(480): wfMsg('pagetitle', 'Pavel St??hule')
    #11 /data/web/www­.postgres.cz/in­cludes/Article­.php(785): OutputPage->setPageTitle('Pa­vel St??hule')
    #12 /data/web/www­.postgres.cz/in­cludes/Wiki.php(493): Article->view()
    #13 /data/web/www­.postgres.cz/in­cludes/Wiki.php(70): MediaWiki->performAction(Ob­ject(OutputPa­ge), Object(Article), Object(Title), Object(User), Object(WebRequest))
    #14 /data/web/www­.postgres.cz/in­dex.php(117): MediaWiki->performReques­tForTitle(Objec­t(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
    #15 {main}

  • 30. 3. 2011 10:57

    Pavel Stěhule

    To se omlouvám - aktuálně si mediawiki nějak nerozumí s virtuálem na kterém to běží, občas to hodí tuhle chybu - stačí refresh stránky, a chyba zmizí. Během měsíce bychom snad měli přemigrovat a já doufám, že se tohoto problému zbavíme.

  • 30. 3. 2011 16:21

    Lenin POWER!

    tohleto je u lamp aplikaci bezny, proste race condition. V mysql maji mozna insert ignore, ale spis bych si tipnul ze zadne chybove hlasky od DB nezobraji. Proste nekdy nejaky sql prikaz neprojde, no a co.

  • 30. 3. 2011 17:48

    Pavel Stěhule

    Je to možné - objevilo se to při dočasné, náhlé a nutné migraci na virtuál, kde není k dispozici memcached. Takže je docela dost možné, že v kódu cache je chyba, ale taky je možné, že je wiki špatně nakonfigurovaná - přetáhli jsme images na jiný hw bez konfigurace. Prostě dočasné řešení, které je dočasné už asi půl roku :(. Nějak to funguje, ta chyba není až tak častá, a teď se CSPUG věnoval přípravě a zajištění P2D2 - takže wiki je trochu zanedbaná. Což se snad změní, máme hosting, máme určeného admina - teď to jenom přeinstalovat - a poskytnout tomu trochu něhy. Kdyby měli u wikipédie race condition, tak by si toho určitě rychle všimli :)

  • 30. 3. 2011 22:29

    Lenin POWER!

    Koukam mate velkou duveru v to ze v mediawiki nemuze byt chyba. On to nad pgsql provozuje malokdo a tym to nad pg ani netestuje. Kdyz prijdou 2 pozadavky na stejnou stranku rychle za sebou takto pak ta cache nezvladne.

    rekl bych ze typicka lamp aplikace bude delat select z cache - nenalezeno - insert do cache a urcite nebude pouzivat ani serializable ani transakce ani zamky. lamp aplikace jsou desny bastly, ty javovske jsou vyrazne lepsi tam si tyhle veci ohlida hibernate pomoci optimistickeho zamykani a programator na to nemusi vubec myslet.

  • 31. 3. 2011 7:44

    Pavel Stěhule

    Hibernate generuje zase jiné chyby - každý sw má chyby - ale o této chybě vím, kdy se začala objevovat a s čím souvisí - a spíš si myslím, že se jedná o chybu konfigurace - kterou nikdo neřeší, poněvadž celý systém budeme brzo reinstalovat. Samozřejmě, že se může jednat i o chybu v mediawiki, ale pak předpokládám, že bych to chybou netrpěla jen naše wiki - můžete mi věřit, že jsem moc podobná chybová hlášení pro daný kontext nenašel.

  • 31. 3. 2011 10:02

    Lenin POWER!

    To je tim ze ten server je pretizenej a casovy okno v kterem se ty zapisy do cache mohou srazit je vetsi. Vzdyt si to vyzkousejte, smazat cache a poslat 2 zadosti soucasne pomoci skriptu. No musite preknonat mysleni typu "Prece neni mozny aby se to projevovalo jen u mne, vzdyt to ma tolik instalaci".

    pgsql ma taky zavadejici chybove hlasky:

    crawler=# alter role export with unencrypted password 'readme';
    ALTER ROLE

    Mar 26 00:36:49 crawl2 postgres[4710]: [2-1] FATAL: password authentication failed for user "export"

    Proc se dohaje nemuze uzivatel prihlasit kdyz pise spravne heslo?

    Odpoved:

    crawler=# alter role export login;
    ALTER ROLE
    crawler=#

    To mi pripomina jak jsme zjistovali pul dne proc se nemuze jeden konkretni user prihlasit do db2 databaze a pak jsme zjistili ze db2 pam modul nepodporuje usernames delsi nez 8 znaku ackoliv AIX je umi.

    DB2 ma taky dobry chybovy hlasky ktery mohou v praxi znamenat ale uplne cokoliv, kuprikladu sql1086c. Oracle ten ma docela dobry chobovy hlaseni ackoliv zase ne vsechny ORA-XXXX jsou zdokumentovane. Kdo u Oraclu jeste nenarazil za nezdokumentovanou chybu tak toho nepovazuju za kvalitniho oracle admina s poradnou praxi. Nejlepsi je u oraclu to ze kdyz zmenite nejake parametry a db pak nenastartuje tak se velmi obtizne pak zpet. Nevim proc jsou ze zasady ORA a DB2 proti textovym konfiguracnim souborum.

  • 31. 3. 2011 13:25

    Pavel Stěhule

    Ta chyba je v 9.0 opravena

    psm: FATAL: role "export" is not permitted to log in

    Zážitků s Oraclem mne zatím život ušetřil - kromě jedné dvoudenní instalace Oracle na nepodporovanou distribuci. Ale Tomáš Vondra by asi mohl vyprávět:

    http://www.fuzzy.cz/cs/clanky/hnusny-chytak-s-heslem-v-sqlplus/

  • 1. 4. 2011 18:36

    Lenin POWER!

    No kdyz nemate zkusenosti s Oraclem tak pak nemuzete rozumet zakaznikum proc z nej chteji migrovat a logicky si myslite ze problemem je cena. Kdyz jsme delali tech 800 Oraclu tak jo, to se migrovalo kvuli cene za licence ktere Oracle nechtel dat lacineji.

    Vezmete si ze nejlevnejsi oracle stoji 5,800/1 CPU socket + US 1,276.00 support na rok. Bez supportu se to neprodava. Takze pri 800 Oraclech jim nacpete 1 mego - sleva co vam daji (tak 35 procent) rocne.

    Kdyz jim nabidnete ze jim budete delat pgsql rocni support rekneme za $350k tak si to od vas koupi, zvlaste kdyz vas doporuci lenin a vyrazite semnou na zakaznika. Z tech prachu chci 30% no a za zbytek si najmete lidi a jdete realizovat zakazku.

    Navic se osobne setkate s leninem coz u vas zanecha hluboky zazitek na cely zivot a dal uz budete vedet komu se vyhybat.

  • 1. 4. 2011 21:32

    Pavel Stěhule

    Ju - nemůžu rozumět všemu :). Ale mám hubu a nebojím se jí použít, když něčemu nerozumím :). O administraci Oraclu toho fakt moc nevím - jsem víc programátor než admin a ještě víc jsem analytik než programátor - tím je to dané - ale perfektně rozumím tomu, jak a proč Oracle vydělává peníze. To na západě je management o 20 let napřed před těma zdejšíma :( - ale už i tady se objevují fy. které z Oraclu utíkají.

    Jinak můžem zajít na pivko, můžeme pokecat, můžeme se domluvit na nějakém projektu i na formě - pokud to nějak zvládnu časově - mail na mne máte. Potkal jsem už pár zvláštních lidí, - o jednoho víc nebo méně - to bych měl ustát :).

  • 3. 4. 2011 23:24

    Lenin POWER!

    huba je vam k nicemu. Abyjste ji mohl pouzit musite si vytvorit nejprve nejaky obraz v kterem vam nejaka cast chybi a na tu se chcete zeptat. Naprosta vetsina lidi si ten obraz neumi vytvorit a je prilis pysna na to aby zkopirovala nejaky jiz fungujici model.

    Ohledne toho Oracle, tak mne to taky dost prekvapuje jak je to v cechach popularni, taky je u vas popularni TSM. O oboudvou techto softech tu lidi prskaji ze jsou drahe. U vas jsou jeste drazsi nez v USA a lidi u vas neprskaji. Holt jak se rika jiny kraj, jiny mrav. Presneji receno naprosto neschopny management.

    Ohledne nasi spoluprace, to vy se musite snazit, ne ja. Necekejte ze vam sezenu projekt ktery by vyhovoval vasim pozadavkum - maximalne 14 dni oneman show a pak to uz nechci videt. Takhle my v komercni sfere nepracujeme. My navzajem dlouhodobe spolupracujeme. Az to pochopite a sezenete si tak 3 lidi tak mi napiste.

    Jsem neco a to urcuje muj zivot jsou kecy pro dospele. Vemte si za priklad mne. Kdyz ucim lidi bibli tak mi nikdo neuveri ze nejsem knez. Kdyz ucim lidi litat tak mi nikdo neuveri ze nejsem letecky instruktor, kdyz vysvetluju lidem db2 a spol tak mi nikdo neuveri ze nejsem database admin a tak dale. Vy mi rikate: jak tohle ja muzu vedet? A ja vam rikam stejne tak jako to vim ja.

  • 4. 4. 2011 7:32

    Pavel Stěhule

    To umění keců pro dospělé můj kamarád označuje jako "pedagogické úmění" - což si myslím, že umíte. Tak pro obchodníka je to skoro nutný předpoklad :) Naši politici to zkouší na nás denodenně - máme ministry životního prostředí, kteří byli stínoví ministři průmyslu - a lidi jim to žerou. Vím, jak to funguje v komerční sféře - a zatím jsem raději, tam kde jsem, s výhodami a nevýhodami, které to má. Nicméně všechno se vždy může změnit.

  • 5. 4. 2011 12:44

    Lenin POWER!

    Ja narozdil od politiku nelzu lidem pro svuj vlastni prospech. O tom obchod neni.

    Spravny prodejce musi prodat a tim uspokojit potreby zakaznika.

    Clovek musi byt vsestrane zameren, tady to lidi chapou. U vas moc ne, tam se praktikuje pristup jsem cosi a cokoliv jineho mne nezajima.

  • 29. 3. 2011 15:18

    Joelp

    Nejdříve php.net a teď mysql.com? Kdo bude dál? apache.org?