Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
libisds je knihovna pro přístup k SOAP rozhraní ISDS napsaná v jazyce C (verze ISO99) a šířena podle podmínek licence LGPL-3. Zdrojové kódy lze získat na http://repo.or.cz/w/libisds.git.
Tento text je staršího data, trochu jsem jej upravil. Odstavce v závorkách doplňují jinak zastaralé údaje, které mi ale bylo líto z historických důvodů smazat.
Vývoj byl započat na základě specifikace druhé verze ISDS („Provozní řád ISDS, verze k 30. 6. 2008“), která obsahuje mírně nepřesný a místy nedostatečný či zavádějící popis jednotlivých veřejných funkcí (ale i název, jak vidíte), dále WSDL definice SOAP volání a nakonec XML schémata jednotlivých datových struktur. Novější verze specifikace (poslední je z 22. ledna 2010) jsem později zapracoval.
Na základě této české dokumentace jsem vytvořil anglicky psaný přehled funkcí (podadresář „doc“). A to jednak jako odrazový můstek pro zahraniční vývojáře (a do budoucna kompletní vývojářskou specifikaci rozhraní ISDS zachycující oficiálně nedokumentované vlastnosti) a za druhé jsem potřeboval sám získat přehled, abych mohl učinit co nejlepší návrh knihovny libisds.
Právě tento krok mi ukázal, že cesta automaticky generovaného kódu z WSDL souborů nebude ta nejlepší, protože:
Implementace serveru nedodržuje specifikaci SOAP/1.1.
Server nedodržuje vlastní XML schémata.
Tudíž jsem zvolil obtížnější postup a napsal si vlastní SOAP parser a pro každou funkci ISDS jsem začal psát vlastní zobrazení z datových struktur knihovny do XML SOAP zpráv ISDS. Pro HTTP jsem zvolil knihovnu cURL a pro XML knihovnu libxml2.
Při implementaci přihlašování jsem narazil na ošklivý způsob přihlašování. Pošle se POST požadavek na jedno URL, server pošle přesměrování na jiné URL a teprve tam se přes HTTP Basic autentizaci odešle uživatelské jméno a heslo a pak následuje další přesměrování na původní adresu. V odpovědi přijde cookie, který pak slouží jako autentizační token pro další požadavky. Protože jednotlivé adresy nejsou nikde specifikované (a tudíž se mohou v budoucnu změnit) musí knihovna odesílat přihlašovací údaje slepě, kam ji HTTP hlavička Location zavede.
I když otrlí vývojáři webových aplikací najdou asi deset důvodů, proč to dělat takto složitě, já bych raději viděl prostou HTTP Basic autentizaci v každém požadavku a bez nějakých přesměrování a bez cookies.
(V lednu to došlo i vývojářům ISDS a nabídli bezstavový způsob komunikace, přesně jak jsem si přál.)
Server podporuje i autentizaci certifikátem X.509. Bohužel to neznamená, že jméno a heslo můžete zapomenout, budou potřeba stále. Moje knihovna má připravené rozhraní pro tento způsob rozšířené autentizace a implementace je otázka pár řádků kódu (cURL je na to připravena), leč není tak učiněno, protože podle vyhlášky ministerstva vnitra je nutné použít kryptografické úložiště, které nevlastním, a certifikát akreditované autority (podporovány jsou jen tři české), který také nemám a ani si jej nehodlám pořizovat.
(Novější specifikace již umožňuje přihlašování bez hesla (a to bylo řečí, že to zákon neumožňuje), ale je nutné použít nesmyslně drahý systémový certifikát.)
Zde je i problém s kryptografickými zařízeními, aby fungovala v Linuxu. Pár výrobců ale existuje a protože z jiných důvodů se doufám brzy stanu šťastným držitelem takové hračky včetně certifikátu, tak do budoucna počítám i s doděláním a ověřením této vlastnosti.
Další problém je trvanlivost hesla, které prý má být měněno každé 3 měsíce. Rozhraní SOAP však funkci měnění hesla vůbec neposkytuje. Tento nedostatek má prý řešit třetí verze systému.
(Skutečně poslední verze nabízí funkce pro zjištění data vypršení hesla a pro jeho změnu. Leč přihlášení vyčpělým heslem selže a neexistuje rozumný způsob, jak strojově zjistit, že je to kvůli starému heslu.)
Ukázkou ďábelské logiky systému je, že osoba mající přístup k více schránkám má více uživatelských účtů, více přihlašovacích jmen a hesel.
V současnosti libisds umí:
Pouze odesílání a přijímání dokumentu ve formě XML podstromu jsem neimplementoval, protože specifikace blíže neomezuje obsah a třeba taková množina uzlů {komentář, textový uzel} nelze serializovat jako správně utvořený soubor XML. Uvidíme, co vymyslí moudré hlavy.
Druhá věc, která není dodělaná, je ověřovaní digitálního podpisu a časového razítka zprávy. Ne že by to nešlo, ale aplikace bude chtít znát podrobnosti (nejlépe celý certifikát, důvod selhání ověření), a já nehodlám duplikovat API kryptografických knihoven. Nevím, jestli nějaký zjednodušující přístup je v tomto případě dobrý nápad.
Zde bych si dovolit poplivat analytiky navrhující ISDS, protože zatímco při odesílání zprávy se uvádí identifikátor cílové schránky, příjemce dostane údaje o odesílateli předformátované jako jeden dlouhý text. Pokud chce aplikace znát údaje strukturované, musí se znovu obrátit na systém. To ovšem může vést ke komickým situacím, pokud bude schránka mezi tím zrušena nebo údaje o majiteli schránky zaktualizovány - tedy pro starou zprávu se už nikdy nedovíte úplný popis odesílatele nebo příjemce.
Další úchylkou současné implementace serveru je, že položku „popis dokumentu“ (zpráva může obsahovat více dokumentů) systém považuje za název souboru a pakliže nekončí na patřičnou příponu, systém takovou zprávu odmítne přijmout (tj. přes ISDS nelze poslat soubor /etc/passwd). Zrovna tak systém kontroluje obsah dokumentu na povolený datový formát a pokud se mu nelíbí, máte smůlu – například mi nebylo vysvětleno, proč textový dokument nemůže obsahovat nulový bajt. (A to pomlčím, že ve zprávě není možné udat znakovou sadu textového dokumentu nebo že systém si myslí, že MIME typ PDF souboru je „pdf“.)
(Poslední verze specifikace tento problém řeší šalamounsky: Stávající pochybný systém standardizuje, přičemž nevhodné názvy atributů nebo chybné hodnoty MIME typů ponechává kvůli zpětné kompatibilitě (přičemž by stačilo začít odmítat chybné nově odesílané zprávy, staré ze systému stejně časem zmizí).
Kryptografické prostředky zajišťující integritu a nepopiratelnost zpráv jsou také svérázné. Vývojáři zavrhli XMLDSig a místo toho si musí klient vypreparovat kus XML podstromu jakožto binární řetězec a nad ním vypočíst hash. Myšlenka oddělené logické a fyzické struktury XML (například různé znakové sady nebo uzávorkování hodnot atributů) je autorům ISDS úplně cizí.
Pokud jste někdo čekal, že z ISDS vymámíte digitálně podepsanou a časově orazítkovanou zprávu tak, aby byla důvěryhodná, musím vás zklamat. Zpráva je nejprve orazítkována a teprve i s razítkem podepsána. Při tom pro udržení platnosti digitálního podpisu je třeba postup opačný.
libisds umí načíst nebo stáhnout jednotlivé zprávy či doručenky jak XML zabalené v PKCS#7, tak již vybalené do čistého XML. Aplikaci jsou pak data dostupná jak v nativních céčkových datových strukturách, tak i původní binární kopie XML/PKCS#7.
Knihovna samozřejmě umožňuje pracovat s více schránkami najednou, každá funkce vrací stavový kód rozlišující důvod chyby, vyplňuje podrobný textový popis chyby a ještě obsahuje nezávislé protokolování několika úrovní a oborů (počínaje protokolem HTTP).
Zdrojové kódy knihovny jsou uloženy v adresáři „src“, aplikace potřebují includovat jediný hlavičkový soubor „isds.h“ a linkovat se proti jediné dynamické knihovně „libisds“.
Knihovna prozatím funguje jen v synchronním blokujícím režimu. Nicméně aplikace si může zaregistrovat funkci, kterou je informována o průběhu datového přenosu a může si vynutit jeho předčasné ukončení.
V adresáři „client“ jsou ukázky, jak aplikace může s knihovnu pracovat, které zatím používám jako hrubé testy. Skutečné testy knihovny ještě nejsou zdaleka hotovy, protože je to velmi rozsáhlá záležitost (často převyšující složitost samotné knihovny). Prozatím je k dispozici několik testů off-line funkcí. Důkladné testy budou pravděpodobně zahrnovat simulaci serveru, protože chybové stavy serveru se jinak nedají navodit, a tím rovněž odpadne nutnost komunikace s testovací instancí přes Internet, což je problém některých současných testů.
Překlad knihovny kvůli přenositelnosti (překlad sdílených knihoven se pro různé platformy liší) řídí nástroje Autotools a Libtool.
Knihovna je internacionalizována pomocí gettextu. Problém je však s protokolováním komunikace se serverem, který se odehrává v UTF-8 a tudíž kvůli ladění jej není možné převádět do jiné znakové sady (ať už kvůli ztrátovosti nebo kvůli poškození kontrolních součtů.) Rovněž hlášení přebíraná z cURL mají problém – tato knihovna ještě není internacionalizována. (Dobrovolník?) Větší problém je s hlášeními přebíranými z ISDS, která jsou většinou česky, ale někdy anglicky. Protože úplný seznam chybových kódu není specifikován, není možné zavést vlastní přeložitelný text.
Dokumentace je zatím vedena jako komentáře v hlavičkových souborech a to jak pro funkce, tak pro datové struktury.
Problém činí převod textového zápisu času ve formátu ISO8601, který k mému hořkému zklamání neumí ani POSIX, ani glibc. Zatím to řeším ošklivým hackem (přepínání časové zóny), který ale bude muset být nahrazen čistým způsobem.
Pro konkrétní kryptografickou knihovnu jsem se rozhodl takto: HTTPS řeší cURL a ten může být přeložen proti OpenSSL, GnuTLS, NSS a asi i dalším. Práci PKCS#7 by měly zvládat všechny. Problém je ale s CRL. OpenSSL umí, ale neumí si CRL stahovat. GnuTLS prý neumí vůbec, NSS prý umí i stahovat, ale nemám ověřeno. Osobně se mi líbí GnuPG/gpgme, jehož správce CRL dirmngr jsem si osahal (a poslal pár patchů, kvůli rozsynchronizovaným distribučním místům CRL PostSigna) a který funguje jinak pěkně a umí i takovou podstatnou věc, jako je odlišení kvalifikovaných autorit a podpisů od ostatních běžných.
Je toho spousta, úkolníček je uložen v kořenovém souboru „TODO“.
Zmíním jen, že bych chtěl vytvořit asynchronní a možná i vícevláknové rozhraní knihovny (protože aplikační grafické toolkity si to žádají), zdokonalit systém protokolování, učinit síťové funkce volitelné, aby bylo off-line aplikace neměly tolik závislostí, a pokud ještě zbude síla, tak doimplementovat doplňkové funkce, jako je žádost o vytvoření datové schránky a odeslání dokumentu do Czech POINTu na autorizovanou konverzi.
Ze všeho nejprve ale chci zvládnout systém vydávání verzí pomocí Automaku, abych mohl vydat první oficiální dehtovou kouli.
Tiskni
Sdílej:
(15. 1. 2010, můžete si udělat obrázek o rychlosti vydávání oprav) Dobrý den, všechny soubory v linuxovém deb balíku 602XML Filleru vlastní uživatel s UID 1000 a mají práva vesměs rwxr-xr-x, filler.sh pak rwxr--r--. Takže: 1) datové schránky nefungují pod jiným uživatelem než tím s UID 1000 (zrovna jsem na to přišel při řešení problémů s nefunkční schránkou u zákazníka, který má tu smůlu, že si líznul 1001) – filler.sh je… jaksi… nespustitelný 2) uživatel s UID 1000 může volně zapisovat třeba sem: - --- > > dpkg -c 602XML_Filler.deb - -rwxr-xr-x martin/martin 5668 2009-10-21 16:30 ./opt/602filler/bin/wine - --- …sem… - --- - -rwxr--r-- martin/martin 3240 2009-12-21 14:15 ./usr/bin/filler.sh - --- …nebo sem… - --- drwxr-xr-x martin/martin 0 2009-12-21 14:21 ./usr/lib/mozilla/plugins/ -rwxr-xr-x martin/martin 34520 2009-12-21 14:21 ./usr/lib/mozilla/plugins/602plugin.so - --- …a odtamtud si Firefox tahá pluginy a zjevně je i spouští, že. Hmm… Nastavit vlastníka na UID 0? Jenda
Dobrý den, v současné verzi doplňku je nutné jej vždy používat pod uživatelem, který jej nainstaloval, tento problém by měla vyřešit nová verze, která by měla vyjít během 2 týdnů. S přáním hezkého dne, Lukáš Huso Technická podpora DS
Dobrý den, nevím, jak u vás, ale u mě balíky instaluje root. Stávající konstrukce balíku přináší jeden funkční a jeden bezpečnostní problém. Asi vám unikla pointa minulého mailu, který se snažil lehce upozornit na ten bezpečnostní. Sežeňte si neposkvrněné Ubuntu/Debian/whatever a postupujte se mnou. 1) root# dpkg -i 602XML_Filler.deb - --> správně, nyní fungují DS jen pod uživatelem s UID 1000, pod jiným ne, protože sh: filler.sh: Permission denied 2) Máme uživatele badguy (UID 1000) a goodguy (UID <> 1000). Badguy chce svému kolegovi způsobit škodu, například smazáním souboru file v domovském adresáři goodguye. 3) badguy$ chmod +x /usr/bin/filler.sh 4) badguy$ echo '#!/bin/bash' > /opt/602filler/bin/wine; echo 'rm /home/goodguy/file' >> /opt/602filler/bin/wine 5) goodguy si nyní spustí Firefox a jakmile narazí na stránku s embednutým fillerem (např. http://www.czebox.cz/static/pages/zadost_formular.html v iframe), /opt/602filler/bin/wine se provede s oprávněním goodguye. S přáním hezkého dne Jan Hrach
Děkujeme za informaci, předal jsem problém kolegům z vývoje. S přáním hezkého dne, Lukáš Huso Technická podpora DS
Dobrý den, nová verze stále nevyšla, nicméně k balíku mám ještě připomínku. I kdyby nová verze vyšla, uživatel (respektive já jako admin) to nemá pouhou návštěvou webu šanci poznat, protože jméno i umístění toho balíku je pořád stejné. Příklad konvence jména z repozitáře Debianu: iceweasel_3.0.6-3_i386.deb Jinak – hodilo by se vytvoření repozitáře, aby se nemusel nový balík vždy stahovat, instalovat atd. Jenda
Dobrý den, dekuji za připomínku, předám kolegům z vývojového oddělení. S pozdravem Michal Vejvoda technická podpora ISDS
"...která musí garantovat funkčnost ze zákona."
To ale v praxi tak či tak moc nepomáha, zdá sa
Rozhodně ne ideálně, má to hodně much, ale funguje.Takže si to shrňme:
Což mimo jiné včera potvrdil v televizi nějaký auditor (jméno si nepamatuji, plešoun s brýlemi).Já už jsem slyšel v televizi o počítačích takové věci…
Takže jsme se v zásadě shodli na tom, že je to funkční řešeníZjevně definuješ termín "funkční" poněkud laxně. Podobně "funkční" by dneska nikdo nechtěl ani nejobyčejnější webový freemail... ale u milionové státní zakázky, která má výrazný dopad na většinu podnikatelů a právnických osob obecně, se to toleruje...
Pod pojmem nefunguje mám já osobně na mysli, že brání ve výkonu toho, k čemu bylo určeno.Pokud nefunguje je negace funguje (tj. není nic mezi tím), tak jsme se shodli na tom, že každý jinak vnímáme slovo „funguje“.
Evidentně jsi se nikdy nepodílel na tak rozsáhlém projektu, který navíc musí garantovat funkčnost na jisté úrovni.Správně, nepodílel. A řekl bych, že by ten projekt mohl funkčnost garantovat o dost lépe. Třeba nepoužitím úplně zbytečného windows-only programu. Myslím si, že zapisování uživatelem do systémových adresářů a přepisování souborů spouštěných ostatními uživateli by u většiny projektů bylo hodnoceno jako docela velká bezpečnostní chyba.
Bohužel u projektu, jehož uživatelů bude opravdu hodně (tento případ), nelze zahrnout požadavky a náměty každého jednotlivce.Kdyby to dělal někdo s mozkem na správném místě, nedalo by to o nic víc práce a fungovalo by to dobře.
Ono až se stane průser, tak jim nic jiného nezbyde, protože to by padaly hlavy...AŽ?! Taky necháváš své servery děravé s tím, že až se stane průser, tak to nějak opravíš?
Jde o ranné stadium.Ne, to tedy opravdu nejde. Ten systém je v ostrém provozu sedm měsíců a pět dní. Tři měsíce ho musí povinně používat všechny OVM a do DS nahlížet všechny právnické osoby kromě pár výjimek.
A já se divim, že nikdo nemá nic proti korupci. Já se divim, že se někdo u ISDS nevzteká. Já se divim, že někdo tvrdí, že je to normální, že zákon kreje lemplovinu. Já se divim, že v produčnim prostředí jsou sedm měsíců zmetky ...
Nebo ne ... ?
Ty naopak zahadzuješ všetky detaily (čo je jediný hmatateľný kontakt s tým systémom) a namiesto toho argumentuješ nejakým vágnym celkom. To, že ten celok sa skladá zo samých nefunkčných častí, je ti zjavne jedno. Platia ťa za to, že to "riešenie" tak obhajuješ? Áno, ja chápem, je to veľký projekt a nemôže byť dokonalý už z princípu a bude tam kopa chýb, ale toto je úplne inde. Tu je zlé prakticky všetko a na prvý pohľad je vidieť, že tú vec budoval niekto neschopný.
Toto nemá cenu. Pozdravuj svoje ministerstvo, alebo kto ťa to vlastne platí za PR...
Ahá, takže dobrovoľné PR. Inu, keď ťa to tak baví... Nechápem veľa vecí; napríklad, ako sa môže niekto zastávať nefunkčného riešenia, keď mu za to neplatia
Ukaž, že jsi lepší a pak pindej.Co očekáváš, že teď má dělat nebo ukazovat?
Tak. Se zatnutými zuby, ale funguje! Je to zatím nic moc, ale funguje. Snad se do budoucna bude systém zlepšovat.
Já od takového člověka neočekávám nic. Říct o někom, že je absolutně neschopný dokáže i moje dcera, která ještě neumí mluvit. Tak moc jednoduchý to je. Dokázat ale nějak, že by to dokázal líp, nebo že aspoň rozumí tomu, co říká, to už je těžší...
Snad se do budoucna bude systém zlepšovat.No, za posledních 7 měsíců, co je v ostrém provozu, se moc nezlepšil. Jestli to půjde dál tímhle tempem…
Ja dúfam, že nám za ten čas nevyhorí slnko
Eh, rovnako jednoduché je tvrdiť opak a to tu zas prezentuješ ty. Pritom dôkaz si nepodal žiadny. Takže sme si kvit
Nie je. A idiota, ktorý ho vytiahne na cesty a ohrozí v ňom cestnú premávku, by som posadil na 10 rokov za mreže (snáď máte nejaký zákon o spôsobilosti auta k jazde. STK anyone?).
Ten nemôže, platí ho automobilka
vim ~/.emacs