Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Zdravim, jsem pravidelny navstevnik lide chatu -> mitnost pc. Chodim tam pres lide-gw pythonovou branu a ted me napadlo udelat nejakou proxy, ktera by fungovala jako takovy filtr vstupu, ktery by kontrolovaly prislusne moduly a teprve pak poustely do klienta. Avsak jsem zatim tvoril neuspesne :-(
Traffic probiha podle vseho pouze od klienta do proxy ( netusim jestli to leze i do brany a fuc ), ale od lide brany mi tam do proxy zadny traffic nejde, cili je zrejme neco spatne...
Login klienta do brany lide-gw je defaultne:
server = localhost
port = 13801
proxy jsem vytvoril na 127.0.0.1:13802
zde je kod: http://www.pastebin.cz/preview/384657616a64f3
lide-gw brana hlasi, ze se proxy pripoji (jede v terminalu), ale klientovi se pripojit nepodari, to je vse, co vam k tomu mohu rict, nevi nekdo, kde je chyba? :-(
Predem dekuji za odpovedi...
my $conn = Connection(); my $lide = $conn->accept();Nejdřív čekáte na spojení na jednom portu...
my $proxy = Proxy(); my $local = $proxy->accept();Pak na druhém...
while( my $input = <$lide> ) {
chomp $input;
print "$input\n";
my $l = <$local>;
chomp $l;
print $l $input;
}
Pak čtete řádek z prvního, pak z druhýho socketu (tohle pořadí máte nějak zaručeno, nebo si koledujete o deadlock), a pak printujete kam??? $1 asi těžko bude nějaký file descriptor, takže by to mělo celkem solidně řvát. Navíc používat $1 jako proměnnou je dost blbej nápad.
die "Can't connected to lide.cz!\n";Tohle je asi dost od věci, protože se to ani v jednom případě nikam nepřipojuje.
No ja jsem omylem hodil predchozi verzi, soucasna je: http://www.pastebin.cz/23778
Aco to ma delat? tento script by mel byt takovym mostem mezi lidegw branou a IRC klientem.
V soucasne dobe to dela to, ze se to napoji na lide branu, prijme data od klienta, ale to je tak vsechno, bud se tomuto mostu nedari odeslat data lidegw brane, nebo neni schopen ty data od ni prijimat a posilat klientovi...
Lidewg brana hlasi connected, tento perlovsky most hlasi connected obema socketum ( uz jsem ten vypis connected z kodu odstranil ), avsak klient se nedokaze prihlasit...
btw od klienta mi prijdou tyto data:
PASS ...
USER ...
NICK ...
Nenapada vas nekoho, jak to zprovoznit? :-(
Všimnul jsem si ale, že vůbec neukončuješ zprávy posílaný socketům, tak se ti všechny zprávy z "proxy" hromadí do 1. neukončené zprávy pro "lidegw" a proto na cílovém serveru není "nic vidět".
Kod verim, ze je zmateny, poneavdz tohle zkousim prvne, nikdy jsem takovou lokalni proxy nezkousel 
A dotaz? Ja osobne doufam, ze staci uz jen kousicek k tomu, aby to fungovalo, tak bych chtel nakopnout
takze znovu:
1) cil - udelat lokalni proxy, neboli takovy most mezi pythonovou lide-gw branou, ktera slouzi k vytvoreni socketu pro komunikaci lide chatu s IRC klientem.
defaultni login na tuto branu je server: localhost; port: 13801;
2) chovani soucasneho scriptu: pythonova brana hlasi prijem noveho spojeni ( tedy od teto lokalni proxy ), oba sockety byly zdarne vytvoreny a proxy prijima data od IRC klienta. To je ale vse - tato lokalni proxy pravdepodobne neodesila data od klienta k lide brane, nebo nedokaze prevzit data z lide brany ( anebo oboji ze ) :-/
3) soucasny kod:
#!/usr/bin/perl
use strict;
use IO::Socket;
sub Connection {
my $conn = new IO::Socket::INET (
PeerAddr => 'localhost',
PeerPort => '13801',
Proto => 'tcp',
Type => SOCK_STREAM,
);
if ( ! $conn ) {
die "Can't connected to lide.cz!\n";
} else {
return $conn;
}
}
sub Proxy {
my $conn = new IO::Socket::INET (
LocalAddr => '127.0.0.1',
LocalPort => '13802',
Proto => 'tcp',
Resue => 1,
Listen => 1,
);
if ( ! $conn ) {
die "Can't created a proxy!\n";
} else {
return $conn;
}
}
my $conn = Connection();
my $server = Proxy();
my $proxy = $server->accept();
my $lidegw = $conn->accept();
$conn->blocking(0);
$server->blocking(0);
while ( my $lide = <$lidegw> or my $local = <$proxy> ) {
chomp $lide;
chomp $local;
if ( $lide != '' ) {
print "from lidegw: $lide\n";
print $server "$lide\r\n";
} else {
print "from klient: $local\n";
print $conn "$local\r\n";
}
}
$lidegw, zejména
...
my $lidegw = $conn->accept();
...
while ( my $lide = <$lidegw> or my $local = <$proxy> ) {
chomp $lide;
chomp $local;
if ( $lide != '' ) {
print "from lidegw: $lide\n";
print $server "$lide\r\n";
} else {
protože to nedává smysl, na tom socketu nic nenaslouchá.
Tiskni
Sdílej: