About KeePassXC’s code quality control (KeePassXC blog)

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

The KeePassXC project has recently updated its contribution
policy
and README
to note its policy around contributions created with generative AI
tools. The project’s use of those tools, such as GitHub Copilot, have
raised a number of questions and concerns, which the project has
responded
to
:

There are no AI features inside KeePassXC and there never
will be!

The use of Copilot for drafting pull requests is reserved for very
simple and focused tasks with a small handful of changes, such as
simple bugfixes or UI changes. We use it sparingly (mostly because
it’s not very good at complex tasks) and only where we think it offers
a benefit. Copilot is good at helping developers plan complex changes
by reviewing the code base and writing suggestions in markdown, as
well as boilerplate tasks such as test development. Copilot can mess
up, and we catch that in our standard review process (e.g., by
committing a full directory of rubbish, which we identified and
fixed). You can review our copilot instructions. Would we ever let AI
rewrite our crypto stack? No. Would we let it refactor and rewrite
large parts of the application? No. Would we ask it to fix a
regression or add more test cases? Yes, sometimes.

Emphasis in the original. See the full post to learn more about the
project’s processes and pull requests that have been created with AI
assistance.

A proposed kernel policy for LLM-generated contributions

Post Syndicated from corbet original https://lwn.net/Articles/1045806/

The kernel community is currently reviewing a
proposed policy
for contributors who are using large language models to
assist in the creation of their patches; the primary focus is on disclosure
of the use of those tools. “The goal here is to clarify community
expectations around tools. This lets everyone become more productive while
also maintaining high degrees of trust between submitters and
reviewers.

Опитите за отслабване на криптирането водят в стена

Post Syndicated from Bozho original https://blog.bozho.net/blog/4544

Четох съобщението на Европейската комисия за стратегията за сигурност ProtectEU (пак започвам скучно). И вътре освен логичните и очаквани неща, видях един голям проблем:

„Ще представи през 2026 г. технологична пътна карта относно криптирането с цел идентифициране и оценка на технологични решения, които да предоставят законен достъп до данни на правоприлагащите органи;“ като препраща към документ, който казва, че „Групата на високо равнище препоръча редица мерки, за да се гарантира, че широк кръг от доставчици, включително доставчици на OTT услуги (чат приложения), отговарят на искания за законно прихващане“ и съответно, че Комисията ще „проучи мерки за създаване на равнопоставени условия за всички видове доставчици на съобщителни услуги, що се отнася до изпълнението на задължения за законно прихващане;“.

Под бюрократичните евфемизми се крие следното: в целия свят, от 30 години, все някой се опитват да отслаби криптирането, за да може държавата да „слуша“. Спрете се. Това не може да стане. Ще ги хващате по други начини. Ще ползвате метаданни, агенти под прикритие и др.. С криптирането ще си загубите времето, а и политическата подкрепа. Ще стане като с „chat control“ – няма технологично решение, което да не нарушава основни конституционни права.

Може би ако изхождаш от съдебните системи на Германия, Франция, Белгия, изглежда разумно да имаш „законно прихващане“. Тук винаги припомням подслушването на десетки протестиращи през 2020 г. по разследване за държавен преврат на прокуратурата. При нашата прокуратура и при нашите служби (все по-овладяни), няма „законно прихващане“. Понякога ще е законно, понякога ще е полу-законно – ще се прихващат политици, опозиция, бизнеси, посолства – каквото ѝ хрумне на държавата с главно Д.

Технологично това е нонсенс – ако отслабиш криптирането за правоохранителните органи, отслабваш го за всички; ако сложиш тайна „задна вратичка“ в алгоритъма, тя ще спре да бъде тайна на втория месец; ако ползваш т.нар.“призрачен потребител“, както предложиха британските служби преди години, чупиш гаранциите за идентификация на потребителите (и някой друг също ще намери как да добави призрачен потребител в разговора); разделянето на криптографски ключове е несъвместимо с гаранциите за т.нар. forward secrecy и създава много други проблеми.

И най-лошото е, че дори да се приеме някаква законодателна глупост, която да отлсаби криптирането „от край до край“, тя ще бъде заобиколена точно от организираните престъпни групи, които цели да засегне. Ако накарате Signal, Threema, Wire или някое друго приложение с криптиране „от край до край“ да сложи вратичка, през която да се подслушва, те или ще излязат от европейския пазар, или дори да се съобразят, ще продължат да бъдат с отворен код, и криминалните групи ще могат да си направят своя версия, без възможността за прихващане. И ще си ползват нея, докато за нормалните хора ще отпаднат гаранциите и някой следващ Гешев ще може да ги слуша за държавен преврат, докато всъщност се опитва да превземе бизнес или да събира компромати.

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

Материалът Опитите за отслабване на криптирането водят в стена е публикуван за пръв път на БЛОГодаря.

Малко статистика за съдебните дела в България

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2025/ecases-stats/

Като се сдобия с някакви данни, често отнема доста време докато разбера какво гледам и подредя. Обикновено започвам със статистика и извадки за първите неща, които ми правя впечатление.

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

В порталът има данни за 4.5 млн. дела. Най-ранните от тях са заведени пред 1970-та г. Ето малко статистика за тях:

На първата снимка виждате делата по месеци от последните 15 години. Вижда се рязко увеличение между 2016-та до 2021-ва, което може да се обясни по-скоро с качването на данни в системата и липсата на повечето дела преди 2016-та, отколкото друго.

Втората графика показва часът, в който са заведени делата в последните пет години, когато този час е упоменат. Известен е часът за 58% от делата. Вероятно конкретни съдилища не публикуват тази информация, а само дата. Сред останалите се забелязва обедната почивка и края на работния ден. Вижда се обаче интересен феномен за завеждане да 1% от делата с известен част между 1 и 4 часа след полунощ.

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

Прокуратурите на България са завели 432 хиляди дела сред публичните такива. Четвъртата графика ги показва. 12% от всички дела на прокурори в последните 5 години са заведени от Районна прокуратура – София.

Липсата на дела от СРП и редица други институции преди 2021-ва сочи към това, че липсват все още много дела в системата. Не е ясно дали просто не ги дават или са в процес на качване. Така обаче трудно може да преценим дали има увеличение на делата от някоя прокуратура или от определена компания като Топлофикация София. Друг проблем е различното изписване на институциите. Докато фирмите се преименуват, а редовните преструктурирания на съдебната система и обвинението водят до объркване, дори изписването на една и съща прокуратура или компания в същата година се различават значително.

На горната графика съм представил статистика на наличните дела в портала по съдилища. Може би това ще ни даде представа кои не са въвели стара информация или е изгубена в предшестващите им структури Вижда се ясно, че Административен съд – София-град не е представил никакви дела преди 2019-та, а е основан 2007-ма. Висшия административен съд има дела едва след 2021-ва. Висшия касационен съд са публикували за по-дълъг период, но имат дупка между 2017 и 2019-та, както и доста данни преди 2008-ма. Софийски районен съд и СГС не са публикували дела преди 2017-та, както и голяма част от данните на районни, окръжни и административни съдилища извън София. Последните обаче се вижда, че не са публикували и доста дела преди 2021-ва.

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

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

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

The post Малко статистика за съдебните дела в България first appeared on Блогът на Юруков.

Седмицата (3–8 ноември)

Post Syndicated from Надежда Радулова original https://www.toest.bg/sedmitsata-3-8-noemvri/

Седмицата (3–8 ноември)

През последните дни по екрана на компютъра ми нефелно примигват разни невнятни новини, на които не можеш да им хванеш ни главата, ни опашката. Камо ли да ги опитомиш в някакъв строен и разумен наратив. И все тая дали ще е кометата 3I/ATLAS, която в конспираторските групи привиждат като поела на мисия да ни „занулява“, или пък 84-метровият кораб фантом край нос Емине само с двама души екипаж, или пък новината за откриване на суперважна всекидневна въздушна линия до Пакистан (а защо не и до Азкабан, питам се)… Все тая, при положение че у нас всичко, което хвърчи, се яде и тези полуприказни сюжети се оказват идеални за предъвкване в социалните мрежи, а и за разтуха от истински преседливите теми, като например публикувания от Министерството на финансите проектобюджет за 2026 г.

Та за троловете и за обикновените любители на медийната и социалномрежовата разтуха – благи вести от парламента! Задават се чували с пуканки, осигурени с любезната подкрепа на ДПС – Ново начало, „Възраждане“, „Величие“, БСП, ИТН, МЕЧ и независими депутати, които – след множество неуспешни напъни – издебнаха деня с най-много отсъстващи от ПП–ДБ и гласуваха създаването на временна комисия за разследване дейността на Джордж Сорос, Александър Сорос и техните фондации на територията на България. Браво, félicitations, Волдемор падна в капана! Въпросът е какво следва оттук нататък, освен, разбира се, доволните дози прах в очите на всички ни.

Първо, нека тръгнем от факта, че

от много години никой от фамилията Сорос няма фондации, нито пък упражнява дейност на територията на България.

Любимата и на „копейките“, и на „хилядниците“ неправителствена организация Институт „Отворено общество“ отдавна не получава никакво финансиране от Сорос и това е лесно проверимо. Така че ако целта на новогласуваната комисия е да разследва дейността на Соросовите фондации в момента, със същия успех може да започне проверки на провеждащия се – примерно в Негован – събор на марсианците.

Второ, ако неуважаемите разследващи все пак се съсредоточат върху отминали периоди, т.е. преди Джордж Сорос да оттегли дейността си от България, осветляването на „мрежата от влияния“ (по думите на Йордан Цонев) със сигурност ще извади наяве немалко членове и сподвижници на партиите, гласували „за“, които са били подкрепяни през годините от някогашната фондация „Отворено общество“, Център за изкуства „Сорос“ и пр. (включително и като питомци на училищата за политика от началото на новото хилядолетие, където младите и обещаващи кадри от БСП и ДПС бяха особено активни).

И тази свързаност не би била учудваща предвид факта, че в мътилката на 90-те, когато държавата беше абдикирала от ключови сфери, като образование, наука, култура и здравеопазване, именно програмите на така мразения днес у нас американски филантроп осигуриха хиляди ученически, студентски и научни стипендии; стартираха фундаментални за развитието на гражданския сектор проекти; позволиха на студенти, учени, писатели, артисти да пътуват, да се обучават, да повишават квалификацията си, да участват в международни форуми; подкрепиха свободните медии, провеждането на хиляди културни събития, издаването на безброй книги…

На фона на всичко това Йордан Цонев има наглостта да заяви от парламентарната трибуна: „Най-голямата вреда обаче беше не толкова в политиката, колкото в обществения и културния живот, в академичните среди. (…) Да не говорим и за културата, където примерите са даже и от миналата седмица, където започва линч срещу един писател, а друг един го затрупват с награди…“ Очевидно моралният компас на г-н Цонев определя като напълно приемливо един писател да размята картечница из социалните мрежи и като точно толкова осъдително и неприемливо друг писател да получава български и международни награди за добре свършена работа. Интересна логика. И етика. И естетика.

Но нека оставим на мира писателите, към които отпраща в речта си Цонев, и се върнем към по-общия въпрос за нанесената от Сорос вреда в културния и обществения живот. Да си припомним някои от публичните фигури, които попадат в групата на свързаните с дейността на Сорос в България. Част от тези хора вече не са сред живите, но това никога не е пречило на троленето и тричането, особено в полуанонимния комфорт на социалните мрежи. Блага Димитрова, Йордан Радичков, поета Борис Христов, Богдан Богданов, Димитър Аврамов, Райна Кабаиванска ли ще „изчистваме“?! Или стотици преподаватели в български университети?! Или може би целия Нов български университет от вратата до комина?! Хайде, стига глупости!

Трето. И този път съвсем сериозно. Ясно е, че комисията няма да предприеме нищо от това, което на думи възнамерява, не само защото не разполага с необходимите правни основания и реален обект на разследването, но и защото действителната ѝ цел е съвсем друга. А именно – да създава стигми и да нанася имиджови удари върху важни за развитието на културата и на цялото ни общество личности и процеси. Да отравя обществените нагласи. Да изкривява и разгражда едни от малкото смислени разкази за най-близкото ни минало. И да постига това с помощта на армии от тролове, спекулации, корупция, фалшиви новини и евтина пропаганда.

(Не мога да повярвам, че нито веднъж дотук в този текст не споменах името Делян Пеевски. Ето, споменавам го.)

А ако искате да научите още за новосъздадената парламентарна комисия, както и за едно много интересно ново проучване на Институт „Отворено общество“, прочетете седмичния анализ на Емилия Милчева „А ти готов ли си да се биеш за демокрацията?“.

След това дълго и мрачно интро, сигурно и на вас (както и на мен) ви иде да затворите бюлетина и да пуснете кепенците. Но точно в такива моменти на ноемврийска резигнация на прозореца каца Е.Т. , за да упражни влияние и да сложи черешката (пардон, коронката) на седмицата.

Освен всичко казано от Е.Т., в броя може да прочетете още за:

За финал – ако и вие изтрещявате като мен, ето едно парче, на което да си трещим заедно в компанията на Иги Поп. И запомнете – няма вече 5 за 4, няма 6–5, всичко е 6–7!

А докато си подскачате със или без микрофон, ударете един подкрепящ бутон, че ония момци с метлите от парламента идат – и за нас, и за вас.

AWS Lambda networking over IPv6

Post Syndicated from John Lee original https://aws.amazon.com/blogs/compute/aws-lambda-networking-over-ipv6/

IPv4 address exhaustion is a challenge in modern networking, as most IPv4 addresses have been depleted with the growth of the internet. Previously, AWS Lambda only supported inbound and outbound connectivity over IPv4, but it has since introduced support for dual-stack endpoints, so that you can transition from IPv4 to IPv6. AWS continues to add support for IPv6, recently announcing support for inbound IPv6 connectivity over AWS PrivateLink, and dual-stack endpoint support for Amazon API Gateway.

With these IPv6 capabilities now available in Lambda, you should understand how to use them effectively. This post examines the benefits of transitioning Lambda functions to IPv6, provides practical guidance for implementing dual-stack support in your Lambda environment, and considerations for maintaining compatibility with existing systems during migration.

Benefits of transitioning

You can transition to IPv6 to future-proof your overall architecture by preparing ahead of the broader transition to IPv6, and establish compatibility with IPv6 clients or services. IPv6 also eliminates the need for a NAT gateway when the Lambda functions need internet connectivity from a private subnet in your Amazon Virtual Private Cloud (Amazon VPC). Lambda functions can direct traffic to the egress-only internet gateway, potentially eliminating the NAT gateway and its associated charges and streamlining network design. This transition provides cost savings, as egress-only internet gateways are free to use, as opposed to NAT gateways that incurs an hourly charge. Furthermore, IPv6 offers improved network efficiency by eliminating NAT translation overhead, so that Lambda functions can establish direct connections with clients. IPv6 also has more advantages such as native Quality of Service (QoS), which streamlines header structure and reduces packet fragmentations.

Architectural implications

Lambda functions are often deployed inside of a VPC to access VPC resources. For VPC Lambda functions to access the internet, routing traffic through an NAT gateway is a common approach. For Lambda functions with IPv6 support, Lambda functions can now route traffic directly through the egress-only internet gateway, which eliminates the need for a NAT gateway and the extra hop, as shown in the following figures.

architecture diagram showing egress traffic in both ipv4 and ipv6 environments

Figure 1. Lambda internet connectivity through a NAT Gateway (IPv4) and Lambda internet connectivity through an egress-only internet gateway (IPv6).

Once the egress-only internet gateway is in place, you need to update the route table to reflect this. If you have used 0.0.0.0/0 as the default route for IPv4 traffic, you should add ::/0 as the default route for IPv6 traffic. The following image shows the updated route table.

ipv4 and ipv6 route tables

Figure 2. Lambda private subnet routing tables for an NAT Gateway (IPv4) as opposed to a dual-stack including an egress-only internet gateway (IPv6)

If you are using Lambda function URLs, no transition is needed. Lambda function URLs are inherently IPv6-capable and can be accessed by IPv6 clients without needing architectural changes or modifications. This IPv6 compatibility for function URLs operates independently of your Lambda function’s VPC configuration, and clients can reach your Lambda function URLs over IPv6 even when dual-stack is not enabled in your VPC.

For Lambda functions that interact exclusively with AWS services through internal traffic, IPv6 offers limited benefits. For example, in an architecture where a Lambda function processes requests from Amazon API Gateway and queries a database hosted on Amazon Relational Database Service (Amazon RDS), no architectural change is expected. Internal traffic routes using the RDS cluster endpoint and Lambda Amazon Resource Name (ARN), not IP addresses, as shown in the following figure.

architecture diagram showing traffic going through API GW, Lambda, and RDS

Figure 3. A common architecture pattern where Lambda processes events from API Gateway and reads/writes to Amazon RDS. You reference the Lambda function ARN and RDS cluster endpoint instead of IPv4/IPv6 addresses.

Transitioning from IPv4 to IPv6

By default, Lambda functions communicate over IPv4 to their destinations. For Lambda functions to communicate with IPv6 destinations, dual-stack VPC configuration is needed. This allows Lambda functions to communicate over both IPv4 and IPv6.

If your VPC does not have IPv6 support, then you need to first add IPv6 support for your VPC. You need to follow these steps to enable IPv6 traffic for a Lambda function:

  1. Assign IPv6 block to VPC: You need to edit the existing VPC CIDRs to add an IPv6 CIDR block. If you select the option of Amazon-provided IPv6 CIDR block, then you are assigned a /56 IPv6 CIDR block from the Amazon pool of IPv6 addresses. You also have the option to assign an Amazon VPC IP Address Manager allocated or your own IPv6 CIDR block.
  2. Assign IPv6 block to Subnets: After assigning an IPv6 CIDR block to the VPC, you must manually configure IPv6 CIDR blocks for each existing subnet, with each subnet receiving a portion of the VPC’s IPv6 address space.
  3. Update route tables: For your Lambda function’s IPv6 traffic to reach the internet, you need to add a route (::/0) to the egress-only internet gateway.
  4. Update security groups: By default, security groups allow all outbound traffic. To restrict outbound IPv6 traffic from your Lambda function, you must remove the default egress rule and add specific restrictive outbound rules. For inbound traffic, security group rules are needed when your Lambda function receives direct network connections, such as traffic through AWS PrivateLink connections.
  5. Enable IPv6 dual-stack on the Lambda function: When you assign IPv6 addresses for your Lambda function’s subnet, you can enable IPv6 dual-stack for the Lambda function. Then, Lambda creates new Elastic network interfaces (ENI) with IPv4 and IPv6 protocols with both IPv4 and IPv6 addresses. Although most updates to the Lambda function have zero downtime, enabling dual-stack may cause disruption in connectivity. To prevent downtime during the transition, we recommend using Lambda versions and aliases to implement a blue/green deployment strategy. You can publish your IPv6-enabled Lambda function as a new version while keeping the current version active and serve traffic through the alias. After testing the new IPv6 version, you can update the alias to switch the traffic. This approach provides a rollback capability, and you can revert the alias to point back to the previous version if needed.

When you have completed these steps, your Lambda function can support dual-stack networking and communicate over both IPv4 and IPv6.

Conclusion

In this post, we covered the benefits of transitioning your AWS Lambda functions from IPv4 to IPv6, the architectural implications, and steps for how you could make the transition.We recommend transitioning your Lambda functions to support both IPv4 and IPv6 traffic to gain its benefits. The Lambda IPv6 support helps address IPv4 exhaustion while providing cost savings and network clarification. Once organizations transition to supporting only IPv6 traffic, they can eliminate NAT gateways for Lambda functions needing internet access, thus reducing both costs and architectural complexity. As AWS expands IPv6 support across services, transitioning Lambda functions to dual-stack networking positions organizations for long-term compatibility while delivering immediate operational benefits.

For more information on how to enable IPv6 access for Lambda functions in dual-stack VPC, see the Lambda documentation. For more serverless learning resources, visit Serverless Land.

Friday Squid Blogging: Squid Game: The Challenge, Season Two

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/friday-squid-blogging-squid-game-the-challenge-season-two.html

The second season of the Netflix reality competition show Squid Game: The Challenge has dropped. (Too many links to pick a few—search for it.)

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Blog moderation policy.

Metasploit Wrap-Up 11/07/2025

Post Syndicated from Marcin Walas original https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-11-07-2025

New module content (3)

Centreon authenticated command injection leading to RCE via broker engine “reload” parameter

Author: h00die-gr3y [email protected]

Type: Exploit

Pull request: #20672 contributed by h00die-gr3y

Path: linux/http/centreon_auth_rce_cve_2025_5946

AttackerKB reference: CVE-2025-5946

Description: Adds an exploit module for Centreon. The vulnerability, an authenticated command injection, will lead to a remote code execution.

Rootkit Privilege Escalation Signal Hunter

Author: bcoles [email protected]

Type: Exploit

Pull request: #20643 contributed by bcoles

Path: linux/local/rootkit_privesc_signal_hunter

Description: Expands diamorphine privilege escalation module to other rootkits that use signal handling for privilege escalation.

Windows Persistent Task Scheduler

Author: h00die

Type: Exploit

Pull request: #20660 contributed by h00die

Path: windows/persistence/task_scheduler

Description: This adds a new persistence module for Windows – the task scheduler module. The module will create scheduled tasks depending on the ScheduleType option.

Enhancements and features (2)

  • #20523 from h00die – This updates the upstart persistence to use the new persistence mixin.
  • #20643 from bcoles – Expands diamorphine privilege escalation module to other rootkits, which use signal handling for privilege escalation.

Bugs fixed (1)

  • #20673 from adfoster-r7 – Temporarily pins date dependency to 3.4.1 due to possible issues associated with 3.5.0 to allow for further testing.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

5 Tools to Integrate Object Storage and Kubernetes

Post Syndicated from Maddie Presland original https://www.backblaze.com/blog/5-tools-to-integrate-object-storage-and-kubernetes/

A decorative image showing several cubes on a gradient background.

It’s no secret that Kubernetes is the de facto container orchestrator for scaling containerized applications. As the Backblaze team gets ready to head to KubeCon North America, we’ve been exploring the ecosystem of tools and integrations that make it easier to store application data in S3 compatible object storage.

From workarounds that make an object storage bucket behave like a persistent volume to cluster backups and early Cloud Native Computing Foundation (CNCF) storage projects we’re excited to watch, here’s a quick guide to making object storage services like Backblaze B2 Cloud Storage work (as close to) seamlessly with your Kubernetes clusters.

Mountpoint for Amazon S3 CSI Driver

AWS Labs released the mountpoint for Amazon S3 container storage interface (CSI) driver to allow Kubernetes clusters to access files in object storage through a file system interface. Essentially, this mountpoint disguises S3 compatible object storage as a persistent storage volume so the Kubernetes cluster can access your object storage without the need for another tool or integration. This also works with other S3 compatible storage services, including Backblaze B2. Check out our GitHub repo for step by step instructions on how to deploy a sample application to test with B2, or see this in action during our upcoming webinar, The State of K8s + S3 Compatible Storage.

MinIO

MinIO is a popular tool for running object storage natively inside Kubernetes clusters, by exposing data through standard APIs to enable containerized application to store, retrieve, and manage unstructured data. MinIO designed to run natively in Kubernetes, and allows you to bring-your-own S3 compatible storage or use your device’s local storage for a self-hosted solution. MinIO is flexible enough for individual developers to experiment with, but its power comes from its scalability, with 77% of Fortune 500 companies using MinIO in their cloud native workloads.

Velero

Rapidly creating and deleting infrastructure, and being able to quickly rebuild and recover are core tenets of Kubernetes. Velero makes it incredibly easy to back up Kubernetes clusters to your preferred object storage service. Run one-off backups as needed with one simple command, or set up a schedule to make sure your clusters are backed up consistently.

Read more about Kubernetes cluster security and backup strategy.

Rook

Rook is a storage orchestrator for Kubernetes that manages distributed storage systems (including Ceph and Cassandra) as native Kubernetes resources. Though Rook’s functionality doesn’t directly extend to S3 compatible object storage like Backblaze B2, you can mirror the data to B2 or set up your preferred object storage service as a backup destination. 

Container Object Storage Interface (COSI) (Currently available in Alpha)

The COSI project is a set of abstractions currently available in Alpha that aims to provide Kubernetes with the ability to request and provision object storage buckets from multiple cloud vendors, similar to how file/block storage is abstracted with the CSI driver. Since each cloud provider builds out object storage differently, COSI intends to provide a unified set of protocols so Kubernetes can be inclusive to all object storage vendors, and adhere to the Kubernetes portability tenet.

Learn more about these tools, see a demo of how to attach a Backblaze B2 bucket via the mountpoint for Amazon S3 CSI driver, and get some initial key takeaways from KubeCon North America during our upcoming webinar, The State of K8s + S3 Compatible Storage. Register to watch live on November 20, 2025 and get access to an on-demand recording.

The post 5 Tools to Integrate Object Storage and Kubernetes appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

[$] Bootc for workstation use

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

The bootc project allows users to
create a bootable Linux system image using the container tooling that many
developers are already familiar with. It is an evolution of OSTree
(now called libostree), which is used to create Fedora
Silverblue
and other image-based distributions. While creating
custom images is still a job for experts, the container technology
simplifies delivering heavily customized images to non-technical
users.

Security updates for Friday

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

Security updates have been issued by AlmaLinux (bind, bind9.16, libsoup, mariadb:10.5, and sssd), Debian (chromium, keystone, and swift), Fedora (apptainer, buildah, chromium, fcitx5, fcitx5-anthy, fcitx5-chewing, fcitx5-chinese-addons, fcitx5-configtool, fcitx5-hangul, fcitx5-kkc, fcitx5-libthai, fcitx5-m17n, fcitx5-qt, fcitx5-rime, fcitx5-sayura, fcitx5-skk, fcitx5-table-extra, fcitx5-unikey, fcitx5-zhuyin, GeographicLib, libime, mbedtls, mingw-poppler, mupen64plus, python-starlette, webkitgtk, and xen), Mageia (dcmtk, java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk, java-latest-openjdk, libvpx, and sqlite3), Oracle (bind, bind9.16, kernel, libsoup, libsoup3, osbuild-composer, qt6-qtsvg, sssd, and valkey), Red Hat (kernel and kernel-rt), SUSE (bind, gpg2, ImageMagick, python-Django, and runc), and Ubuntu (linux-azure, linux-azure-4.15, linux-fips, linux-aws-fips, inux-gcp-fips, linux-gcp, linux-gcp-6.8, linux-gke, linux-intel-iot-realtime, linux-realtime, linux-raspi-5.4, and linux-realtime, linux-realtime-6.8).

Threat Landscape of the Building and Construction Sector, Part One: Initial Access, Supply Chain, and the Internet of Things

Post Syndicated from Jeremy Makowski original https://www.rapid7.com/blog/post/tr-building-construction-sector-threat-landscape-initial-access-supply-chain-iot

In 2025, the construction industry stands at the crossroads of digital transformation and evolving cybersecurity risks, making it a prime target for threat actors. Cyber adversaries, including ransomware operators, organized cybercriminal networks, and state-sponsored APT groups from countries such as China, Russia, Iran, and North Korea, are increasingly focusing their attacks on the building and construction sector. 

These actors exploit the industry’s growing dependence on vulnerable IoT‑enabled heavy machinery, Building Information Modeling (BIM) systems, and cloud‑based project management platforms. 

Ransomware campaigns designed to disrupt project timelines, supply chain attacks exploiting third‑party software and equipment vendors, and social engineering schemes targeting on‑site personnel pose substantial operational and financial risks. Compounding this, data privacy mandates and regulatory scrutiny have intensified globally, pressing construction companies to implement robust cybersecurity measures. 

In this two-part series, Rapid7 is looking at the threats the construction industry faces, how threat actors are entering their networks, and the most common vulnerabilities construction industry security professionals should remediate now. 

Initial access and data leaks 

The construction sector faces escalating cyber threats as rapid digital transformation and heavy reliance on third-party vendors expose firms to new vulnerabilities. Cybercriminals increasingly target construction companies for initial access and data leaks, exploiting weak security practices, outdated legacy systems, and widespread use of cloud-based project management tools. Attackers commonly employ phishing email messages, compromised credentials, and supply chain attacks, taking advantage of insufficient employee training and lax vendor risk management. 

Notably, gaining initial access to a corporate network can be resource-intensive, prompting many threat actors to seek more accessible routes: purchasing access from underground forums where intermediaries and brokers sell credentials to previously breached networks across all industries, including construction. Access types traded, such as VPN, RDP, SSH, Citrix, SMTP, and FTP, are priced based on the target’s size and network complexity. 

Once inside, cybercriminals leverage interconnected systems to move laterally and exfiltrate valuable data, including blueprints, contracts, financial records, and personal information. The complex, collaborative nature of construction projects and the frequent exchange of sensitive documents amplify the risk, making the sector a prime target for corporate espionage, financial gain, and extortion through ransomware. This evolving threat landscape underscores the urgent need for robust cybersecurity measures and comprehensive vendor risk management within the industry.

TL1.png

Construction company network access for sale on the dark web

TL2.png

VPN/RDP/Cpanel access to a construction company for sale on the dark web

Social engineering and phishing campaigns

Social engineering and phishing campaigns are particularly effective in the building and construction industry as attackers exploit the industry’s workflow and human vulnerabilities. Cybercriminals frequently use phishing emails, SMS messages, and phone calls to impersonate project managers, suppliers, or executives. These communications often appear urgent, requesting immediate payment, sensitive information, or login credentials, making them difficult for busy staff to ignore.

Common attack vectors

  • Vendor impersonation: Attackers pose as legitimate suppliers to request changes in payment details or deliver fake invoices, exploiting the sector’s reliance on a broad network of subcontractors and vendors.

  • Executive impersonation (“CEO fraud”): Criminals spoof senior management to pressure employees into transferring funds or divulging confidential information.

  • Malicious attachments and links: Phishing messages often contain fake contracts, blueprints, or project documents, which, when opened, compromise credentials or deploy malware.

  • Compromised trusted platforms: Attackers exploit open redirects or compromised accounts on construction management tools to distribute phishing links that bypass basic email security checks.

Due to several unique operational challenges, the building and construction sector is particularly vulnerable to social engineering and phishing attacks. A dispersed and mobile workforce, with employees often working remotely or across multiple job sites, makes it challenging to verify unexpected requests or consult with IT and security teams in real time. 

The urgency to complete high-value transactions under tight project deadlines can encourage employees to bypass verification procedures and overlook warning signs of suspicious communications. Additionally, the sector’s complex supply chains, which involve frequent interactions with unfamiliar subcontractors, provide ample opportunities for attackers to infiltrate ongoing conversations unnoticed. 

This risk is compounded by varying levels of cybersecurity awareness among employees, particularly in smaller firms where consistent training is less common. These factors make the industry an attractive target for attackers and highlight the critical need for enhanced employee awareness, rigorous verification processes, and sector-specific cybersecurity measures.

Supply chain and third‑party risks

The construction sector’s dependence on a vast network of subcontractors, vendors, and technology providers has intensified its exposure to supply chain and third‑party cyber threats. Construction projects often involve dozens, sometimes hundreds, of different partners, each bringing their systems and security practices to the table. Unlike more centralized industries, construction companies rarely have complete visibility or control over the cybersecurity standards of every third party involved. 

This lack of uniformity creates significant blind spots that attackers can exploit. For example, a breach within a third-party software update or a compromised equipment supplier can quickly propagate throughout an entire project, causing costly delays, data loss, or operational paralysis. 

With tight deadlines and complex, geographically dispersed operations, construction firms may deprioritize cybersecurity vetting in favor of speed and cost, further compounding their risk. Effective mitigation now demands ongoing risk assessments, precise contractual cybersecurity requirements for all partners, real-time monitoring, and a collaborative approach to incident response, ensuring vulnerabilities are identified and addressed before they can impact critical projects.

Emerging threats: The Internet of Things (IoT) and Building Information Modeling (BIM)

The rapid adoption of IoT‑enabled machinery and Building Information Modeling (BIM) has transformed the construction landscape, enhancing efficiency and collaboration across project teams. However, these advances have also created new and unique points of vulnerability. 

The sector’s use of connected devices such as smart cranes, on-site sensors, and drones often operate in environments where cybersecurity is not traditionally a primary concern, and where devices may be physically accessible to outsiders or not consistently updated. Many IoT devices lack built-in security features, making them easy entry points for cyberattacks that could disrupt operations or threaten worker safety. 

Similarly, BIM platforms that centralize and share sensitive design and project data are now high-value targets, as a single compromise can reveal blueprints, project timelines, and operational details to attackers. Construction firms are particularly at risk because project sites frequently change, IT resources may be stretched thin, and digital assets are constantly being moved and accessed by different parties. 

Protecting these new technologies requires a shift in mindset: from viewing cybersecurity as a back-office concern to treating it as an essential component of on-site and digital operations, including secure device management, strong access controls, regular updates, and robust encryption practices.

Key threats and vulnerable points in IoT and BIM for construction:

  • IoT device vulnerabilities:

    • Weak authentication: Many IoT devices use default or weak passwords, making unauthorized access easier.

    • Unpatched firmware: Devices often lack regular updates, leaving known vulnerabilities open to exploitation.

    • Physical access risks: Construction sites are less secure environments, allowing attackers to tamper with or steal devices.

    • Insecure communication protocols: Data sent between IoT devices and central systems may be unencrypted or poorly secured, exposing sensitive information.

  • BIM threats:
    Centralized data breaches: BIM platforms hold all project data in one place so that a single breach can expose blueprints, schedules, and operational details.

    • Unauthorized access: Weak access controls or shared credentials can let unauthorized users download, alter, or leak sensitive project files.

    • Third-party collaboration risks: Multiple subcontractors or vendors may have access to BIM, increasing the risk of compromised accounts or insider threats.

Taking proactive steps to enhance cybersecurity

As the building and construction industry digitalizes, strengthening cybersecurity has become a business-critical priority. The following strategies address the sector’s unique challenges and offer a roadmap for reducing cyber risk.

Elevate cybersecurity to a core business priority

Historically, cybersecurity has been an afterthought in many construction firms. To change this, leadership must treat cybersecurity as essential to project delivery and business continuity. This requires investing in dedicated IT security staff, integrating cybersecurity into board-level discussions, and establishing clear policies for digital risk management throughout the organization.

Secure the digital supply chain

Given the sector’s reliance on a complex network of subcontractors and vendors, assessing and strengthening supply chain security is crucial. Firms should require vendors to meet baseline cybersecurity standards, conduct regular audits of third-party security practices, and ensure that project documents and data are shared through secure and encrypted channels. Construction companies can reduce the risk of supply chain-based attacks by holding all partners to strong security protocols.

Upgrade and harden legacy systems

Outdated software and systems remain prime targets for cybercriminals. Construction companies must thoroughly assess their IT environments, identify and replace unsupported or vulnerable technologies, and maintain a regular schedule of software updates and patching. Modern firewalls and endpoint protection further help to close critical security gaps.

Protect IoT devices and smart technology

Securing these devices is essential with the rapid adoption of IoT sensors, connected machinery, and advanced project management platforms. This means changing default passwords, disabling unnecessary services, and keeping IoT devices on networks separate from core business systems. Ongoing monitoring for unauthorized access or unusual activity helps to detect and respond to threats targeting these new endpoints.

Foster a security-aware culture

Human error is still a leading cause of cyber incidents, so regular cybersecurity training should be mandatory for all employees and contractors. Staff should be equipped to recognize phishing attempts, follow secure password practices, and report security incidents. Construction firms can strengthen their defense by building a culture where everyone understands their role in protecting digital assets.

Safeguard sensitive data and intellectual property

Protecting sensitive information such as blueprints, bids, client data, and proprietary designs is crucial. Data should be encrypted at rest and in transit, with strict access controls and permissions. Regular data backups and recovery testing are also important, along with using secure platforms for managing and sharing documents. These measures help prevent unauthorized access, data loss, and reputational harm.

As the industry reckons with its expanding digital footprint, understanding and mitigating the unique tactics and motivations of these threat actors in 2025 is prudent and imperative for ensuring project continuity, workforce safety, and reputational resilience. 

In the concluding installment of this two-part series, Rapid7 will look at how ransomware actors exploit many of the same weaknesses mentioned here. Stay tuned.

The collective thoughts of the interwebz