Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 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áří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Na kontrolu návratového kódu procesu snad není potřeba Python, ne?
Co se týče dohledu, ten je ideální mít nezávislý na tom, jestli se skript pro obnovu pustil nebo ne. Prostě systém, který hlídá tvoje služby, kontroluje dostupnost a dá ti mj. vědět, když se datum expirace nějakého certifikátu nebezpečně přiblíží.
Upozorňujem, že nie som dobrý v písaní bash skriptov, takže neručím za funkčnosť (po prípadných pripomienkach v komentároch upravím).
To je síce fajn, ale nechce sa mi s tým babrať Je to len dočasné riešenie:
Let’s Encrypt is working hard on automating the renewal process. Until the tool is ready, we are sorry for the inconvenience!
Ako sa to skriptuje? Nech s tým skúšam čokoľvek vracia mi 0.
for a in $(cat seznam_certifikatu.txt) ; do if [ -f $a ] ; then if ! openssl x509 -in $a -checkend $INTERVAL > /dev/null ; then notify fi fi done
#!/bin/bash cd /root/letsencrypt/letsencrypt domain=www.example.com webroot=/data/www/www.example1.com/html/letsencrypt/www.example.com/ days=65 certfile=/etc/letsencrypt/live/www.example.com/cert.pem email=mail@example.com ./letsencrypt-auto --email $email --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory -v -t -a webroot --webroot-path $webroot -d $domain auth >>/var/log/letsencrypt/console.l firstline="Script $0 at "`hostname`" designed to renew letsencrypt certificate" subj='[letsencrypt]['"$domain"'] Certificate renewal' if openssl x509 -checkend $(($days*86400)) -noout -in $certfile then { echo $firstline echo "Renewed Certificate is valid for at least $days days!" openssl x509 -noout -text -in $certfile } | mail -s "$subj" $email else { echo $firstline echo "Certificate has expired or will do so within $days days (or is invalid/not found)!" openssl x509 -noout -text -in $certfile } | mail -s "$subj FAILED - manual action required" $email fi #service httpd restartJe to zatím taky jen prototyp, ale mělo by to fungovat. Chybí tomu zatím nějaké zhezčení a nějaký lepší management těch certifikátů, protože plánuju mít na jednom serveru hromadný management všech certifikátů ze strojů, kde nebudu chtít instalovat tu jejich utilitu. I proto je ta cesta k tomu webu trochu složitější, protože se počítá s tím, že webserver běží na jiném stroji a má nějakou takovouto sekci:
location /.well-known/acme-challenge/ { return 301 $scheme://www.example1.com/letsencrypt/www.example.com$request_uri; }T.j. letsencrypt-auto běží na stroji www.example1.com, obnovuje doménu example.com, na jejímž serveru je jen přesměrování a vlastní ověření tak ve skutečnosti proběhne na www.exmaple1.com. Toto funguje bez problému, zatím jsem to zkoušel jen na stejném stroji, takže proto je tam zaremovaný ten restart toho webserveru, ale počítám s tím, že se to přes SSH nacpe kam potřebuje a tam zrestartuje... V principu mi jde o to, abych nemusel tu jejich utilitu instalovat na všech strojích a abych měl všechny certifikáty na jednom místě. Půjdo pak snadněji spravovat a ideálně i výše uvedený skript bude jen zárodkem pro komplexnější management - třeba že všechny obnovené domény z jednoho stroje nahraje na ten server najednou a udělá jen jeden restart nebo bude posílat pravidelně přehled certifikátů....
Hmm, to je zaujímavé, nečakal by som, že budú podporovať presmerovanie v acme-challenge. Asi by som sa na to vôbec nespoliehal a nastavil tam proxy_pass keby to v budúcnosti zmenili.
I'm not sure whether we'll publish a list of hosts that may perform validations. One security challenge for DV validation is that an attacker might be able to manipulate the network path between the host that performs the validation and the host that responds. To address this, we might in the future perform validations from several different locations on the Internet. We might not want to let prospective attackers know all of the network paths or locations that they'd have to manipulate in order to interfere with the validation for a particular name or server.Docela mě polil pot, když jsem si uvědomil, že člověk mluvící za CA, která může vydávat uznavané certifikáty, vůbec přemyšlí o řešení, které je založené na nějakém utajování IP adres, ze kterých se bude dělat domain validation...
Ja som v bezpečnosti trochu blbec (programátor, admin len z donútenia).
Ak sa niekto zmocní routra na ktorom mám pripojený server môže si kedykoľvek sám vygenerovať certifikát na danú doménu (opravte ma ak sa mýlim). Ktorýkoľvek klient, ktorý sa bude pripájať k serveru môže potom dostať na prvý pohľad korektne podpísaný certifikát vydaný na správnu doménu ale dáta môžu byť smerované na útočníkov server. Dá sa tomu zábrániť?
Je možné podvrhnúť DNS tak aby pri overení bolo možné získať certifikát aj bez nutnosti prístupu k routru?
A nakoniec asi najzaujímavejšia otázka: prináša Let's Encrypt väčšie zabezpečenie než na dlhú dobu vydaný certifikát podpísaný sám sebou (ak beriem do úvahy, že som na slovensku, teda nemôžem mať dnssec, v prípade vydania certifikátu pre moju doménu a podvrhnutia DNS bude používateľ vidieť stále bezpečné spojenie zatiaľ čo pri certifikáte podpísanom samým sebou by bol okamžite upozornený, že sa zmenil certifikát)?
Rozdíl je v tom, že u Let's Encrypt se zkontroluje otisk/certifikát z více různých míst, takže MITM útočník by musel být hned před serverem. Kdežto u samopodepsaných certifikátů mu stačí, když bude kdekoli mezi tebou a serverem, klidně těsně před tebou (tvoje místní síť). Kromě toho, že je takový útok snáze proveditelný, dá se i lépe cílit a utajit – nedozví se o něm ostatní, protože ti dostávají správný certifikát.
Wow vedel som, že niečo musí existovať. No mohli dať aspoň odkaz do dokumentácie ;)
Tiskni Sdílej: