OpenSUSE Leap 16.1

Post Syndicated from daroc original https://lwn.net/Articles/1105131/

The openSUSE project has announced the release of openSUSE Leap 16.1. The release is notable for allowing both traditional installations and immutable images with transactional updates. While immutable images had previously been available for Leap Micro, they are now available across all platforms that Leap supports, including servers, desktops, and virtual machines.

“Leap’s image gives the best of both for traditional and immutable users, and we expect that Tumbleweed will follow when Agama becomes the default installer for Tumbleweed as well.” said Leap release manager Lubos Kocman. “The Leap Micro experience people relied on is still here, but now it shares the same release, the same life cycle and the same maintenance updates as the rest of Leap, so users only have to pick the mode that fits their workload.”

[$] LLM reviews for Debian’s new queue spark debate

Post Syndicated from jzb original https://lwn.net/Articles/1103674/

The Debian project has wrestled with the topic of LLM usage for years, which
culminated in a general-resolution
vote
this August. The project voted in favor of the fifth, out of
eight, option: “Responsible Use of
Generative AI
“. With the door open to LLM use, the DFSG, Licensing & New Packages
Team
(usually shortened to “DFSG team”), which is relatively new, has started to employ LLMs in
sending out reviews of packages entering Debian’s new queue. The practice has
raised a number of objections and questions about where lines should be drawn in
the use of LLM-generated output.

Fedora Linux 45 released

Post Syndicated from jzb original https://lwn.net/Articles/1105121/

Fedora Linux
45
has been released. This includes all editions: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Server, Fedora Cloud, Fedora CoreOS, and Fedora IoT, as well as the Atomic Desktops and Spins.

This release adds support for installation
on Stratis storage
using Anaconda or Kickstart installs, retires
unmaintained VPN plugins
for NetworkManager, and updates Fedora’s desktop
environments, developer toolchains, and system packages. See the Fedora wiki
ChangeSet page
for a list of major changes.

Security updates for Tuesday

Post Syndicated from jzb original https://lwn.net/Articles/1105111/

Security updates have been issued by AlmaLinux (bind, bind9.16, firefox, freerdp, ghostscript, kernel, kernel-rt, libXi, perl-YAML:1.24, perl:5.32, pipewire, qt5-qtbase, redis:6, tomcat, and wireshark), Debian (chromium, git-annex, incus, kernel, and strongswan), Fedora (barman, erlang-hex_core, glib-networking, kernel, knot, liblerc, libsoup3, mingw-cfitsio, openjpeg, perl-libnet, pipx, python-pillow, python-uv-build, radicale, ruff, rust-archive-trait, rust-astral-ini, rust-astral-mail-headers, rust-astral-pubgrub, rust-astral-version-ranges, rust-astral_async_zip, rust-quick-junit, rust-tar-codec, rust-tar-framing, tpm2-tss, ty, uv, and zvbi), Mageia (unbound), Red Hat (buildah, compat-openssl10, compat-openssl11, container-tools:rhel8, delve, golang-github-openprinting-ipp-usb, grafana, grafana-pcp, kernel, oci-seccomp-bpf-hook, openssl, opentelemetry-collector, osbuild-composer, podman, rhc, and skopeo), Slackware (expat), SUSE (ansible-core, apache-arrow, apache-commons-codec, apache-commons-io, apache-commons- logging, avalon-framework, avalon-logkit, glassfish-jsp, jsch, maven-file- management, opentest4j, aws-nitro-enclaves-cli, bouncycastle, chromedriver, chromium, cifs-utils, expat, firefox, gcc48, ghostscript, GraphicsMagick, guava, j2objc-annotations, gvfs, ImageMagick, in-toto, libsoup, nodejs22, nodejs24, praat, python-Pillow, python-PyJWT, python-soupsieve, python-sqlparse, python313-OpenEXR, python313-vllm, rootlesskit, and rqlite), and Ubuntu (kernel, linux, linux-aws, linux-aws-5.15, linux-aws-fips, linux-azure, linux-azure-5.15, linux-azure-fde-5.15, linux-azure-fips, linux-fips, linux-gcp, linux-gcp-5.15, linux-gcp-fips, linux-gke, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-intel-iot-realtime, linux-intel-iotg, linux-intel-iotg-5.15, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-oracle, linux-oracle-5.15, linux-realtime, linux, linux-aws, linux-aws-fips, linux-azure, linux-azure-5.4, linux-azure-fips, linux-fips, linux-gcp, linux-gcp-5.4, linux-gcp-fips, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-iot, linux-kvm, linux-oracle, linux-oracle-5.4, linux-xilinx-zynqmp, linux, linux-aws, linux-fips, linux-kvm, linux-lts-xenial, linux, linux-aws, linux-gcp, linux-hwe-7.0, linux-ibm, linux-oracle, linux-aws, linux-azure-fde, linux-bluefield, linux-nvidia-tegra, linux-nvidia-tegra-5.15, linux-nvidia-tegra-igx, and linux-oem-7.0).

Introducing Zero Wire, a hub for investigating critical Internet vulnerabilities

Post Syndicated from Daniele Molteni original https://blog.cloudflare.com/zero-wire/

You run security at your organization. It’s 7:00 am, and you’re having breakfast. You receive a ping: a new critical vulnerability has been disclosed. Your team scrambles to compare vendor advisories, read technical research, check which systems run the affected software, and answer familiar questions from the business: are we affected, and what are we doing about it? Another disclosure arrives before that work is finished.

AI is changing both the volume and speed of critical vulnerability discovery. It can analyze large codebases at scale and surface deeply nested flaws that may have existed for years without being found through human review. That discovery momentum will put more pressure on security teams to understand the impact of each disclosure on their infrastructure.

To help security teams prepare, today we’re introducing Zero Wire: a public vulnerability intelligence feed on Cloudflare Radar, bringing the clarity of a news wire service to critical security developments. It helps security leaders and practitioners understand significant vulnerabilities and decide what to do next.

How it works

Zero Wire lives inside Cloudflare Radar under the security section.

Each briefing brings together a plain-language explanation of the vulnerability, who should investigate it, recommended actions, and links to the evidence and vendor guidance. The format is deliberately simple: an index card with what you need to know, without the drama. A CISO should be able to understand the issue quickly and ask the right questions. An engineer should be able to follow the same briefing to the technical guidance needed to investigate and remediate it.

We also offer a pre-compiled prompt you can use with your agent to assess the impact on your infrastructure. Cloudflare contributes security research, observations from our network, and practical knowledge of the controls that can help reduce exposure. The information is useful whether or not you are a Cloudflare customer. 

Zero Wire brings that context together with authoritative external sources, giving readers a starting point for assessment and a place to return as an issue develops.

Our focus

Rather than a catalog of every CVE, Zero Wire complements vendor advisories and vulnerability databases, linking readers to the evidence and technical guidance needed to act. Zero Wire focuses on critical CVEs in Internet-facing software, such as vulnerabilities in web applications, the runtimes and libraries they depend on, and services exposed to the Internet, where a proxy can help mitigate exploitation.

We select significant issues that security teams need to understand and assess. Each briefing explains the potential impact, which deployments should be investigated, what is known about exploitation, and the available mitigation and patching guidance. A vulnerability’s severity and evidence of active exploitation are distinct: readers need both to make informed decisions.

A dedicated Cloudflare protection, such as Web Application Firewall (WAF) rules, is not a prerequisite for inclusion. Some issues require vendor updates or changes beyond the traffic Cloudflare can inspect. Where Cloudflare controls can help, we explain their scope and configuration requirements.

A walk through Zero Wire

Start on the Zero Wire homepage. Each card introduces an issue, identifies associated CVEs where applicable, and summarizes why it matters and what to do. You can search for a published briefing using a CVE or issue name, and follow technology tags to related entries. One briefing can cover several related CVEs when understanding them together makes the response clearer.

Find what needs attention

The homepage separates briefings into two categories. “Needs attention” brings together issues requiring active assessment or action, including those with known exploitation or developing guidance. “Reference” keeps briefings available when guidance has stabilized. Moving to “Reference” does not mean every affected system has been patched: an older vulnerability can still matter to an organization that has not completed remediation.

The status and last-checked date help you interpret each card. Known exploitation, an ongoing investigation, and an available vendor fix describe different things. Read them alongside the briefing’s evidence rather than treating them as a verdict on your own environment.

Understand what happened and who should investigate

When you open a briefing, the overview tells you what happened, why it deserves attention, and which teams should investigate. The explanation connects the technical issue to its practical consequences, such as service disruption or risk of data exposure.

For example, the recent php2shell vulnerability concerns flaws in the PHP runtime. That distinction matters for teams running applications such as WordPress or Magento: updating application code or a plugin alone does not repair the underlying runtime. The briefing helps readers identify the right system owners and directs them to the PHP security guidance for affected versions and remediation.

Turn the briefing into an action plan

What to do now gives your team a short set of next steps. Depending on the issue, that can mean identifying affected deployments, checking versions with a hosting provider, applying vendor updates, reviewing suspicious activity, or keeping compensating controls in place while patching.

The purpose is to make the next conversation concrete. For a PHP deployment, ask which runtime is actually running, whether the vendor’s fix has been applied, and who owns the update. Follow the linked vendor advisory for detailed applicability and remediation instructions, which can change as the investigation develops.

Assess your exposure with an AI agent

In this section, we share a prompt that can be used with your AI agent to quickly assess the impact on your infrastructure. The prompt asks for a read-only assessment of deployed software, relevant vendor fixes, exposure, and compensating controls, with per-asset evidence, unknowns, and next actions. It helps your team investigate its own environment; copying the prompt does not itself scan or change systems.

Check the evidence and follow what changed

To help you learn more about the vulnerability, each briefing links to external documents such as CVE records, research, and relevant exploitation evidence, including CISA’s Known Exploited Vulnerabilities Catalog. These sources answer different questions. A vendor advisory establishes affected versions and remediation guidance. An exploitation report provides evidence of attacker activity. 

If applicable to a briefing, Cloudflare can add context about traffic seen on our network, for example by showing traffic matching WAF rules that indicates exploitation attempts. Those distinctions matter. Observing an attack attempt does not establish that a particular organization was compromised. Equally, a lack of observed attempts on Cloudflare’s network does not establish that exploitation is absent elsewhere. Briefings distinguish what the sources establish from what remains unknown.

Where available, charts add context to that evidence. The php2shell briefing shows the volume of HTTP requests matching Cloudflare WAF managed rules over time. Note that requests matching these rules are not a count of compromised systems or successful exploits; the chart aims at providing practitioners a sense of what the focus level is by threat actors on a particular vulnerability.

Finally, update chronology records important developments, such as new advisories or changes to the evidence and response guidance. Together with the last-checked date, it helps returning readers understand what has changed since their previous visit.

Understand Cloudflare’s role

The Cloudflare section provides links to whether we offer compensating controls or provide a way to mitigate the vulnerability impact on your infrastructure. 

If a particular CVE can be addressed with a WAF rule, the briefing reports its availability and essential configuration requirements. When applicable, paid Plans and free Plans links take customers to the relevant dashboard configuration. The next step is explicit: “Review your WAF configuration to determine whether you are protected”. A link allows you to review your security posture, it does not automatically enable a rule or verify a deployment.

Note that a WAF mitigation is a compensating control for the traffic it covers, it is not a replacement for fixing vulnerable software. Blocking the requests can prevent exposed data from reaching an attacker, but it cannot undo actions already performed at the origin. The security teams should always follow the vendor remediation guidance.

Stay informed with Zero Wire

A useful vulnerability briefing should leave you with a clearer understanding of the issue and a concrete next step. Day Zero brings those essentials together: what happened, who should investigate, what to do now, and where to find the evidence.

Visit Zero Wire vulnerability intelligence, share the relevant briefings with the teams responsible for your systems, and return for new entries and updates. When the next disclosure arrives, we want you to spend less time assembling the basic facts and more time acting on them.

Follow Cloudflare Radar on X @CloudflareRadar and Bluesky @radar.cloudflare.com for updates.

AIs Hacking the Law

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/11/ais-hacking-the-law.html

In both a 2021 essay and my 2022 book, A Hacker’s Mind, I talk about AIs finding vulnerabilities and exploits—hacking—the legal system.

Here’s some demonstrations of this from Germany:

Legal systems encode the foundations of social order in natural language. Similar to computer systems, the written law can contain vulnerabilities that invite exploitation.1 Courts absorb most exploits through interpretation, and such vulnerabilities rarely surface in the first place. With highly capable AI systems enabling the discovery of vulnerabilities at unprecedented scale, we believe the latter could change.

In testing this hypothesis, we have identified a substantial number of vulnerabilities in the German legal system using LLMs. To our knowledge, none of these have been previously recorded. We share a selection of vulnerabilities below, and present potential exploits for each. We share only those vulnerabilities whose exploitation we believe would not cause serious harm.

We believe that with cheap legal reasoning proliferating, AI systems could jeopardize the functioning of today’s legal systems. In such a world, lawmakers would need to significantly harden the process of legislation, for example by leveraging advanced AI themselves.

Still in its early stages, but definitely something that’s coming.

Бомбоубежища за 1%

Post Syndicated from Александър Малинов original https://www.toest.bg/bomboubezhishta-za-1-procent/

Бомбоубежища за 1%

България не е във война, поне официално. Липсата на формално обявена война обаче не пречи на Русия вече почти пет години да убива цивилни и да разрушава градове и села в Украйна. От години насам България като важна част от обединена Европа и НАТО също е жертва на руска агресия под формата на информационна война, саботажи и политическа намеса. През октомври 2026 г. това се промени, след като Русия засили военния си натиск върху България. 

На 6, 13 и 28 октомври близо до българския бряг няколко търговски кораба бяха ударени от руски дронове, а над 20 души от екипажите им загинаха. България ще се сблъсква с все повече преки военни заплахи и инциденти, а междувременно инфраструктурата ни за гражданска защита остава критично неподготвена. В това отношение се вижда рязък контраст с други европейски държави, които активно подготвят населението си за действие по време на криза, включително и война.

Как е в Европа?

В отговор на ескалиращата руска агресия срещу Европа много държави предприеха спешни мерки – от обновяване на укритията до масово разпространение на ръководства за оцеляване за всяко домакинство.

В Полша подготовката на гражданското общество премина от формални административни прегледи към мащабна трансформация. Страната прие фундаментални законодателни промени, задължаващи строителния сектор и частните инвеститори да интегрират защитни съоръжения и подземни бункери в нови обществени и многофамилни сгради. Чрез националната програма за защита на населението и гражданска отбрана Варшава задели милиарди злоти за реновиране на съществуващи укрития и изграждане на нови пространства за сигурност, а финансовите параметри на тези проекти достигат мащаби от десетки милиарди евро за следващия петгодишен цикъл. 

Полските власти не просто инспектират мазета и подземни паркинги, а създават национална мрежа от самостоятелни убежища със системи за филтровентилация, водоснабдяване и електрозахранване и развиват система за ранно предупреждение при ракетен и дронов удар.

Подобни действия се наблюдават и в балтийските страни – Естония, Латвия и Литва, чиито правителства третират гражданската отбрана като пряко продължение на военната си доктрина. Латвия започна мащабни инициативи, подкрепени с милионни европейски и общински инвестиции, за трансформиране на хиляди сгради в защитни убежища (само в столицата Рига се разработват проекти за сигурност на десетки хиляди граждани). 

Литва и Естония от своя страна залагат на тотална децентрализация на информацията: стотици хиляди домакинства преди време получиха директно в домовете си специализирани ръководства за оцеляване в условия на криза, обсада или окупация, съдържащи детайлни инструкции за поведение при военен конфликт и съпротива. 

Брошурата, раздадена на населението на Литва, информира, че граждани, попаднали под чужда окупация, имат право да извършват саботажи срещу окупационните сили и че 

при настъпила окупация всяка информация за капитулиране на литовските сили би била фалшива. 

Швеция, Норвегия и Дания разпространиха обновени брошури за гражданите с ясни инструкции при военен конфликт. В шведското ръководство за оцеляване категорично се заявява: 

Ако Швеция бъде нападната, никога няма да се предадем.

По подобие на страните от Северна Европа, през миналата година Чехия раздаде над 5 млн. брошури, които стигнаха до всяко домакинство, и пусна специален уебсайт с инструкции за оцеляване през първите 72 часа на криза, включваща прекъсване на електричеството, интернет и останалите комуникации.

Породената от руската агресия срещу Украйна активна подготовка на населението за оцеляване в криза е приоритет не само за Източна Европа. В западната част на континента държавните власти също обновиха готовността си – както що се отнася до скривалища и бомбоубежища, така и по отношение на комуникацията с населението. 

Германия предприе спешна реформа в своята политика за сигурност, започвайки изпълнението на дългосрочен план на стойност милиарди евро за преоборудване и адаптация на съществуващата подземна инфраструктура. Берлин съсредоточава усилията си върху спешни ремонти на бункери от Студената война и трансформирането на метростанции, подземни тунели и паркинги, мазета в надеждни защитни пространства, които могат да служат за скривалища. В допълнение федералните власти активно модернизират националната мрежа за ранно предупреждение на гражданите.

Нидерландия, Франция и Белгия залагат на превантивната информираност и масовото ангажиране на самите граждани. В Нидерландия например правителството започна мащабна национална кампания чрез изпращане на специални ръководства на милиони домакинства, даващи ясни указания как всяко семейство да състави собствен план за действие и да подготви тридневни запаси от вода, консерви, медикаменти и алтернативни източници на светлина и топлина. Подобни инициативи бяха реализирани и от френските и белгийските власти през националните кризисни центрове с цел повишаване на устойчивостта срещу хибридни атаки, киберзаплахи и мащабни прекъсвания на комуникациите.


/* ———- ОБЩО за всички инфографики (.tst-ig) ———- */
.tst-ig,
.tst-ig * {
box-sizing: border-box;
margin: 0;
padding: 0;
border: 0;
text-transform: none;
letter-spacing: 0;
text-decoration: none;
text-indent: 0;
}
.tst-ig {
–tst-ink: #000;
–tst-white: #fff;
–tst-shape: #e8e8e8; /* сивото на картите и на „празните” кръгчета */
–tst-radius: 20px;
–tst-accent: #D92B36; /* акцентът на Тоест (цветът на точките и на запълнените кръгчета) */
display: block;
width: 100%;
margin: 24px 0;
padding: 8px 0;
color: var(–tst-ink);
font-weight: 700;
font-style: normal;
font-size: 15px;
line-height: 1.3;
text-align: left;
overflow: visible;
}
.tst-ig-title { display: block; text-align: center; margin-bottom: 24px; }

/* =====================================================================================
КАРТА НА ЕВРОПА (.tst-map) — кликаш държава → излиза балонче с текст
===================================================================================== */
.tst-map {
–tst-map-idle: #ee9aa0; /* кликаемите държави — по-бледо червено */
–tst-map-hover: #e56a73;
}
.tst-map-hint { margin: -12px 0 14px; text-align: center; font-weight: 500; font-size: 13px; }
.tst-map-texts { display: none; } /* текстовете се четат от скрипта и излизат в балончето */
.tst-map-stage { position: relative; max-width: 760px; margin: 0 auto; }
.tst-map-svg { display: block; width: 100%; height: auto; }
.tst-map-bg { fill: var(–tst-shape); stroke: #fff; stroke-width: 1; stroke-linejoin: round; fill-rule: evenodd; }
.tst-map-c path {
fill: var(–tst-map-idle);
stroke: #fff;
stroke-width: 1;
stroke-linejoin: round;
cursor: pointer;
transition: fill 0.2s;
}
@media (hover: hover) { .tst-map-c:hover path { fill: var(–tst-map-hover); } }
.tst-map-c.is-active path { fill: var(–tst-accent); }
.tst-map-c:focus { outline: none; }
.tst-map-c:focus-visible path { stroke: var(–tst-ink); stroke-width: 2; }

.tst-map-bubble {
position: absolute;
left: 0;
top: 0;
z-index: 2;
width: 290px;
max-width: calc(100% – 16px);
padding: 16px 18px 18px;
background: var(–tst-white);
border-radius: 18px;
box-shadow: 0 6px 24px rgba(0, 0, 0, 0.15);
pointer-events: none;
}
.tst-map-bubble[hidden] { display: none; }
.tst-map-name { font-size: 17px; line-height: 1.2; }
.tst-map-body { margin-top: 8px; font-weight: 500; font-size: 15px; line-height: 1.4; }
.tst-map-tail {
position: absolute;
bottom: -7px;
left: 20px;
width: 16px;
height: 16px;
background: var(–tst-white);
transform: rotate(45deg);
border-radius: 0 0 3px 0;
}
.tst-map-bubble.is-below .tst-map-tail { bottom: auto; top: -7px; border-radius: 3px 0 0 0; }

.tst-map.is-armed:not(.is-done) .tst-map-bg,
.tst-map.is-armed:not(.is-done) .tst-map-c { opacity: 0; }

/* =====================================================================================
ФИНЛАНДИЯ СРЕЩУ БЪЛГАРИЯ (.tst-fin) — по 100 кръгчета (1 кръгче = 1% от населението)
===================================================================================== */
.tst-fin { –tst-fin-d: 20px; –tst-fin-gap: 6px; }
.tst-fin-parts { display: flex; flex-wrap: wrap; justify-content: center; gap: 40px 64px; }
.tst-fin-part { width: calc(var(–tst-fin-d) * 10 + var(–tst-fin-gap) * 9); max-width: 100%; }
.tst-fin-top { display: flex; align-items: baseline; justify-content: space-between; margin-bottom: 16px; }
.tst-fin-country { font-size: 18px; }
.tst-fin-num { font-size: 42px; line-height: 1; }
.tst-fin-grid {
display: grid;
grid-template-columns: repeat(10, var(–tst-fin-d));
gap: var(–tst-fin-gap);
}
.tst-fin-dot {
position: relative;
width: var(–tst-fin-d);
height: var(–tst-fin-d);
border-radius: 50%;
background: var(–tst-shape);
overflow: hidden;
}
.tst-fin-glow { /* цветната част; JS я добавя във всяко „пълно” кръгче */
position: absolute;
left: 0; top: 0; bottom: 0;
width: var(–tst-fin-p, 100%); /* при частично кръгче (напр. 0,5) е по-тясна */
background: var(–tst-accent);
}
.tst-fin-note { margin-top: 16px; font-weight: 500; font-size: 15px; line-height: 1.4; }
.tst-fin-legend { margin-top: 28px; text-align: center; font-weight: 500; font-size: 13px; }

.tst-fin-part.is-armed:not(.is-done) .tst-fin-dot { opacity: 0; }
.tst-fin-part.is-armed:not(.is-done) .tst-fin-glow { clip-path: inset(0 100% 0 0); }
.tst-fin-part.is-armed:not(.is-done) .tst-fin-country,
.tst-fin-part.is-armed:not(.is-done) .tst-fin-num { clip-path: inset(0 100% 0 0); }
.tst-fin-part.is-armed:not(.is-done) .tst-fin-note { opacity: 0; }


<!– =====================================================================================
[B] КАРТА НА ЕВРОПА — как се подготвя Европа
Копирай от тук до „КРАЙ КАРТА".
РЕДАКТИРАШ САМО текстовете в блока „ТЕКСТОВЕ" (име и текст на всяка държава/група).
Блокът с картата () НЕ СЕ ПИПА. data-group в двата блока трябва да съвпада.
Групите се оцветяват заедно: Естония+Латвия+Литва, Швеция+Норвегия+Дания, Нидерландия+Франция+Белгия.
===================================================================================== –>

Как се подготвя Европа
Натисни върху държава

Полша
Нови обществени и многофамилни сгради задължително се строят с убежища. Милиарди злоти за обновяване и нови укрития.

Естония, Латвия, Литва
Ръководства за оцеляване в стотици хиляди домакинства. В Латвия хиляди сгради стават убежища.

Швеция, Норвегия, Дания
Обновени брошури за гражданите с ясни инструкции при военен конфликт

Чехия
Над 5 млн. брошури за всяко домакинство и сайт с инструкции за първите 72 часа на криза

Германия
План за милиарди евро: ремонт на бункери от Студената война, метростанции, тунели и паркинги като скривалища

Нидерландия, Франция, Белгия
Национални кампании: всяко семейство съставя план за действие и си осигурява тридневни запаси

Финландия
Над 50 000 убежища с капацитет 4,8 млн. души

България
247 напълно годни убежища с капацитет около 60 000 души


Що се отнася до покритие и достъп до бункери, абсолютният лидер е Финландия. 

Страната разполага с над 50 000 убежища за гражданска защита с капацитет от 4,8 млн. души – значителна част от населението ѝ, което наброява близо 5,7 милиона. Повечето от тях са частни стоманобетонни скривалища, разположени в отделни сгради. В съчетание със задължителните бомбоубежища в мазетата на жилищните кооперации капацитетът в столицата Хелзинки надхвърля 700 000 души, каквото е населението на града.

Как е в България?

В цялата страна официално регистрираните и напълно годни да изпълнят своето предназначение защитни скривалища са едва 247. Това става ясно от данни на отдел „Превантивна дейност“ в Главна дирекция „Пожарна безопасност и защита на населението“, представени пред БНР. Общият капацитет на тези съоръжения позволява едновременно да бъдат укрити максимум около 60 000 души, или по-малко от 1% от постоянно живеещите в страната.

Според същите данни при евентуална извънредна ситуация най-мащабно укриване на населението в градски условия би могло да се осъществи в станциите на метрото в София. 


Каква част от населението може да се скрие в убежище
Финландия
84%

Убежища за 4,8 млн. души при около 5,7 млн. население

България
<1%

247 годни убежища с капацитет около 60 000 души

1 кръгче = 1% от населението



(function () {
‘use strict’;

/* ===== ОБЩО ===== */
var reduceMotion = window.matchMedia && window.matchMedia(‘(prefers-reduced-motion: reduce)’).matches;
var canAnimate = typeof Element !== ‘undefined’ && typeof Element.prototype.animate === ‘function’;
function qs(root, sel) { return root.querySelector(sel); }
function qsa(root, sel) { return Array.prototype.slice.call(root.querySelectorAll(sel)); }
function noop() {}
var WIPE_FROM = ‘inset(0 100% 0 0)’;
var WIPE_TO = ‘inset(0 0 0 0)’;

function onceInView(el, threshold, cb) {
if (!(‘IntersectionObserver’ in window)) { cb(el); return; }
var io = new IntersectionObserver(function (entries) {
entries.forEach(function (e) {
if (e.isIntersecting) { io.unobserve(e.target); cb(e.target); }
});
}, { threshold: threshold });
io.observe(el);
}

/* пуска елементите един след друг: всеки чака да е в екрана И предишният да е стигнал до „реда” си.
play(el) връща след колко ms да тръгне следващият. */
function sequence(items, threshold, play) {
var prev = Promise.resolve();
items.forEach(function (it) {
var seen = new Promise(function (res) { onceInView(it, threshold, res); });
prev = Promise.all([prev, seen]).then(function () {
var wait = play(it) || 0;
return new Promise(function (res) { setTimeout(res, wait); });
});
});
}

/* събира анимациите и при край маха началното състояние (is-armed) */
function makeRunner(root, defaultEase) {
var anims = [];
function run(el, keyframes, delay, duration, easing) {
var a = el.animate(keyframes, { delay: delay, duration: duration, easing: easing || defaultEase, fill: ‘both’ });
anims.push(a);
return a;
}
function finish() {
Promise.all(anims.map(function (a) { return a.finished; })).then(function () {
root.classList.add(‘is-done’);
anims.forEach(function (a) { try { a.cancel(); } catch (e) { noop(); } });
}).catch(noop);
}
return { run: run, finish: finish };
}

var EASE_OUT = ‘cubic-bezier(0.22, 0.8, 0.26, 1)’;
var EASE_POP = ‘cubic-bezier(0.34, 1.56, 0.64, 1)’;

/* =====================================================================================
КАРТА НА ЕВРОПА (.tst-map) — влизане на картата + клик върху държава → балонче
===================================================================================== */
var MAP = {
threshold: 0.3,
bgMs: 600,
groupDelay: 300, // кога тръгват държавите
groupStep: 110, // пауза между групите
groupMs: 500,
bubbleMs: 260
};

function mapSetup(root) {
var stage = qs(root, ‘.tst-map-stage’);
var svg = qs(root, ‘.tst-map-svg’);
var bubble = qs(root, ‘.tst-map-bubble’);
var bName = qs(bubble, ‘.tst-map-name’);
var bBody = qs(bubble, ‘.tst-map-body’);
var groups = qsa(root, ‘.tst-map-c’);
var texts = {};
qsa(root, ‘.tst-map-text’).forEach(function (t) {
texts[t.getAttribute(‘data-group’)] = {
name: (qs(t, ‘.tst-map-name’) || {}).textContent || ”,
body: (qs(t, ‘.tst-map-body’) || {}).textContent || ”
};
});
var active = null;
var FULL_VIEW = svg.getAttribute(‘viewBox’);
/* компютър с мишка: балончето излиза при посочване; телефон/таблет: при докосване */
var canHover = !!(window.matchMedia && window.matchMedia(‘(hover: hover) and (pointer: fine)’).matches);

/* на тесен екран (телефон/приложение) приближаваме към Европа, за да са държавите по-големи */
function applyView() {
var narrow = stage.clientWidth < 560;
svg.setAttribute('viewBox', narrow ? '130 90 520 540' : FULL_VIEW);
}
applyView();

/* намира държавата под пръста; ако докосването е „до" държава (малките са тесни), взема най-близката */
function groupAt(x, y) {
var offs = [[0, 0], [10, 0], [-10, 0], [0, 10], [0, -10], [14, 14], [-14, 14], [14, -14], [-14, -14], [20, 0], [-20, 0], [0, 20], [0, -20]];
for (var i = 0; i < offs.length; i++) {
var el = document.elementFromPoint(x + offs[i][0], y + offs[i][1]);
var g = el && el.closest ? el.closest('.tst-map-c') : null;
if (g && root.contains(g)) { return g; }
}
return null;
}

function place() {
if (!active) { return; }
var vb = svg.viewBox.baseVal;
var sw = stage.clientWidth, sh = stage.clientHeight;
var kx = sw / vb.width, ky = svg.getBoundingClientRect().height / vb.height;
var bb = active.getBBox();
var cx = (bb.x – vb.x + bb.width / 2) * kx;
var top = (bb.y – vb.y) * ky, bottom = (bb.y – vb.y + bb.height) * ky;
var w = bubble.offsetWidth, h = bubble.offsetHeight;
var left = Math.max(8, Math.min(cx – w / 2, sw – w – 8));
var below = top – h – 14 < 0;
var y = below ? bottom + 14 : top – h – 14;
y = Math.max(0, Math.min(y, sh – h));
bubble.style.left = left + 'px';
bubble.style.top = y + 'px';
bubble.classList.toggle('is-below', below);
var tx = Math.max(24, Math.min(cx – left, w – 24));
bubble.querySelector('.tst-map-tail').style.left = (tx – 8) + 'px';
bubble.style.transformOrigin = tx + 'px ' + (below ? '0' : '100%');
}

function close() {
if (active) { active.classList.remove('is-active'); }
active = null;
bubble.hidden = true;
}

function select(g) {
var t = texts[g.getAttribute('data-group')];
if (!t) { return; }
if (active) { active.classList.remove('is-active'); }
active = g;
g.classList.add('is-active');
bName.textContent = t.name;
bBody.textContent = t.body;
bubble.style.visibility = 'hidden';
bubble.hidden = false;
place();
bubble.style.visibility = '';
if (canAnimate && !reduceMotion) {
bubble.animate([{ opacity: 0, transform: 'scale(0.92)' }, { opacity: 1, transform: 'scale(1)' }],
{ duration: MAP.bubbleMs, easing: EASE_POP });
}
}

groups.forEach(function (g) {
g.setAttribute('tabindex', '0');
g.setAttribute('role', 'button');
var t = texts[g.getAttribute('data-group')];
if (t) { g.setAttribute('aria-label', t.name); }
g.addEventListener('click', function (e) { e.stopPropagation(); if (active !== g) { select(g); } });
if (canHover) {
g.addEventListener('mouseenter', function () { if (active !== g) { select(g); } });
g.addEventListener('mouseleave', function () { if (active === g) { close(); } });
}
g.addEventListener('keydown', function (e) {
if (e.key === 'Enter' || e.key === ' ') { e.preventDefault(); select(g); }
if (e.key === 'Escape') { close(); }
});
});
stage.addEventListener('click', function (e) { // клик до държава → избира я; клик другаде → балончето се скрива
var g = groupAt(e.clientX, e.clientY);
if (g) { select(g); } else { close(); }
});
window.addEventListener('resize', function () { applyView(); place(); });

if (reduceMotion || !canAnimate) { return; }
root.classList.add('is-armed');
onceInView(root, MAP.threshold, function () {
var R = makeRunner(root, EASE_OUT);
R.run(qs(root, '.tst-map-bg'), [{ opacity: 0 }, { opacity: 1 }], 0, MAP.bgMs);
groups.forEach(function (g, i) {
R.run(g, [{ opacity: 0 }, { opacity: 1 }], MAP.groupDelay + i * MAP.groupStep, MAP.groupMs);
});
R.finish();
});
}

/* =====================================================================================
ФИНЛАНДИЯ СРЕЩУ БЪЛГАРИЯ (.tst-fin) — първо кръгчетата едно след друго (сиви),
после цветът се „пали" в цветните, докато излиза числото. После втората част.
===================================================================================== */
var FIN = {
threshold: 0.5,
dotStep: 9, // пауза между кръгчетата
dotMs: 350,
glowLead: 200, // цветът тръгва толкова след последното кръгче
glowStep: 10, // пауза между цветните кръгчета
glowMs: 450,
wordMs: 500,
noteDelay: 350,
next: 500 // след колко ms от старта на цвета тръгва следващата част
};

/* създава кръгчетата от data-total / data-on (работи и без анимация) */
function finBuild(grid) {
if (grid.getAttribute('data-built') === '1') { return; }
var total = parseInt(grid.getAttribute('data-total'), 10);
var on = parseFloat(grid.getAttribute('data-on'));
if (!isFinite(total) || total < 1) { total = 100; }
if (!isFinite(on)) { on = 0; }
for (var i = 0; i < total; i++) {
var dot = document.createElement('div');
dot.className = 'tst-fin-dot';
if (i < on) {
var g = document.createElement('span');
g.className = 'tst-fin-glow';
var p = Math.min(1, on – i);
if (p < 1) { g.style.setProperty('–tst-fin-p', (p * 100) + '%'); }
dot.appendChild(g);
}
grid.appendChild(dot);
}
grid.setAttribute('data-built', '1');
}

function finPlay(part) {
part.classList.remove('is-done');
part.classList.add('is-armed');
var R = makeRunner(part, EASE_OUT), run = R.run;
var dots = qsa(part, '.tst-fin-dot');
var glows = qsa(part, '.tst-fin-glow');
var country = qs(part, '.tst-fin-country'), num = qs(part, '.tst-fin-num'), note = qs(part, '.tst-fin-note');

if (country) { run(country, [{ clipPath: WIPE_FROM }, { clipPath: WIPE_TO }], 0, FIN.wordMs); }
dots.forEach(function (d, i) {
run(d, [{ opacity: 0, transform: 'scale(0.3)' }, { opacity: 1, transform: 'scale(1)' }], i * FIN.dotStep, FIN.dotMs, EASE_POP);
});
var tG = Math.max(0, (dots.length – 1) * FIN.dotStep) + FIN.glowLead;
glows.forEach(function (g, k) {
run(g, [{ clipPath: WIPE_FROM }, { clipPath: WIPE_TO }], tG + k * FIN.glowStep, FIN.glowMs);
});
if (num) { run(num, [{ clipPath: WIPE_FROM }, { clipPath: WIPE_TO }], tG, FIN.wordMs); }
if (note) { run(note, [{ opacity: 0, transform: 'translateY(6px)' }, { opacity: 1, transform: 'translateY(0)' }], tG + FIN.noteDelay, 600); }
R.finish();
return tG + FIN.next;
}

function finSetup(root) {
qsa(root, '.tst-fin-grid').forEach(finBuild);
if (reduceMotion || !canAnimate) { return; }
var parts = qsa(root, '.tst-fin-part');
parts.forEach(function (p) { p.classList.add('is-armed'); });
sequence(parts, FIN.threshold, finPlay);
}

/* ===== старт ===== */
function init() {
qsa(document, '.tst-map').forEach(mapSetup);
qsa(document, '.tst-fin').forEach(finSetup);
}
if (document.readyState === 'loading') { document.addEventListener('DOMContentLoaded', init); } else { init(); }
})();

МВР обаче не потвърждава дали метростанциите отговарят на нужните изисквания. 

На този фон капацитетът на отделните специализирани подземни скривалища остава ограничен, като най-големият обект може да побере само около 300 души. Въпреки поредицата от атаки с дронове край българското крайбрежие и продължаващата война на Русия в Украйна темата за сигурността на цивилното население шокиращо остава извън дневния ред на българските политици – както в проруските среди на Радев и Костадинов, така и сред проевропейските сили. Следва незабавно да се поставят на фокус въпросите около състоянието, поддръжката и капацитета на защитната инфраструктура в страната и готовността на държавата и населението за реакция при кризисни ситуации. 

Три са насоките, които изискват спешно внимание:

Увеличаване на капацитета – спешна проверка на всички бомбоубежища от времето на Студената война в цялата страна и превръщането им в годни скривалища по примера на Германия и Полша. Одит на гражданска инфраструктура, която би могла да се ползва по време на кризи – това са метростанции, тунели и подземни гаражи. 

Институционална, политическа и обществена ангажираност – обществото не получава ясни насоки от управляващите, актуални карти на укритията или практични обучения за реакция при криза. Липсва мащабна национална кампания за подготовка на домакинствата, подобна на тези в Европа.

Разминаване с реалността – заради дребни политически интереси и нежелание на политическите сили да всяват „паника“ защитата на населението е хвърлена в кофата; не само че липсва инфраструктура и кампания за подготовка, липсват дори идеи и насоки такива да бъдат създадени.

Според премиера Радев няма място за „истерия“, когато Русия убива моряци в близост до българския бряг. Вероятно по същата причина къпещото се в похвали от Москва правителство пази гробно мълчание по темата с липсата на бомбоубежища в България и не предприема кампания за кризисна готовност на населението. Но да се подготвиш за бедствие, когато е очевидно, че то се насочва към теб, не е истерия, а елементарно чувство за самосъхранение. Ако съседската къща гори, да знаеш къде има пожарогасител или да се измъкнеш навреме е начин да останеш жив. 

Докато Европа готви своите граждани за природни бедствия, кибератаки и военен конфликт, в България институциите са безмълвни по темата, а за политическите лидери явно безопасността на хората в страната не е на дневен ред. Кой обаче ще поеме отговорност, когато ни връхлети кризата?

Marvell Proposes Acquiring Lumentum to Combine Optical Circuit Switching with AI Connectivity Silicon

Post Syndicated from Cliff Robinson original https://www.servethehome.com/marvell-to-acquire-lumentum-115-billion-optical-ai-connectivity/

Marvell announced its intention to acquire Lumentum in a $115B acquisition to further optical connectivity in the AI era

The post Marvell Proposes Acquiring Lumentum to Combine Optical Circuit Switching with AI Connectivity Silicon appeared first on ServeTheHome.

Introducing queue consumption mode for Apache Kafka in AWS Lambda

Post Syndicated from Vaibhav Jain original https://aws.amazon.com/blogs/compute/introducing-queue-consumption-mode-for-apache-kafka-in-aws-lambda/

Queue consumption mode for AWS Lambda event source mappings (ESMs) that subscribe to Apache Kafka is now available. Queue consumption mode is available on the self-managed Apache Kafka ESM. It covers both Kafka clusters you operate yourself and managed Kafka offerings such as Confluent Cloud and other providers that offer Kafka 4.2 or later with Kafka Queue support.

With this launch, you can build queue-style event-driven workloads on Kafka that process records with high parallelism that scales concurrency to match your backlog instead of your topic layout. Queue mode achieves this using Kafka Share Groups (KIP-932), introduced in Kafka 4.0. With share groups, multiple consumers read concurrently from the same partitions, so Lambda can process records from a single partition across many parallel invocations. The result is parallelism that is decoupled from partition count, without head-of-line blocking and without introducing a second messaging system into your architecture.

Many Kafka workloads treat each event as an independent unit of work rather than a step in an ordered sequence: generating image and video renditions after upload, offloading slow work from a user-facing API, scoring transactions for fraud, delivering notifications, enriching records for inference, processing bulk files, buffering ahead of a rate-limited dependency, and ingesting telemetry. Correctness for these workloads depends on processing records quickly, not in order. The Kafka consumer group protocol, however, assigns each partition to exactly one consumer, so a topic with 10 partitions supports up to 10 concurrent consumers. Over-partitioning raises that ceiling but increases broker resource usage, slows rebalances, and still leaves head-of-line blocking, where one slow record stalls every record behind it. Previously, teams moved this traffic to a separate queuing system, adding a platform to operate and new producer code.

In this post, you learn how queue consumption mode works compared to the existing stream mode, what broker and cluster requirements your Kafka 4.2 cluster must meet, and how to scale from on-demand defaults to provisioned mode for high-throughput workloads.

What’s new

This launch adds a ConsumptionMode parameter to the Kafka event source mappings in Lambda. It accepts two values: Stream (the default, matching today’s behavior) and Queue, which uses Kafka Share Groups for parallel consumption. The core primitive in both modes is the event poller, a compute resource that fetches records from Kafka and invokes your Lambda function. Queue mode changes the protocol an event poller uses to obtain those records. Because pollers are no longer bound to individual partitions, queue mode supports higher concurrency. A single poller reaches up to 10 concurrent invocations compared to 5 in stream mode, and queue mode scales independently of partition count. We cover the scaling model in detail later in this post.

Stream mode: One consumer per partition, ordered processing

ConsumptionMode defaults to Stream, so existing ESMs are unaffected by this launch. In Stream mode, event pollers join a Kafka consumer group, and the broker assigns each partition exclusively to one consumer. This guarantees ordered processing within each partition.

Queue mode: Multiple consumers per partition, unordered parallel processing

Setting ConsumptionMode to Queue directs Lambda to use the Kafka Share Consumer. Event pollers join a share group, where partitions can be assigned to multiple event pollers for parallel processing without guarantees about order. The broker manages a record lifecycle of Available, Acquired, Acknowledged, and Archived. Fetched records are marked Acquired under a visibility timeout called the record lock duration. A successful invocation acknowledges them. A failed invocation releases them back to Available for any poller to acquire. While an invocation is still running, the poller renews the lock without incrementing the delivery attempt count.

Choosing between the modes

Use Stream mode when per-partition ordering matters: change data capture, event sourcing, or per-entity state machines. Use Queue mode when records are independent, and you want parallelism that is not bounded by partition count. You can run a Queue mode ESM and a Stream mode ESM against the same topic. Each operates independently through its own protocol.

Minimum requirements

Before you configure an ESM with ConsumptionMode: Queue, confirm that your Kafka cluster and Lambda function meet the following requirements.

Cluster requirements

  • Apache Kafka 4.2 or later, with share groups enabled.

Four broker settings interact with your ESM configuration:

  • group.share.partition.max.record.locks – The maximum in-flight records per partition. In Queue mode, multiple pollers might acquire records from the same partition concurrently, so the total in-flight count can exceed a single poller’s batch size. Set this value high enough to accommodate your expected concurrency. When the limit is reached, pollers can’t acquire new records from that partition until existing records are acknowledged, or their locks expire.
  • group.share.record.lock.duration.ms – The visibility timeout for acquired records. In most cases, the default of 30 seconds is sufficient. The poller renews the lock during processing. A long-running function does not typically require a duration longer than 30 seconds.
  • group.share.delivery.count.limit – The maximum number of times the broker attempts to deliver a record before archiving it. This works alongside MaximumRetryAttempts to govern retry behavior.
  • group.share.max.size – The maximum consumers allowed in the share group. When provisioned mode is active, keep MinimumPollers ≤ MaximumPollers ≤ group.share.max.size so that Lambda scaling isn’t capped by the broker. In on-demand mode, Lambda internally manages poller counts within broker-safe defaults.

Getting started

In the Lambda console, choose your function, choose Add trigger, and select Self-managed Apache Kafka. Enter your bootstrap servers and topic name, set Consumption mode to Queue, and configure your virtual private cloud (VPC) subnets and security groups. Optionally set Minimum event pollers and Maximum event pollers to use provisioned mode. For on-demand scaling leave those empty.

The following AWS CLI command creates the equivalent Queue mode ESM in on-demand mode:

aws lambda create-event-source-mapping
--function-name my-function
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["broker1.example.com:9092","broker2.example.com:9092"]}}'
--topics my-queue-topic
--batch-size 100
--self-managed-kafka-event-source-config '{"ConsumptionMode": "Queue"}'

ConsumptionMode is the only parameter required to enable Queue mode. BatchSize sets the maximum records per batch sent to your function, accepts values from 1–10,000, and defaults to 100.

With AWS CloudFormation, the equivalent resource looks as follows:

MyKafkaQueueESM:
  Type: AWS::Lambda::EventSourceMapping
  Properties:
    FunctionName: !Ref MyFunction
    SelfManagedEventSource:
      Endpoints:
        KafkaBootstrapServers:
          - broker1.example.com:9092
          - broker2.example.com:9092
    Topics:
      - my-queue-topic
    BatchSize: 100
    SelfManagedKafkaEventSourceConfig:
      ConsumptionMode: Queue

Queue mode is also configurable through the AWS SDKs, AWS Serverless Application Model (AWS SAM), and AWS Cloud Development Kit (AWS CDK). For the complete setup walkthrough, see the AWS Lambda Developer Guide.

Scaling with on-demand mode

Queue mode ESMs use on-demand mode for scaling by default. Lambda evaluates share group consumer lag at one-minute intervals and adds or removes event pollers as needed, completing scaling actions within three minutes. On-demand mode scales to five event pollers per ESM, each supporting up to 1 MB/s. It reaches its ceiling at either 5 MB/s aggregate throughput or 50 concurrent invocations, whichever comes first. This suits lower-concurrency workloads and development environments.

Scaling with provisioned mode

For workloads with strict latency requirements or spiky traffic, provisioned mode for scaling gives you direct control over the event pollers dedicated to your ESM. Set MinimumPollers from 1 –200 and MaximumPollers from 1 to 2,000. However, the broker’s group.share.max.size setting caps how many members can join a share group, and Kafka 4.2 limits this value to 1,000. Set MaximumPollers to 1,000 or below unless your broker supports a higher limit. Each provisioned event poller supports up to 5 MB/s.

aws lambda create-event-source-mapping
--function-name my-function
--self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["broker1.example.com:9092","broker2.example.com:9092"]}}'
--topics my-queue-topic
--batch-size 100
--self-managed-kafka-event-source-config '{"ConsumptionMode": "Queue"}'
--provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
--source-access-configurations '[{"Type":"VPC_SUBNET","URI":"subnet-0123456789abcdef0"},{"Type":"VPC_SUBNET","URI":"subnet-0123456789abcdef1"},{"Type":"VPC_SECURITY_GROUP","URI":"sg-0123456789abcdef0"}]'

To size MinimumPollers, divide your baseline ingestion rate by 5 MB/s. If your workload is concurrency-bound, divide your target concurrent invocations by 10 instead. A workload needing 300 concurrent invocations requires at least 30 pollers. Setting MinimumPollers equal to MaximumPollers pins capacity and disables autoscaling. For detailed sizing guidance, see Introducing provisioned mode for Kafka event source mappings with AWS Lambda on the AWS Compute Blog.

Low-latency processing, schema registry filtering for Avro and Protobuf, and ESM grouping are available only in provisioned mode. Provisioned mode also removes the requirement to configure AWS PrivateLink VPC endpoints, so you are not charged for those endpoints. To switch an ESM to on-demand scaling, pass an empty configuration:

aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{}'

Cost optimization with provisioned mode

In provisioned mode, ESMs in the same VPC can share Event Poller Unit (EPU) capacity through a common PollerGroupName, letting low-throughput ESMs pack onto shared EPUs instead of each holding dedicated capacity. For details, see Cost optimization for provisioned mode. A poller group supports up to 100 ESMs and 2,000 aggregate maximum pollers.

Queue mode ESMs share EPUs only with other Queue mode ESMs. The two modes autoscale on different signals, and isolation keeps a new Queue mode ESM from destabilizing existing ordered consumers. Use a unique PollerGroupName for your Queue mode ESMs. If you reuse a PollerGroupName across modes, CreateEventSourceMapping returns a validation error.

Handling failures

MaximumRetryAttempts accepts values from 0 to 10,000 and defaults to -1, which retries indefinitely. BisectBatchOnFunctionError splits a batch in half when the function returns an error, isolating a poison-pill record from an otherwise healthy batch. To capture records that exhaust their retries, configure an on-failure destination: a Kafka topic, Amazon Simple Queue Service (Amazon SQS), or Amazon Simple Notification Service (Amazon SNS). ESM logging to Amazon CloudWatch Logs is available for diagnostics.

Key considerations for Queue mode

Keep the following in mind when configuring your event source mapping for Queue mode.

  • Make your function idempoten – Lambda event source mappings process each record at least once, and duplicate processing can occur. See How do I make my Lambda function idempotent in the AWS Knowledge Center.
  • No ordering guarantees – Records can arrive out of order, including records from the same partition.
  • Batching window is not supported – MaximumBatchingWindowInSeconds returns a validation error. The Kafka Share Consumer requires every record in a batch to be acknowledged before fetching new records, which is incompatible with a time-based window.
  • Starting position is not supported – StartingPosition and StartingPositionTimestamp can’t be used. Queue mode reads from the share group’s committed position. To control where a new share group begins reading, configure share.auto.offset.reset on the broker.
  • Event filtering supports up to five filter patterns per event source mapping.

Pricing and availability

Queue consumption mode is available in all AWS Regions where Lambda event source mappings for self-managed Apache Kafka is supported. On-demand mode carries no charge beyond standard Lambda invocation charges. Provisioned mode is billed on EPU usage. For details, see AWS Lambda pricing.

Conclusion

Queue consumption mode brings queue-style processing to Apache Kafka topics without additional infrastructure and without changes to your producers, topic configuration, or function code. By replacing exclusive partition assignment with share groups, it removes the partition count as a ceiling on parallelism and eliminates head-of-line blocking for workloads built on independent records.

To get started, create an event source mapping with ConsumptionMode set to Queue on a self-managed Apache Kafka 4.2 or later cluster. For configuration details, see Polling Kafka queue topics in the AWS Lambda Developer Guide.

For more serverless learning resources, visit Serverless Land.

 


About the authors

Vaibhav Jain

Vaibhav Jain

Vaibhav is a Senior Delivery Consultant at Amazon Web Services, where he leads technical delivery for complex data platform and application modernization engagements. He has over 20 years of experience in application development, including 15 years building large-scale distributed systems before joining AWS.

Hardith Murari

Hardith Murari

Hardith is a Delivery Consultant at Amazon Web Services, focused on application development, modernization, and event-driven architectures. He is driven by a deep interest in cloud infrastructure, distributed systems, and developer tooling, always seeking to improve reliability, scalability, and the overall developer experience on AWS.

Nihar Sheth

Nihar Sheth

Nihar is a Principal Product Manager for AWS Lambda at Amazon Web Services, where he leads product strategy for serverless compute and event-driven integrations. He is passionate about building capabilities that make it easier to create event-driven, highly scalable applications with a focus on developer experience, performance, and operational simplicity.

Beyond DKIM key rotation: understanding email replay attacks

Post Syndicated from Michael Araba original https://aws.amazon.com/blogs/security/beyond-dkim-key-rotation-understanding-email-replay-attacks/

As the email administrator for your organization’s domain, you receive a Domain-based Message Authentication, Reporting, and Conformance (DMARC) aggregate report showing email passing DomainKeys Identified Mail (DKIM) verification as though it came from your domain, sent from IP addresses you don’t recognize to recipients you didn’t contact. To clear the issue, you rotate your DKIM key, confirm the new selector is live, and verify that your DMARC policy is already set to p=reject. Days later, you see that the same unfamiliar traffic is still authenticating as you.

In this post, you learn why rotation alone can’t stop a DKIM replay attack, how to confirm that you’re looking at a replay rather than a legitimate relay or ordinary spoofing, and the DNS cleanup step that most rotation guidance leaves out. You also learn how you can use Amazon Simple Email Service (Amazon SES) to detect and respond to this activity faster.

How DKIM replay works

DKIM verifies one thing: that specific parts of a message didn’t change between the signer and the receiver. The signer signs the message with a private key, and receivers fetch the matching public key from your domain’s DNS to check the signature. A valid signature continues to validate wherever the message travels afterward. Mailing lists, .forward rules, and third-party relays all preserve it, which is the protocol working as designed.

A replay attack takes advantage of that durability. The attack works as follows:

  1. Your ecommerce platform sends a customer a legitimate response email, signed with your DKIM key.
  2. An attacker obtains one copy of that message. They might subscribe to your mailing list, compromise a mailbox, retrieve it from a list archive, or capture it through a forwarding rule.
  3. The attacker resends that message, unchanged, from their own servers to thousands of new recipients.
  4. Each receiving server fetches your public key from DNS and checks the signature. The signature passes, because the body wasn’t modified. Sender Policy Framework (SPF) fails, because the sending IP isn’t yours, but DMARC requires only one of SPF or DKIM to pass with alignment. Because DKIM passes, DMARC passes, and the message is delivered as authenticated email from your domain.

Understanding what an attacker can and can’t do matters, because the limits define the problem. An attacker can’t modify your message, add new content, or read your email. The signature is only valid while the message remains byte-for-byte identical.

What an attacker gains is your domain’s reputation, which they use to deliver your genuine message to an audience you didn’t intend. A receipt or invoice becomes a lure, and email that would normally be filtered is delivered because receivers trust your domain. This is abuse of reputation and reach, not content forgery, and the distinction matters when you explain the incident to your security team.

This also explains why an enforcing DMARC policy doesn’t stop an attack. DMARC passes when SPF or DKIM passes with alignment. During a replay, DKIM passes, so DMARC passes, and p=reject does not apply. A p=reject policy is designed to stop spoofing, where a forger has no valid signature and DKIM fails. It does nothing against a message that you signed. Determining which of the two was used is what tells you how to respond.

Is it replay, spoofing, or a legitimate relay?

Email from an unfamiliar IP address that passes DKIM has three common explanations, and each requires a different response. Confirm which you’re dealing with before you make any changes.

DMARC aggregate (rua) reports provide the source IP address, message volume, and SPF and DKIM results. This is enough to identify an anomaly, but not to prove a replay. A report row might read as follows:

source IP: 203.0.113.45 | count: 4,200 | SPF: fail | DKIM: pass (d=yourdomain.com)

You need to evaluate that row against the three possibilities:

  • The first possibility is a legitimate relay that you haven’t inventoried, such as a mailing list, a forwarder, or an email security gateway such as an inline cloud access security broker (CASB) that you route through. The signature validly survives the relay, and this is normal email flow. In the report, the source IP address usually resolves to a known provider, and the volume tracks your actual sending.
  • The second possibility is replay abuse, in which an attacker redistributes a message that you legitimately signed. In this case, the DKIM-passing volume comes from an IP address that has no business relationship with you, often well above the usual number of recipients that you send to, and frequently to recipient domains that you haven’t worked with.
  • The third possibility is ordinary spoofing, which is a forgery with no valid signature. That row shows DKIM: fail. DKIM that passes from an unknown IP address is therefore usually not ordinary spoofing.

Aggregate counts can’t prove a replay on their own. To confirm a replay, you need message-level evidence: a specific message that you sent matched to one that reached recipients you didn’t address. If you can’t make that match, treat the activity as an unconfirmed anomaly, and begin with the enforcement and monitoring steps that follow rather than removing keys.

Set up an enforcing DMARC policy first

Before you take any other action, confirm that you’re enforcing DMARC. Many domains that encounter this problem are still at p=none, which is monitoring only. This situation is common. Every DMARC deployment begins at p=none, and many organizations do not advance beyond it because nothing appears to be broken. At p=none, receivers take no action on failures, so no change you make affects delivery, and you can’t determine what enforcement would have caught.

The first step is therefore not key removal; it’s completing your sender inventory and reaching enforcement:

  1. Inventory every legitimate sender and relay for your domain, including your email service providers, mailing lists, and any security gateways that send on your behalf.
  2. Bring each sender into SPF and DKIM alignment so that legitimate email authenticates.
  3. Advance the policy one stage at a time, from p=none to p=quarantine to p=reject. Review your rua reports at each stage before you advance, typically for a week or two per stage, and longer if you have many senders to work through. The pct tag lets you ramp up gradually, for example by quarantining 25% of failing email before you increase the percentage.

After you’re enforcing DMARC, receivers that honor DMARC drop unauthenticated spoofing on your behalf. Only after this baseline is in place, and only after you have confirmed a replay of genuinely signed email, does the next step apply.

Remove the old key from DNS: routine hygiene after rotation

Most rotation guidance omits this step. Rotating a key and removing the old key are two separate actions.

Rotation means that your provider begins signing new email with a new key and selector. Removal means deleting the old public key from DNS, so that previously signed messages, including the copies that an attacker captured, can no longer be verified. If you rotate but leave the old public key published, every message ever signed with that key remains replayable for as long as the record exists. Removing the old key is what closes that window and is the step that’s commonly overlooked.

Removal affects only messages that are still in transit and were signed with the old key. After email is delivered, the receiver no longer needs your key, so we recommend that you leave the old key published long enough for in-flight email to arrive and then remove it. How much of this process you manage yourself depends on your DKIM method, which the following section describes. During a confirmed active replay, closing this window is essential.

How you manage keys depends on the DKIM method that you use with Amazon SES. With Bring Your Own DKIM (BYODKIM), you generate the key pair and publish the public key as a TXT record that you control. You can rotate and remove keys whenever you want, including removing an old key on demand during an incident. As the BYODKIM documentation states, “you can rotate the DKIM keys for your domains as often as you want.”

With Easy DKIM, a feature where Amazon SES generates and manages the keys for you, you publish CNAME records that point to AWS-hosted keys. Because your DNS points to AWS-hosted keys through those CNAME records, Amazon SES manages the underlying key material for you, so you don’t publish or remove individual keys yourself. Unlike BYODKIM, Easy DKIM doesn’t provide an on-demand option to delete a specific key immediately.

If you’re an Easy DKIM sender during a confirmed replay, your defenses are early detection (described in the following section), the duplicate-message throttling that receivers already apply, and, over the longer term, the emerging DKIM2 effort, an IETF initiative to update the DKIM specification with built-in replay resistance, which is being designed to give receivers better signals to identify and act on replayed messages at the protocol level.

How Amazon SES helps you detect and respond

Your first response is detection, not DNS changes. The goal is to identify anomalous DKIM-passing volume early, while you build the message-level evidence that distinguishes a replay from a legitimate relay.

Begin by enabling logging. Create an Amazon SES configuration set with an event destination (see Monitor email sending using Amazon SES event publishing) that streams per-message events (Send, Delivery, Bounce, and Complaint) to Amazon Data Firehose or Amazon EventBridge (see Add an event destination), tagged with the From domain.

Separately, confirm that you’re receiving rua reports for your domain. You enable these reports by adding a rua= address to your domain’s DMARC TXT record, for example rua=mailto:[email protected]. For the record syntax and a phased p=none to p=quarantine to p=reject rollout, see Complying with DMARC authentication protocol in Amazon SES. Reports arrive as daily XML digests, and most teams process them with a DMARC analyzer rather than reading the raw XML.

With both sources in place, you can correlate them. Compare the email that your account emitted—based on your Amazon SES delivery events—against what DMARC reports show that receivers accepted as your domain. When DMARC shows DKIM-passing volume from IP addresses outside your SPF record that exceeds the delivery events that Amazon SES recorded for that From domain in the same window, that gap is your signal. It’s also how you build the message-level case that distinguishes a replay from a legitimate relay.

We recommend three additional controls. Amazon SES sending authorization restricts which AWS principals can send using your verified identity. It doesn’t stop an external replay, but it addresses the insider and third-party vector that SPF, DKIM, and DMARC don’t cover on their own, so use identity-level policies to limit sending to specific AWS Identity and Access Management (IAM) principals.

Use Amazon Route 53 to set short DNS time-to-live values (TTLs) (for example, 300 seconds) on your DKIM records so that changes propagate quickly; and enable DNS query logging with an Amazon CloudWatch Logs metric filter that watches for queries to a selector that you’ve rotated away from.

A spike in lookups for an old selector is a useful early indicator of a replay attempt using a retired selector. For a BYODKIM domain during a confirmed replay, Route 53 is also where you remove the old selector’s TXT record. You can automate that removal by using an Amazon CloudWatch alarm that starts an AWS Lambda function to call the Route 53 API and retire an old selector’s record.

Scope the function’s IAM role to only the specific Route 53 hosted zone and record that it needs to change, so that it follows least privilege. Because an incorrect DNS change can have a wide effect, gate any automation behind confirmed-replay criteria and test it against a non-production domain first. For most teams, alarm-to-human is safer than alarm-to-automatic-removal.

When your domain is the one being abused

Most guidance assumes that you’re either the provider preventing abuse or the receiver detecting it. In a replay, your domain is the one whose reputation is being consumed, and you aren’t on the recipient list. As a result, you don’t have the message that everyone asks for when you report the issue.

When you file an abuse report with the provider that hosts the source IP address, they ask for full message headers. The email went to people you didn’t contact, so you don’t have the message headers. You then provide DMARC aggregate reports that show the source IP address and volume, and the provider asks for headers again. At this point, you’re unable to proceed.

To break this cycle, go to the recipients. Review your rua reports for the top recipient domains—which are often .gov and .edu domains—contact those recipients directly and request a sample message with full headers. In addition to providing the headers, that sample lets you confirm a replay rather than a legitimate relay. Build your abuse report around the IP address and the DMARC evidence rather than the message content. If the source IP address belongs to Amazon Web Services (AWS), report it through the AWS abuse process and include your DMARC reports and SPF record as evidence.

Incident response: ordered actions

If your reports show suspicious DKIM-passing email from unfamiliar IP addresses, complete the following procedure.

To respond to a suspected DKIM replay

  1. Confirm that it’s a replay. Match a message that you sent to one that reached recipients you didn’t address and rule out legitimate relays and gateways. Aggregate data alone isn’t proof.
  2. Reach an enforcing DMARC policy. Inventory your legitimate senders, align them, and advance from p=none to p=quarantine to p=reject. This stops spoofing.
  3. Harden SPF to -all rather than ~all, but only after your sender inventory is complete, since -all hard-fails any legitimate source you haven’t listed.
  4. Check the DKIM-Signature header of a fresh message to confirm that your provider signs only with the current selector.
  5. Report the source IP address to the hosting provider and include your DMARC evidence.
  6. Investigate the capture point, such as a compromised mailbox, a mailing list, a forwarding rule, or a newsletter subscription.
  7. Remove the old DKIM public key after in-flight email has cleared. For BYODKIM, delete the old selector’s TXT record. For Easy DKIM, rely on the managed Amazon SES rotation together with the monitoring and receiver-side defenses described earlier.

The following table summarizes what each action does and doesn’t do.

Action What it does What it doesn’t do
Confirm replay (message-level) Separates a replay from a legitimate relay or spoofing Can’t be done from aggregate DMARC data alone
DMARC enforcement (p=none to p=reject) Drops unauthenticated spoofing Does nothing against a replay because DKIM still passes
Key rotation Signs new email with a new key Doesn’t invalidate already signed messages
Remove old key (routine, post-rotation) Invalidates old-key signatures, including captured ones Doesn’t protect in-flight old-key email; on-demand removal available only with BYODKIM
Amazon SES sending authorization Restricts which principals send as your identity Doesn’t stop external replay of captured messages

Conclusion

DKIM replay succeeds because a valid signature keeps validating, and an enforcing DMARC policy doesn’t change that. To respond effectively, confirm that the activity is a replay with message-level evidence, reach an enforcing DMARC policy, and then remove the old key from DNS as routine post-rotation hygiene. Keep your primary defense on monitoring and DMARC enforcement rather than on emergency DNS changes. The durable fix for replay is receiver-side: duplicate-message counting today, and stronger protocol-level signals through DKIM2 in the future.

To get started, review your current DMARC policy and confirm that you’re receiving rua reports, enable Amazon SES event publishing, and document how you rotate and remove DKIM keys for each of your domains.

Learn more

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.


Michael Araba

Michael Araba

Michael is a Technical Account Manager at AWS Enterprise Support, where he works with customers on email security, DNS architecture, and incident response.

[$] The second part of the 7.4 merge window

Post Syndicated from daroc original https://lwn.net/Articles/1102739/

The 7.4 merge window, which
closed on November 1,
included a record-breaking 18,591 non-merge changesets.
That is almost as many as the entire 7.3 development cycle, which had 18,765, itself a record breaker. Of
those, 11,838 landed after the article covering the
first part of the merge window
. Most of those were bug fixes of
various forms; it seems as though bug fixes may be crowding out feature
additions across the open-source ecosystem to
some extent. Still, a good number of new features were included, and a handful
removed, in the tail end of the merge window.

The collective thoughts of the interwebz