Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
Řešení dotazu:
./pppd noauth nobsdcomp nodeflate require-mppe-128 \
name "CN-name-from-client-cert" \
remotename "CN-name-from-server-cert" \
cert ..../cert.pem \
key ..../key.pem \
ca ..../ca.pem \
password password \
logfile /tmp/pppd.log \
pty "pptp 192.168.200.65 --nolaunchpppd"
where the password is only required if your private key requires one. You can then view the /tmp/pppd.log file for a detailed log. does that help? cheers, JJK PS yes I'm aware that the old italian tutorial is gone and that I need to write a tutorial of my own, it's just that I do not use this very often ;)
------------------------------------------------------------------------------------------Bohužel mě to s touto konfigurací nechodí, takže si s ním ještě dopisuji a uvidím, co z toho vyleze...
require-eap ca /etc/pki/tls/certs/ca-ss-users.crt cert /etc/pki/tls/certs/ppp-server.crt key /etc/pki/tls/private/ppp-server.key password XXX
Hm, tak nevim, co mám špatně, tady je můj složený příkaz:
/usr/local/sbin/pppd \
noauth nobsdcomp nodeflate require-eap \
name "$FQDN_HOSTNAME" remotename "$CN_Z_CA_CERTIFIKATU" \
cert $PRIVATNI_CERTIFIKAT \
key $VEREJNY_KLIC
ca $CA_CERTIFIKAT
password $HESLO \
logfile /tmp/pppd.log pty \
"pptp $VPN_SERVER --nolaunchpppd"
Výstupem je:
/usr/local/sbin/pppd: The remote system (CERT-CA-LESYCR) is required to authenticate itself
/usr/local/sbin/pppd: but I couldn't find any suitable secret (password) for it to use to do so.
Nějak si s tím nevím rady, našel jsem tuhle diagnostiku, ale moc mi to nepomohlo.
Mohl bys mi poslat celou svoji konfiguraci, zkusil bych z toho dedukovat, kde dělám chybu. Děkuji za pomoc.
a sice moment... az tohto vypisu vlastne asi tusim o co sa pokusate... ja som vam dal funkcnu cast konfiguracie na strane VPN servera...a vy riesite podla vsetkeho VPN klienta (pptp+pppd on eap-tls). v tom pripade direktivu "require-eap" asi vyhodte... lebo tym vlastne nutite overit opacnu stranu spojenia co asi nieje ziaduce.
z readme:
If you're setting up a client, edit the configuration file and then run pppd with 'remotename' option to specify the server name. Add the 'need-peer-eap' option if you want to be sure the peer ask you to authenticate (and to use eap) and to disconnect if it doesn't.
Ano máte pravdu, pokouším se připojit z linuxového klienta na Microsoft VPN PPTP server.
require-eap jsem vyhodil, do remotename, kde jsem používal CN z certifikátu, jsem podstrčil přímo hostname FQDN serveru VPN. ale stále to na mě plive:
Connect: ppp0 <--> /dev/pts/8
EAP: peer reports authentication failure
Connection terminated.
Ok, díky. Zkusím. Jinak se jedná o klasický Windows Server 2003, kde je nahozená PPTP VPN, která používá klientské certifikáty. Jedná se o následující konfiguraci, kterou se mi podařilo vyčíst po připojení na Windows mašině.
On the connection configuration card:
On security folder there is selected "Precise configuration", then click on the Setting
Cryptography of data: Require (disconnect if cryptography cannot be used)
Use of protocol EAP: Smart Card or another certificate
There is a button for "Properties" where is>
- Use certificate in this computer
- Verify server certificate
- and in the root certificates list I selected the CA root certificate
Windows client VPN attributes after connection made:
Type of device: vpn
Type of server: PPP
Transports: TCP/IP
Authentication: EAP
Cypher: MPPE 128
Compression: MPPC
Multilink patterns of PPP: disabled
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
Sep 5 14:28:29 helios pppd[6611]: using channel 10
Sep 5 14:28:30 helios pppd[6611]: sent [LCP ConfReq id=0x1 < asyncmap 0x0> < magic 0xbe27e267> < pcomp> < accomp>]
Sep 5 14:28:30 helios pppd[6611]: rcvd [LCP ConfReq id=0x0 < mru 1400> < auth eap> < magic 0x8c817fa> < pcomp> < accomp> < callback CBCP> < mrru 1614> < endpoint [local:97.2e.e8.e1.34.cb.47.43.b5.60.1c.c8.f8.0d.2a.89.00.00.00.00]> < 17 04 00 53>]
Sep 5 14:28:30 helios pppd[6611]: sent [LCP ConfRej id=0x0 < callback CBCP> < mrru 1614> < 17 04 00 53>]
Sep 5 14:28:30 helios pppd[6611]: rcvd [LCP ConfAck id=0x1 < asyncmap 0x0> < magic 0xbe27e267> < pcomp> < accomp>]
Sep 5 14:28:30 helios pppd[6611]: rcvd [LCP ConfReq id=0x1 < mru 1400> < auth eap> < magic 0x8c817fa> < pcomp> < accomp> < endpoint [local:97.2e.e8.e1.34.cb.47.43.b5.60.1c.c8.f8.0d.2a.89.00.00.00.00]>]
Sep 5 14:28:30 helios pppd[6611]: sent [LCP ConfAck id=0x1 < mru 1400> < auth eap> < magic 0x8c817fa> < pcomp> < accomp> < endpoint [local:97.2e.e8.e1.34.cb.47.43.b5.60.1c.c8.f8.0d.2a.89.00.00.00.00]>]
Sep 5 14:28:30 helios pppd[6611]: sent [LCP EchoReq id=0x0 magic=0xbe27e267]
Sep 5 14:28:30 helios pppd[6611]: rcvd [EAP Request id=0x54 Identity < No message>]
Sep 5 14:28:30 helios pppd[6611]: sent [EAP Response id=0x54 Identity < Name "helios">]
Sep 5 14:28:30 helios pppd[6611]: rcvd [LCP EchoRep id=0x0 magic=0x8c817fa]
Sep 5 14:28:30 helios pppd[6611]: rcvd [EAP Failure id=0x54]
Sep 5 14:28:30 helios pppd[6611]: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
Sep 5 14:28:30 helios pppd[6611]: rcvd [LCP TermReq id=0x3 08 c8 17 fa 00 3c cd 74 00 00 02 b3]
Sep 5 14:28:30 helios pppd[6611]: sent [LCP TermAck id=0x3]
Sep 5 14:28:30 helios pppd[6611]: rcvd [LCP TermAck id=0x2 "Failed to authenticate ourselves to peer"]
Sep 5 14:28:30 helios pppd[6611]: Waiting for 1 child processes...
Sep 5 14:28:30 helios pppd[6611]: script pptp 80.188.1.3 --nolaunchpppd, pid 6612
Sep 5 14:28:30 helios pppd[6611]: Script pptp 80.188.1.3 --nolaunchpppd finished (pid 6612), status = 0x0
Díky za feedback všem.
Ladislav Jech
root@helios:~# /usr/local/sbin/pppd debug noauth nobsdcomp nopcomp noaccomp nodeflate require-mppe-128 name "Subjekt z klient certifikátu" remotename "CN z certifikátu serveru" cert /root/cert/PRIV_CERT.pem key /root/cert/PRIV_KEY_ONLY_WITHOUT_PASSPHRASE.pem ca /root/cert/CACERT.pem logfile /tmp/pppd.log pty "pptp X.X.X.X --nolaunchpppd"
Subjekt z klientského certifikátu vydoloval pomocí:
openssl x509 -noout -in PRIV_CERT.pem -subject
V případě remotename parametru, tak když tohle nesedí, tak debug vyhodí hlášku, že zadané peername nesedí s CN, které je vyčteno z certifikátu na serveru, takže se to odladí velmi jednoduše.
Po těchto změnách se připojení zdařilo, nicméně se nelze dostat do na žádný server, pouze na bránu VPN a to pouze port 443, hláška v logu ukazuje
Cannot determine ethernet address for proxy ARP local IP address 192.168.101.25 remote IP address 192.168.101.1 Script /etc/ppp/ip-up started (pid 10603) Script /etc/ppp/ip-up finished (pid 10603), status = 0x0Takže v tuto chvíli je připojení aktivní, ale síť nekomunikuje. V dokumentaci pppd jsem nalezl nějaké návody, jak toto upravit pomocí proxyarp, ale řešení sestává v úpravě na straně serveru. To v mém případě nehrozí, jelikož se nejedná o linuxový, ale windows server, a také na něj nemám přístup, takže si pohraju ještě s tímhle.
Cannot determine ethernet address for proxy ARPřeší ruční správné nastavení routovací tabulky. V mém případě zřejmě jediné řešení, jelikož nemám přístup ke konfiguraci serveru, aby se dalo nastavit z jeho strany. Zkusím ještě prozkoumat, zda to lze automatizovat nějak jinak, než pomocí ručně psaného skriptu. Ale nevím teď. Každopádně ručně jsem to rozchodil. Děkuji za pomoc timeos a tvůrci patche EAP-TLS Jan Just Keijserovi.
Ladislav
Tiskni
Sdílej:
