Mastodon (Wikipedie) - sociální síť, která není na prodej - byl vydán ve verzi 4.6. Přehled novinek s náhledy v oznámení na blogu.
V Edici CZ.NIC, knižní řady správce české národní domény, vychází nová kniha Martina Malého Kódy, buildy, firmwary. Autor po půl roce od vydání předchozího titulu přichází se svou již sedmou knihou, tentokrát zaměřenou na vývoj programového vybavení pro embedded zařízení. Publikace s podtitulem Základy vývojářského řemesla pro tvůrce hobby elektroniky nabízí praktického průvodce pro všechny, kdo své projekty vytvořené s Arduinem
… více »V Brně na FIT VUT probíhá dvoudenní open source komunitní konference DevConf.CZ 2026. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.
Byla vydána nová verze 15.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Vývojáři Ubuntu představili projekt Myna, tj. iniciativu zaměřenou na přidání funkce převodu řeči na text do prostředí desktopu Ubuntu. Dle plánu již v Ubuntu 26.10.
Společnost Epic Games představila nový open source systém pro správu verzí Lore navržený pro "bezprecedentní škálovatelnost dat i týmů a optimalizovaný pro projekty, včetně her a zábavy, které kombinují kód s velkými binárními soubory, aby uspokojil potřeby vývojářů i umělců". Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Úřad pro ochranu hospodářské soutěže (ÚOHS) provedl v říjnu 2024 místní šetření u společnosti Seznam.cz. Úřad prověřoval důvodné podezření na možné protisoutěžní jednání, konkrétně zneužití dominantního postavení. Krajský soud v Brně v květnu 2025 konstatoval, že toto šetření bylo nezákonné. Nejvyšší správní soud (NSS) včera rozhodl, že šetření bylo provedeno v souladu se zákonem. Krajský soud bude muset případ posoudit znovu.
Byl představen skládací telefon Commodore Callback 8020. Ani hloupý, ani chytrý. Pro fanoušky Commodore a digitálního minimalismu. Bez webového prohlížeče a sociálních sítí. S předinstalovaným WhatsAppem. S operačním systémem Sailfish OS.
V OpenBSD byla objevena 27 let stará chyba v ppp pomocí níž lze vzdáleně obejít autentifikaci. Chyba byla nahlášena 12.6. a 14.6. byla opravena. Bližší info v článku A 27-Year-Old Authentication Bypass in OpenBSD's PPP Stack.
Odpověď Evropské komise (pdf) k evropské občanské iniciativě Stop Destroying Videogames, jež je součástí hnutí Stop Killing Games: "Komise se domnívá, že v této fázi nemůže navrhnout právní povinnost zachovat hratelnost videoher poté, co přestaly být poskytovány komerčně. Důvodem jsou i stávající práva duševního vlastnictví. Podle autorského práva EU mají nositelé práv výlučná práva ke svým výtvorům. Kromě autorských práv mohou být
… více »Nový VIM verze 7 slibuje zajímavé funkce, mimo jiné code completion pro řadu jazyků včetně RUBY. Implementace code completion není v případě RUBY nic snadného, tak jsem byl zvědavý, jak si s tím autor VIMu poradil. Dnes jsem si to vyzkoušel vlastníma rukama a nevěřil jsem vlastním očím...
Out of the box mi code completion pro ruby nefungovava (byly v tom moje úpravy konfigurace pro VIM 6), tak jsem se jal číst dokumentaci... Uzel nápovědy "ft-ruby-omni" obsahuje text:
Notes: - Vim will load/evaluate code in order to provide completions. This may cause some code execution, which may be a concern.
Tahle věta nám vlastně říká, jak je code completion udělán -- oni ten kód VYKONÁVAJÍ. Chvíli jsem nevěřícně kulil oči "may be a concern" -- to je poněkud eufemisticky řečeno! Zavětřil jsem zásadní bezpečnostní problém.
Pak si říkám, že v RUBY jsou přece prostředky, jak se s takovou situací vyrovnat. No a pak jsem si to vyzkoušel... a málem jsem spadl ze židle: je to tak, použitím code completion ve VIMu si třeba můžete smazat disk.
Demonstrace:
Mějme zdrojový soubor a.rb:
system('echo vim je pako > /tmp/pako')
class MyTest
def test
return 1
end
end
Porom mějme zdrojový kód, který editujeme, třeba b.rb:
require 'a'
t = MyTest.new
t.t
Pokud nyní umístíte kursor na konec posledního řádku souboru b.rb a stiskněte CTRL-X-O (code completion), VIM vám korektně nabítne metodu "test". Jenže při tom také vytvoří soubor /tmp/pako s obsahem "vim je pako"...
Co k tomu dodat? Zneužití se přímo nabízí, nemluvě o tom, že ke škodě může dojít i omylem.
Někdy je méně více...
Tiskni
Sdílej:
require "my-evil-script.rb", vim se přepne do ruby-mode, a v site-packages se objeví váš zákeřný exploit, aby jej vim mohl spustit?
system("echo #{$:.inspect} >> /tmp/zde_je_pako")
.
3. krok (pokud vám to ani teď nedocvaklo) - zamyslete se nad tím, jestli je třeba možné, že by někdo pustil VIM z adresáře /tmp/.
4. krok a) pokud vám to už docvaklo, nasypte si popel na hlavu a příště před psaním ironického příspěvku přemýšlejte, b) pokud se cvaknutí stále nedostavilo, změňte povolání
I ten loading kvůli zjištění názvů metod by měl jít celkem rozumně zasandboxovat. Jen by se o to měl přičinit autor...
".", je to jistý bezpečnostní nedostatek, ovšem pro Ruby, ne pro Vim.
2) Pusťte si Bash. Pod rootem napište echo >/etc/povolny_je_pako, a stiskněte ENTER (ta velká klávesa napravo se zalomenou šipkou). Ha! bash je děravý.
3) To samozřejmě možné je, ale netuším co tím chcete dokázat.
4) Myslím že vaše rady nebudu brát příliš vážně.
1) pokud má Ruby jako prioritní search path pro moduly ".", je to jistý bezpečnostní nedostatek, ovšem pro Ruby, ne pro Vim.
Jako prioritní ne, ale v serch path '.' má a to stačí. A problém VIMu to je, protože mluvíme o variantě, kdy je VIM linkován s Ruby a VIM nevhodným způsobem Ruby používá (nenastavuje $SAFE).
2) Pusťte si Bash. Pod rootem napište echo >/etc/povolny_je_pako, a stiskněte ENTER (ta velká klávesa napravo se zalomenou šipkou). Ha! bash je děravý.
No to je dost mizerný vtip a ještě horší přirovnání.
3) To samozřejmě možné je, ale netuším co tím chcete dokázat.Třeba to, že exploit zranitelnosti, kterou jsem popsal je poměrně proveditelný.
Jinak než z již vykonaného kódu se v jazycích jako Python, Ruby a Lisp doplňovat prostě nedá. Používám hlavně Slime, takže mi to vlastně ani nevadí a už mi přijde úplně přirozené, že completion bere v úvahu kód, který jsem již napsal, načetl a vyzkoušel. (Stejně si ho člověk krátce po napsání chce taky vyzkoušet, že jo...
) Třeba ty accessory v Ruby a v Lispu prostě jinak zjistit nejdou, leda, že by se udělala ad-hoc omezená statická analýza omezená pouze na standardní jazyk. Což by ve větším kódu asi dlouho nevydrželo.
(Forth vynechám, ten je na tom teoreticky nejhůř, ale asi se neočekává, že by někdo do několikakilobajtového softwaru montoval Visual Studio
)
Slime to řeší úplně jednoduše s přímočaře. C-c C-k provede compile-file a load. Tím pádem se dostane kód do běžícího lispu a je přístupný pro swank (serverová část Slime). Completion je řešená na straně serveru, tedy v tom bežícím procesu. Slime klient v Emacsu tedy nepředstírá, že umí doplňovat symboly z aktuálního souboru - to umět samozřejmě nemůže.
Tahá si je ze spuštěného image.
Zákonitě se nenajde nikdo, komu by to vadilo, přestože jde o tentýž proces, jako v případě Vimu a Ruby.
Jediný rozdíl je v tom, že tady je ta kompilace explicitní.
Mimochodem, fuzzy code completion ve Slime je z pohledu lispera úplný mazlíček. Třeba negado expanduje na most-negative-double-float, wiof na with-open-file...prostě expanduje podle procenta fuzzy matche dost vychytaným způsobem...
To by možná ocenili i javisti a C#aři, kdyby jim oumeme + TAB samo vyhodilo OutOfMemoryException (OutOfMemoryError) a nemuseli se se vším tak psát, zvlášť, když z toho dělají proměnnou a musejí to psát dvakrát.
Docela by mě zajímalo, co na tomhle poli šikovných fíčur vznikne v průběhu příštích dvaceti let a jak se s tím editory vypořídají.
if ($a == ($b ± autobus)) {
...
}
hmm, a to sa jeden čuduje, prečo im ten vývoj trvá tak dlho
On je trochu rozdíl mezi textovým editorem a interaktivním interpretrem. VIM se pokud vím interaktivním interpretrem nenazývá
Spousta editorů ten interpret obsahuje nebo nějaký umožňuje používat. Nehledě na to, že já zásadně nepoužívám textové editory. Používám výhradně interaktivní interpret Emacs Lispu, který se (jen) jako textový editor defaultně tváří.
Na běžné věci používam Kate a když programuju v Pythonu tak Eric3 (který autocompletion v Pythonu dělá a to aniž by vykonával kód
). Sice v něm to doplňování kódu asi nebude tak "dokonalé" jako v editorech který ten kód vykonávají, ale mně to stačí a nemusim se bát, že mi textový editor napáchá škody v systému
No a jako interaktivní interpretr nejčastěji používám výborný IPython, ten nemá konkurenci
A v konzoli třeba na editaci konfiguráků mi bohatě stačí nano
Možná by to stálo za nějaký Slime-reklamní blogpost. Nebo rovnou video.
http://common-lisp.net/movies/slime.mov
No jo, ale já stejně přemýšlím, že v téhle zemi se tvoří příliš málo screencastů...
Taková skvélá forma sdělování informací a ono kde nic, tu nic.
(((vím, ((jsem ignorant) a tohle) je) poněkud laciný) (humor))
Neupírám Vimu jednu přednost: Mnoho textových editorů obsahuje závažný bug, který náhodně poškozuje editovaný text a vkládá do něj náhodný šum, například :wq!, ZZ nebo qq. Ani Emacs se tomu nevyhnul. Vim je zato z nějakého důvodu imunní.
Mimochodem, převeďte si "vi vi vi" z římských číslic na arabské a pochopíte postoj Církve Emacsu k tomuto tématu...
Statickým parsingem zase všechny metody člověk nezjistí, nebo aspoň ne obecně. Můžu mít ošetřený attr_reader, attr_writer a attr_accessor, ale podobné "metaprogramovací metody" si člověk může nadefinovat sám a pak je editor bez pomoci v pytli.
Vítejte do světa dynamických jazyků...
Jó, kdo přičichne k lispu, uvědomí si, že i pouhá kompilace může mít side-effecty, protože při ní dochází třeba ke spouštění makrofunkcí (ty side-effecty ovšem mohou být záměr).
)