Ruby on Rails opravují kritickou bezpečnostní chybu (diskuse)

[washeck]

Mám pocit, že v poslední době se o RoR píše jenom v souvislosti s jednou kritickou dírou za druhou.

[SPM]

Teď už to aspoň opravují, předtím to úmyslně neopravovali

[xvasek]

Jj,RoR je pěkný cedník. :-/

[Lukáš Zapletal]

Je to tak, kromě toho Rubyisti nemohou řádně aktualizovat, protože byl díky této chybě napaden server rubygems.org a některé gemy (knihovny) byly napadeny. Probíhá šetření, server běží v read only režimu. Já osobně bych z toho teda raději neinstaloval nic.

A Rubyisti se ne a ne poušit ze zkušeností starších, například balíčkovacích systémů u distribucí, které se digitálně podepisují. Řekl bych, že nyní tam podpisy už přidají. Prostě musejí padnout na hubu, asi se s tím nedá nic dělat.

Jinak knihovní systém rubygems je vadný a nesmírně pomalý, protože umožňuje instalovat stejné balíčky ve více verzích, což může být někdy sice "cool", ale čím víc jich nainstalujete, tím pomaleji Ruby pak startuje (protože prohledává pro každý require stovky, tisíce a včera jsem naměřil celkem 170 tisíc stat/open systémových volání s ENOENT výsledkem).

Jsou to pankáči. Rubyisti obecně nemají v lásce PHP, jenže já bych řekl, že Ruby je dnešní PHP. Potřebují trošku schladit a začít věci dělat pořádně, trošku "postaru".

-- Autor není Rubyista, ale pracuje na velkém open-source systému napsaném v Ruby on Rails ;)

[Michal Karas]

Jinak knihovní systém rubygems je vadný a nesmírně pomalý, protože umožňuje instalovat stejné balíčky ve více verzích, což může být někdy sice "cool", ale čím víc jich nainstalujete, tím pomaleji Ruby pak startuje (protože prohledává pro každý require stovky, tisíce a včera jsem naměřil celkem 170 tisíc stat/open systémových volání s ENOENT výsledkem).

Zajímavé. Zkoušeli jste i co s tím udělá Bundler? Jestli dokáže všechny ty nepouživané gemy odřezat i z require?

[Michal Karas]

Bezpečnostní díra související s parsováním XML => YAML už tu byla dříve: Ruby on Rails 3.2.11, 3.1.10, 3.0.19 a 2.3.15

I když je princip víceméně stejný, tak tentokrát je zranitelnost zneužitelná přes JSON => YAML. Viz například Rails PoC exploit for CVE-2013-0333.