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.
Apr 2 02:58:34 server1 postfix/smtpd[723]: warning: SASL authentication failure: cannot connect to saslauthd server: Connection refused Apr 2 02:58:34 server1 postfix/smtpd[723]: warning: SASL authentication failure: Password verification failed Apr 2 02:58:34 server1 postfix/smtpd[723]: warning: unknown[192.168.3.101]: SASL PLAIN authentication failed Apr 2 02:58:34 server1 postfix/smtpd[723]: warning: SASL authentication failure: cannot connect to saslauthd server: Connection refused Apr 2 02:58:34 server1 postfix/smtpd[723]: warning: unknown[192.168.3.101]: SASL LOGIN authentication failedNevite nekdo kde delam chybu ???
Apr 2 13:04:28 server1 postfix/smtpd[21790]: NOQUEUE: reject: RCPT from mail.tiscali.cz[213.235.135.69]: 554 <mail.tiscali.cz[213.235.135.69]>: Client host rejected: Access denied; from=<cz373923@tiscali.cz> to=<petr.haton@unicov-net.com> proto=ESMTP helo=<mail.tiscali.cz> Apr 2 13:04:28 server1 postfix/smtpd[21790]: disconnect from mail.tiscali.cz[213.235.135.69]Jeste prikladam konfiguraci main.cf
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
myhostname = mail.unicov-net.com
mydomain = unicov-net.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = @mydomain
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, krs-unicov.cz
relayhost =
mynetworks = 127.0.0.0/8, 192.168.1.0/22, 192.168.2.0/22, 192.168.3.0/22
#mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/
alias_maps = mysql:/etc/postfix/mysql-aliases.cf
relocated_maps = mysql:/etc/postfix/mysql-relocated.cf
transport_maps = mysql:/etc/postfix/mysql-transport.cf
virtual_maps = mysql:/etc/postfix/mysql-virtual.cf mysql:/etc/postfix/mysql-email.cf
mysql:/etc/postfix/mysql-trash.cf
local_recipient_maps = $alias_maps $virtual_mailbox_maps unix:passwd.byname
virtual_mailbox_base = /home/virtual
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-maps.cf
virtual_uid_maps = mysql:/etc/postfix/mysql-virtual-uid.cf
virtual_gid_maps = mysql:/etc/postfix/mysql-virtual-gid.cf
smtpd_recipient_restrictions = check_recipient_access mysql:/etc/postfix/mysql-recipient.cf,
reject_unknown_sender_domain,
permit_mynetworks,
permit_sasl_authenticated,
check_relay_domains,
reject
smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = mail.unicov-net.com
broken_sasl_auth_clients = yes
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject
START=yes PARAMS="-r -m /var/spool/postfix/var/run/saslauthd" MECHANISMS="pam"Adresář /var/spool/postfix/var/run/saslauthd si vytvořte, protože zřejmě nebude existovat. Během hraní s saslauth jsem si ještě udělal symlink ln -s /var/spool/postfix/var/run/saslauthd /var/run/saslauthd. Co ti nahlásí následující příkaz?
testsaslauthd -u uzivatel -p heslo -f /var/spool/postfix/var/run/saslauthd/mux
testsaslauthd -u petr.haton -p heslo -f /var/spool/postfix/var/run/saslauthd/mux to jiste i testsaslauthd -u petr.haton@unicov-net.com -p heslo -f /var/spool/postfix/var/run/saslauthd/muxhlasi:
0: NO "authentication failed"v /etc/default/saslauthd mam cestu nastavenou spravne i to -r ktere by tam melo byt.
May 14 12:10:02 server1 saslauthd[15215]: (pam_unix) check pass; user unknown May 14 12:10:02 server1 saslauthd[15215]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= May 14 12:10:04 server1 saslauthd[15215]: DEBUG: auth_pam: pam_authenticate failed: User not known to the underlying authentication module May 14 12:10:04 server1 saslauthd[15215]: do_auth : auth failure: [user=petr.haton@unicov-net.com] [service=imap] [realm=] [mech=pam] [reason=PAM auth error]muzete me nekdo trknout jestli je opravdu chyba v pam a napojeni na MySQL ????
auth required pam_unix.so nullok account required pam_unix.so password required pam_unix.so session required pam_unix.sosice netusim proc by si to chtelo brat ze souboru imap. predpokladal jsem ze si to bude brat ze smtp kde je nastavenej modul pam_mysql a pristup do databaze
auth sufficient pam_mysql.so user=DBUZIVATEL passwd=DBHESLO host=localhost \ db=postfix table=postfix_users usercolumn=email passwdcolumn=clearjelikoz ten chce hesla v nazasifrovane podobe a ja vyuzivam hesla zasifrovana. pokud system chtel overovat vzal si tenhle radek a ten vyhodnotil spatne tak se se mnou odmital uz dal bavil. po vymazani tohoto radku ze smtp vse funguje jak ma
Tiskni
Sdílej: