V Londýně probíhá dvoudenní Ubuntu Summit 25.10. Na programu je řada zajímavých přednášek. Zhlédnout je lze také na YouTube (23. 10. a 24. 10.).
Gemini CLI umožňuje používání AI Gemini přímo v terminálu. Vydána byla verze 0.10.0.
Konference OpenAlt 2025 proběhne již příští víkend 1. a 2. listopadu v Brně. Nabídne přibližně 80 přednášek a workshopů rozdělených do 7 tematických tracků. Program se může ještě mírně měnit až do samotné konference, a to s ohledem na opožděné úpravy abstraktů i případné podzimní virózy. Díky partnerům je vstup na konferenci zdarma. Registrace není nutná. Vyplnění formuláře však pomůže s lepším plánováním dalších ročníků konference.
Samsung představil headset Galaxy XR se 4K Micro-OLED displeji, procesorem Snapdragon XR2+ Gen 2, 16 GB RAM, 256 GB úložištěm, operačním systémem Android XR a Gemini AI.
Před konferencí Next.js Conf 2025 bylo oznámeno vydání nové verze 16 open source frameworku Next.js (Wikipedie) pro psaní webových aplikací v Reactu. Přehled novinek v příspěvku na blogu.
Sovereign Tech Fund oznámil finanční podporu následujících open source projektů: Scala, SDCC, Let's Encrypt, Servo, chatmail, Drupal, Fedify, openprinting, PHP, Apache Arrow, OpenSSL, R Project, Open Web Docs, conda, systemd a phpseclib.
Bylo vydáno OpenBSD 7.8. S předběžnou podporou Raspberry Pi 5. Opět bez písničky.
Valkey (Wikipedie) byl vydán v nové major verzi 9.0. Valkey je fork Redisu.
Byly publikovány informace o kritické zranitelnosti v knihovně pro Rust async-tar a jejích forcích tokio-tar, krata-tokio-tar a astral-tokio-tar. Jedná se o zranitelnost CVE-2025-62518 s CVSS 8.1. Nálezci je pojmenovali TARmageddon.
AlmaLinux přinese s verzí 10.1 podporu btrfs. XFS bude stále jako výchozí filesystém, ale instalátor nabídne i btrfs. Více informací naleznete v oficiálním oznámení.
Programming stuff. And stuff.
Nemožnost attachnout se k pythonímu procesu podobně jak to umí gdb s C/C++ kódem mi dost začla vadit, když jsem měl spoustu pythoních procesů a jenom občas v některém z nich nastala race condition.
Dostal jsem nápad vyzkoušet injectnout pythoní kód, který by se připojil k pythonímu debuggeru, do běžícího pythoního procesu. Možnosti jsou asi dvě, gdb nebo ptrace. Volba padla na gdb, pro vyzkoušení je to jednodušší než přímo přes ptrace (navíc přenositelnější a není potřeba přepisovat kód v paměti).
Nejdůležitejší věc byla zjistit, kam se může kód injectnout. Když je proces uspán v systémovém volání (třeba přes time.sleep), tak to moc dobře nejde. Něco jsem zjistil experimentováním s gdb nad pythonem a něco z gdbinit, který používají pythoní vývojáři.
Po attachnutí se s gdb na pythoní proces se musí breaknout na místě v pythoním stack frame (funkce PyEval_EvalFrameEx), kde se bude provádět další instrukce virtuálního stroje. V pythonu 2.6.2 se switch na opcode nachází v Python/ceval.c:952.
V promptu gdb zadám dva příkazy (viz níže definice těch příkazů):
til Python/ceval.c:952
callkomodo
Vuala! V Komodo IDE se mi objeví connection (stačí jen dát jednou "step over") a už vidím a debuguju kód, který je interpretován attachnutým pythoním procesem. S jiným debuggerem by to nespíš šlo taky, jenže myslím většina pythoních debuggerů dělá connection obráceně (debugovaný program je server, debugger je klient), asi by se muselo hackovat jinak.
GDB má machine interface, čímž lze tenhle postup automatizovat.
Použité předdefinované příkazy v ~/.gdbinit (metoda brk se připojuje na debugger):
define callkomodo
call PyRun_SimpleString("import sys; sys.path.append('/opt/Komodo'); from dbgp.client import brk; brk('172.16.1.105', 9000);")
continue
end
define til
tbreak $arg0
continue
end
U sebe jsem měl přeložen python s ladícími symboly, breaknutí na konkrétním řádku není problém. Na ostrém serveru je nutné disassemblovat distribuční python a zjistit správnou adresu pro breakpoint (nebo přeložit ručně znovu). V mém pythonu ten switch(opcode) vypadá takhle:
0x00000000004a0d83 (PyEval_EvalFrameEx+1367): cmpl $0x8f,-0x1c8(%rbp)
0x00000000004a0d8d (PyEval_EvalFrameEx+1377): ja 0x4a7026 (PyEval_EvalFrameEx+26618)
0x00000000004a0d93 (PyEval_EvalFrameEx+1383): mov -0x1c8(%rbp),%eax
0x00000000004a0d99 (PyEval_EvalFrameEx+1389): mov 0x546270(,%rax,8),%rax
0x00000000004a0da1 (PyEval_EvalFrameEx+1397): jmpq *%rax
Tiskni
Sdílej:
pekne, precteni takoveho blogu po ranu cloveku hned spravi naladu
Pro jiné pythoní debuggery by mělo stačit injectnout volání sys.settrace() se správně nastavenou trace funkcí a výsledek by měl být podobnej.
Trocha jsem to zkoušel na pythoní binárce bez ladících symbolů - musíte specifikovat adresu. Jenže třeba s ASLR + PIC kódem se adresy pořád mění. Nakonec jsem boj s gdb vyhrál Lze to napsat takhle (samozřejmě je nutné znát správný offset):
til *(&PyEval_EvalFrameEx+998)