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.
Elektronický podpis sa vyrába tak, že zo vstupného dokumentu sa spočíta kontrolný súčet. Kontrolný súčet sa počíta špeciálnym matematickým algoritmom. Jeho špeciálnosť spočíva v tom, že pre ľubovoľný vstup poskytne na výstupe reťazec, z ktorého nie je možné odvodiť pôvodný vstup a zároveň aj tá najmenšia zmena vo vstupe má za následok zmenu vo výstupe. V minulosti sa používal jednoduchý algoritmus zvaný CRC, v súčasnosti sa používa napr. algoritmus s označením MD5, ale ten je vytláčaný algoritmom SHA1 resp. SHA2. Získaný výstupný reťazec sa potom zašifruje pomocou súkromného kľúča:
openssl dgst -sign RSprivatekey vstupny_subor > podpis Enter pass phrase for RSprivatekey:
Program si vypýta heslo prislúchajúce ku RSprivatekey a s jeho pomocou vytvorí elektronický podpis. Podpis je unikátny pre daný súkromný kľúč a vstupný súbor. Nikto iný, než ten, kto disponuje súkromným kľúčom, nemôže vytvoriť rovnaký podpis. Ten, kto chce zistiť, či dokument je pravý (nebol zmenený jeho obsah), spočíta jeho kontrolný súčet. Ten sa potom porovná s kontrolným súčtom, ktorý sme získali dešifrovaním overovaného podpisu:
openssl dgst -verify RSpublickey -signature podpis < vstupny_subor Verified OK
Ak by súbor medzičasom niekto pozmenil, elektronický podpis už nebude sedieť:
openssl dgst -verify RSpublickey -signature podpis < zmeneny_subor Verification Failure
V predchádzajúcich odsekoch sme používali pre prácu s certifikátmi program openssl z balíka OpenSSL. Teraz sa pozrieme, ako využiť SSL v maileri či browseri. Aby certifikáty používateľov bolo možné používať na šifrovanie či podpisovanie správ, musíme najprv naučiť program rozoznávať certifikačnú autoritu, ktorá certifikáty vydáva.
Náš vlastný certifikát potrebujeme importovať, ak plánujeme podpisovať odosielané správy. Mailové programy spravidla požadujú certifikát v inom formáte, ako sme používali doteraz - PKCS#12. Našťastie openssl poskytuje možnosť previesť certifikáty do požadovaného formátu:
openssl pkcs12 -in RScertificate.pem -inkey RSprivatekey -export \ -out RScertificate.p12 Enter pass phrase for RSprivatekey: Enter Export Password: Verifying - Enter Export Password:
Certifikáty ľudí, ktorých podpisy budeme overovať alebo ktorým budeme posielať šifrované správy, musíme takisto importovať.
Po ukončení importovania môžeme potom pri písaní správy nastaviť či má byť šifrovaná, alebo podpísaná, alebo oboje:
Pri takomto nastavení bude text správy šifrovaný. Pozor však na to, že informácie v hlavičke mailu, teda odosielateľ, príjemca, predmet správy a podobne, šifrované nie sú.
Ďalšou oblasťou, kde sa s SSL certifikátmi stretávame, sú webové servery.
Typickým príkladom sú webové servery pre internetbanking. Zmyslom je, aby
si používateľ bol istý, že je skutočne spojený s webovým serverom banky a nie
nejakého podvodníka, ktorý sa snaží vylákať cenné informácie, číslo
kreditky a podobne. Okrem autentickosti servera sa SSL postará aj o
šifrovanie dát prenášaných medzi webovým serverom a browserom. Ako to
funguje, si môžeme vyskúšať pomerne jednoducho. Potrebujeme k tomu webový
server Apache, ktorý bol skompilovaný s podporou SSL - pri kompilovaní bol
použitý prepínač --with-openssl. SSL funkcionalita je dostupná
vo forme modulu s názvom mod_ssl. Aby bola aktivovaná, musí
konfigurácia Apache obsahovať direktívu:
LoadModule ssl_module libexec/apache/libssl.so
Moja distribúcia to konkrétne rieši tak, že v konfiguračnom súbore
/etc/apache/httpd.conf treba zrušiť komentár na riadku, ktorý
includuje súbor s konfiguráciou SSL:
# ==> mod_ssl configuration settings <== Include /etc/apache/mod_ssl.conf
Správne nahratie mod_ssl sa prejaví aj v logu (o umiestnení logu
rozhoduje direktíva ErrorLog a vplyv má aj
LogLevel v httpd.conf):
tail /var/log/apache/error_log ... [Wed Feb 8 21:25:24 2006] [notice] Apache/1.3.33 (Unix) mod_ssl/2.8.22 OpenSSL/0.9.7d configured -- resuming normal operations
Okrem správneho nahratia mod_ssl potrebujeme prinajmenšom certifikát a zodpovedajúci súkromný kľúč. O ich umiestnení rozhodujú direktívy v konfiguračnom súbore:
SSLCertificateFile /etc/apache/ssl.crt/server.crt SSLCertificateKeyFile /etc/apache/ssl.key/server.key
Podstatné je aj nastavenie portu. Webové spojenia chránené pomocou SSL sa tradične robia na porte https (s číslom 443):
<IfDefine SSL> Listen 80 Listen 443 </IfDefine>
Teraz nám už ostáva iba prekrížiť prsty a odštartovať to:
httpd -DSSL Apache/1.3.33 mod_ssl/2.8.22 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order to read them you have to provide us with the pass phrases. Server ras:443 (RSA) Enter pass phrase: Ok: Pass Phrase Dialog successful.
Či Apache počúva na porte https, nám povie napr.
netstat.
netstat -ltp |grep http tcp 0 0 *:http *:* LISTEN 3616/httpd tcp 0 0 *:https *:* LISTEN 3616/httpd
Ak je všetko v poriadku, tak sa môžeme pokúsiť pripojiť pomocou browsera. Pretože ja som použil certifikát, ktorý som si vyrobil sám, tak ma browser upozorní, že taký certifikát ani CA nepozná a ponúkne mi zaradiť ho medzi dôveryhodné certifikáty. Tomu sa dá vyhnúť, ak certifikát CA vopred zaradíme do zoznamu dôveryhodných CA:
SSL modul servera apache dokáže oveľa viac. Môžete povoliť prístup k niektorým URL len pre browsery, ktoré sa preukážu správnym certifikátom a podobne. Detailnejší popis je mimo rozsah tohto článku, ale s dôverou sa môžete obrátiť na dokumentáciu.
Ak ste robili kroky popísané vyššie, isto ste si všimli, že súkromný kľúč je chránený heslom. Čo sa stane, keď sa heslo prezradí? V takom prípade môže niekto predstierať, že sme to my. Samozrejme za predpokladu, že získa aj náš súkromný kľúč. Môže tiež dešifrovať správy určené len nám. Tento problém riešia odvolávacie certifikáty (Revocation Certificate). Certifikačná autorita, okrem vydávania certifikátov aj udržiava a publikuje CRL - zoznam certifikátov, ktoré už nie sú platné.
openssl ca -revoke RScertificate.pem -keyfile CAdsaprivtekey -cert CAcertificate
V parametroch vidíme, že odvolávame certifikát signed.pem
a potrebný je na to súkromný kľúč CA a certifikát CA. O revokačných
certifikátoch sa všeobecne málo vie. V prípade, že sa napr. pripájate na
internet-banking, tak by ste si mali nielen overiť, že sa pripájate
skutočne na ten správny server, ale aj to, že jeho certifikát nebol
medzičasom odvolaný. Niektoré prehliadače to dokážu robiť za nás, ak
sú správne nastavené:
Program openssl z balíka OpenSSL, ktorý sme používali v uvedených príkladoch, nie je určený pre koncového používateľa a ani nie je tou najdôležitejšou časťou tohto balíka. Najpodstatnejšou časťou sú knižnice implementujúce jednotlivé šifrovacie a hashovacie algoritmy a program openssl len poskytuje základný prístup k týmto knižniciam. Okrem openssl sú súčasťou balíka aj ďalšie skripty napr. CA.pl a podobne. Knižnice z balíka OpenSSL sú používané v množstve Open Source projektov, kde majú na starosti bezpečnosť ukladania a prenosu dát. Udržiavanie aktuálnosti tohoto balíka je významnou súčasťou bezpečnosti celého systému.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
. Ale o to nejde. Zastávam názor, že prekladaný program stráca na kvalite a preto používam prakticky všetok software nelokalizovaný - anglický. Problém je tiež v tom, že preklady niektorých pojmov nie sú ustálené. A to sa potom človek čuduje keď lúšti chybovú hlášku "neplatný popisovač" a podobne 
. Pravdou je, že by som pri tých screenshotoch mal rád aj linky na screenshoty z iných klientov než TB, ale nejak som sa k tomu nedokopal. Zatiaľ.
Mám na mysli nepresnosť prekladu. Veľmi často sa stáva, že prekladateľ nepozná, resp. dostatočne nepreskúma, súvislosti v ktorých je daný termín použitý. Problémom, je tiež to, že niektoré stringy v originálnom programe sú použité na viacerých miestach v rôznych pádoch. V angličtine to nevadí, pretože vo všetkých pádoch má to slovo stále rovnaký tvar, ale v našich jazykoch dochádza k tomu, že slovo je na jednom mieste správne a na inom nesprávne vyskloňované. Ďalším príkladom je niečo, čo som zažil nedávno pri čítaní jednej knižky o SQL - prekladateľ prekladal aj príklady. Ale nie konzistentne. Takže meno stĺpca v CREATE TABLE bolo anglické, ale v SELECT statemente už bolo preložené. Skrátka urobiť dobrý preklad nie je jednoduché. A keď chcem mať istotu tak sa obraciam na originál.
Ale samozrejme priznávam, že máš svoju pravdu. Považuj moju náchylnosť používať anglický soft za moju úchylku, a ja sa budem snažiť pri písaní ďalšieho článku myslieť na Tvoju pripomienku.
) Pre PGP existuje tiež celkom dobrá dokumentácia. Najviac sa mi páčili dva textové dokumenty, ktoré boli súčasťou verzie 2.6.x. Jednu zaujímavú pasáž
som si dokonca preložil.
Veľa sa dá dočítať aj vo FAQ pre comp.security.pgp ( jedna stará verzia je tu: 1,
2,
3,
4,
5,
6,
7,
8,
9 ) Skrátka som mal pocit, že fungovanie PGP/GPG je medzi linuxákmi, ktorí si vedia pohľadať trocha dokumentácie na googli, dostatočne známe a článok o ňom by bolo nosenie dreva do lesa.
Už v diskusii pri prvej časti som sa Ťa pýtal, či by si bol ochotný urobiť recenziu druhej časti - prv než vyjde. Nereagoval si.
Máš pravdu. Nie som expert na SSL, CA ani X.509. Som len človek, čo pozná PGP a chcel vedieť ako bezpečne komunikovať s inými ľuďmi, pre ktorých používanie PGP/GPG nie je praktické. Niečo som si o tom prečítal, vyskúšal a zafungovalo mi to. Tak som to popísal v článku. Asi z toho neurobím doktorantskú prácu, ale niektorým sa to tu zišlo a páčilo.
CRC - nehovorím, že by sa CRC používal v kontexte elektronického podpisu ako ho chápe zákon či SSL alebo PGP. CRC - cyclic redundancy check - je algoritmus, ktorý sa používal ešte v časoch DOS-u a pkzip-u na overenie toho, že nejaký súbor nebol poškodený - napr. pri chybe čítania z diskety a podobne. Už v polovičke 90 rokov som stretával na unixoch program sum, ktorý slúži na podobné účely.
SHA-2 - wikipedia - The first member of the family, published in 1993, is officially called SHA; however, it is often called SHA-0 to avoid confusion with its successors. Two years later, SHA-1, the first successor to SHA, was published. Four more variants have since been issued with increased output ranges and a slightly different design: SHA-224, SHA-256, SHA-384, and SHA-512 — sometimes collectively referred to as SHA-2.
Na záver zopakujem to čo som Ti povedal už v diskusii k minulej časti: ak nesúhlasíš s niečím čo je v článku, je tu diskusia, v ktorej to môžeme uviesť na pravú mieru.
Hezký článek, jinak zajímavé info o tom, jak to technicky funguje mají třeba tady: www.digitalni-podpis.cz
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz