Nazdar! je open source počítačová hra běžící také na Linuxu. Zdrojové kódy jsou k dispozici na GitHubu. Autorem je Michal Škoula.
Po více než třech letech od vydání verze 1.4.0 byla vydána nová verze 1.5.0 správce balíčků GNU Guix a na něm postavené stejnojmenné distribuci GNU Guix. S init systémem a správcem služeb GNU Shepherd. S experimentální podporou jádra GNU Hurd. Na vývoji se podílelo 744 vývojářů. Přibylo 12 525 nových balíčků. Jejich aktuální počet je 30 011. Aktualizována byla také dokumentace.
Na adrese gravit.huan.cz se objevila prezentace minimalistického redakčního systému GravIT. CMS je napsaný ve FastAPI a charakterizuje se především rychlým načítáním a jednoduchým ukládáním obsahu do textových souborů se syntaxí Markdown a YAML místo klasické databáze. GravIT cílí na uživatele, kteří preferují CMS s nízkými nároky, snadným verzováním (např. přes Git) a možností jednoduchého rozšiřování pomocí modulů. Redakční
… více »Tým Qwen (Alibaba Cloud) uvolnil jako open-source své modely Qwen3‑TTS pro převádění textu na řeč. Sada obsahuje modely VoiceDesign (tvorba hlasu dle popisu), CustomVoice (stylizace) a Base (klonování hlasu). Modely podporují syntézu deseti různých jazyků (čeština a slovenština chybí). Stránka projektu na GitHubu, natrénované modely jsou dostupné na Hugging Face. Distribuováno pod licencí Apache‑2.0.
Svobodný citační manažer Zotero (Wikipedie, GitHub) byl vydán v nové major verzi 8. Přehled novinek v příspěvku na blogu.
Byla vydána verze 1.93.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Svobodný operační systém ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, slaví 30. narozeniny.
Společnost Raspberry Pi má nově v nabídce flash disky Raspberry Pi Flash Drive: 128 GB za 30 dolarů a 256 GB za 55 dolarů.
Technologie Skip pro multiplatformní mobilní vývoj, která umožňuje vývojářům vytvářet iOS a Android aplikace z jediné Swift a SwiftUI kódové základny, se s vydáním verze 1.7 stala open source.
Na GitHubu byl zveřejněn algoritmus "Pro vás" sociální sítě 𝕏.
StartSSL CA - class1 intermediate - certifikátklient zná StartSSL, ale zaslán mu bude certifikát, který má jako CA class1 intermediate a ten má jako CA startssl. Problém bude, pokud na místě class1 intermediate bude jiná ca, která vydá vlastní certifikát a ta ho podvrhne a klient nic nepozná. Z článku jsem to dost dobře nepochopil a ani to jak se proti takovým útokům prakticky bránit? (Článek je už starý a proto se ptám zde místních guru)
Řešení dotazu:
StartSSL CA deklaruje, že může podepisovat certifikáty jiných autorit, které podepisují koncové certifikáty (že tedy mezi koncovým certifikátem a jimi bude ještě jedna CA). Teoreticky by ta cesta mohla být i delší (tj. např. že by StartSSL CA podepisovala certifikáty autorit, které podepisují certifikáty dalších autorit a ty teprve podepisují koncové certifikáty). Pokud vy přijmete certifikát StartSSL CA za důvěryhodný i s jejich politikou, říkáte tím, že jim věříte, že podepíšou certifikáty jen takových certifikačních autorit, které považují za dostatečně důvěryhodné (mají např. nějaké požadavky na jejich politiku). Pokud jim nevěříte, je jednoduchý způsob, jak se bránit – odstranit StartSSL CA ze seznamu důvěryhodných autorit.
Praktický příklad, kde takováhle hierarchie dává dobrý smysl, je třeba univerzita. Ta bude mít svou certifikační autoritu, ale svou CA bude mít také každá fakulta. Teprve ty fakultní CA budou podepisovat koncové certifikáty. Ta univerzitní CA bude ve své politice deklarovat, že jako zprostředkující CA podepíše jen oficiální CA jednotlivých fakult, které dále musí dodržovat nějaké univerzitní standardy pro to, co mohou podepisovat.
V komerční oblasti jsou ty zprostředkující CA podle mne dost na hraně. Sice chápu, že pro velké organizace je příjemnější mít vlastní CA, než nakupovat spousty certifikátů od externí CA, takže chápu jejich snahu nechat si od důvěryhodné externí CA certifikát zprostředkující CA, slíbit té kořenové CA, že certifikáty bude vydávat „správně“, a pak už si to řešit po svém. Ale nedovedu si představit, že by ta externí komerční CA měla sílu a moc ty zprostředkující CA nějak kontrolovat.
Ale nedovedu si představit, že by ta externí komerční CA měla sílu a moc ty zprostředkující CA nějak kontrolovat.co treba extension "name constrains"? pravda, prakticky jsem nikdy nezkousel, jak se k tyhle extension napriklad browsery chovaji, takze je docela mozna ze ji ignoruji, ale v principu by to fungovat melo
Tiskni
Sdílej: