Инго Молнар (Ingo Molnar), мэйнтейнер архитектуры x86, механизма блокировок и планировщика задач в ядре Linux, выставил на обсуждение набор патчей, удаляющих из ядра поддержку процессоров 486 (M486, M486SX, AMD ELAN) и начальных серий процессоров 586. В ядре предлагается оставить только возможность работы с процессорами x86, поддерживающими инструкцию CX8 (CMPXCHG8B) и регистр TSC (Time Stamp Counter), которые появились в CPU Pentium.

Отмечается, что для поддержки CPU 486 в ядре приходится держать код, эмулирующий операции CX8 (сравнить и обменять 8 байт) и TSC (счётчик циклов CPU, используемый в планировщике задач). Подобный код усложняет ядро, затрудняет сопровождение и временами становится источником проблем, разбор которых отнимает время у разработчиков. Прекращение поддержки 486 позволит удалить из ядра 14104 строки кода, что значительно упростит некоторые функции в ядре за счёт исключения прослоек, эмулирующих CX8 и TSC, и позволит избавиться от библиотеки math-emu, эмулирующей FPU.

За день до публикации патчей вопрос целесообразности удаления поддержки 486 поднял Линус Торвальдс при обсуждении очередной проблемы, проявляющейся при эмуляции CX8. Линус считает, что настало время отказаться от поддержки CPU 486 и не видит причин, чтобы продолжать тратить время разработчиков на решение возникающих из-за них проблем. Поддержка процессоров 386 была удалена из ядра в 2012 году. По мнению участников дискуссии, сейчас настало время для удаления поддержки CPU 486. В октябре 2022 года Линус уже публиковал подобное предложение, но оно не получило развития.

The main problem is time. The URLs accessed in the attack are the most expensive ones the wiki offers since they heavily depend on the database and are highly dynamic, requiring some processing time in PHP. This is the worst-case scenario since it throws the server into a death spiral.

First, the database starts to lag or even refuse new connections. This, combined with the steadily increasing server load, leads to slower PHP execution. Eventually, all resources in the PHP-FPM pools are used up, and since Apache2 doesn’t get a reply from PHP-FPM in time, it waits until it runs out of free connections. At this point, the website dies. Restarting the stack immediately solves the problem for a couple of minutes at best until the server starves again.
. . .
As a regular user, all you’ll notice is a loading screen when accessing the website. As an attacker with stupid bots, you’ll never get through. As an attacker with clever bots, you’ll end up exhausting your own resources. As an AI company trying to scrape the website, you’ll quickly notice that CPU time can be expensive if used on a large scale.

Long story short, deploying Anubis immediately solved our issues. In fact, you can see the exact time in our monitoring.

res, err := myFunc()
if err != nil {
    // что-то делать
}

That's it. I've had it. I'm putting my foot down on this craziness.

1. Every reporter submitting security reports on #Hackerone for #curl now needs to answer this question:

"Did you use an AI to find the problem or generate this submission?"

(and if they do select it, they can expect a stream of proof of actual intelligence follow-up questions)

2. We now ban every reporter INSTANTLY who submits reports we deem AI slop. A threshold has been reached. We are effectively being DDoSed. If we could, we would charge them for this waste of our time.

We still have not seen a single valid security report done with AI help.

What is easyjson?

Easyjson is a Go package designed to optimize JSON serialization and deserialization processes by generating Go code for JSON encoding and decoding. Widely adopted across cloud-native ecosystems, it is a critical dependency for numerous open source and enterprise projects. This includes high-performance JSON handling in distributed systems, real-time data serialization for financial and analytics platforms, and optimization of cloud-native applications.

Who maintains easyjson?

A group of developers from VK, an entity with leadership that is under active U.S. and E.U. sanctions and has connections to Russian security services.

Who is impacted?

Cornerstones of the modern software supply chain and cloud-native tools have dependencies on easyjson, and all applications that pull in these dependencies could potentially be impacted, including, but not limited to:

- Helm
- Istio
- Kubernetes

How could this be weaponized or exploited?

Russia doesn’t need to attack directly. By influencing state-sponsored hackers to embed a seemingly innocuous OSS project deep in the American tech stack, they can wait, watch, and pull strings when it counts.

Hunted Labs has provided exhaustive evidence regarding this advisory to the U.S. government and relevant stakeholders. So, what’s next? 

The widespread use of easyjson makes finding a solution challenging. However, we cannot continue to blindly rely on this package due to the state of the current threats to our increasingly fragile software supply chain.

Компания Canonical намерена в осеннем выпуске Ubuntu 25.10 задействовать по умолчанию аналог утилиты sudo, развиваемый проектом sudo-rs и написанный на языке Rust. В марте аналогичное решение было принято в отношении замены утилит GNU Coreutils на инструментарий uutils. На стадии рассмотрения находятся инициативы по замене zlib и ntpd на zlib-rs и ntpd-rs, а также задействованию Sequoia вместо GnuPG в пакетном менеджере APT.

В sudo-rs по возможности обеспечена совместимость с классическими утилитами sudo и su, позволяющая использовать sudo-rs в качестве прозрачной замены sudo в большинстве сценариев использования. Для пользователей, не желающих переходить на uutils и sudo-rs, в Ubuntu 25.10 будет предоставлена опция для отката на классические варианты системных утилит coreutils и sudo.
. . .
Замена системных компонентов производится в рамках инициативы по повышения качества системного окружения через поставку программ, изначально разрабатываемых с оглядкой на безопасность, надёжность и корректность. Поставка утилит, написанных на языке Rust, даст возможность снизить риск появления ошибок при работе с памятью, таких как обращение к области памяти после её освобождения и выход за границы буфера. Если эксперимент будет признан удачным, то утилиты на Rust будут задействованы по умолчанию в LTS-ветке Ubuntu 26.04.

For example we could add a user to the system containing the username `../../../../bin/cp`. When logged in as a user with that name, that user could run `sudo -K` to clear their session record file. The session code then constructs the path to the session file by concatenating the username to the session file storage directory, resulting in a resolved path of `/bin/cp`. The code then clears that file, resulting in the `cp` binary effectively being removed from the system. An attacker needs to be able to login as a user with a constructed username. Given that such a username is unlikely to exist on an existing system, they will also need to be able to create the users with the constructed usernames...The `sudo -K` and `sudo -k` commands can run, even if a user has no sudo access.

Kubernetes relies on Linux containers and cgroups, so you can't run Kubernetes or even docker containers directly on OpenBSD, but Alpine Linux runs great under OpenBSD's VMM hypervisor. Alpine shares a lot of the same ideologies as OpenBSD, and it has become a favorite in the Linux container ecosystem.
. . .
This is not a good project for someone who’s never used OpenBSD before. I make some assumptions that you’re generally familiar with OpenBSD and performing routine system administration and housekeeping tasks.

This is not a supported configuration. I’ve been running kubernetes on OpenBSD’s VMM hypervisor in my home lab for about 7 months as of the time of writing. I wanted to play with Kubernetes at home, and at the time, my Dell PowerEdge R410 running OpenBSD was the only thing I had available, so I decided to try this out. Occasionally, the network or nodes lag a little, but it’s been pretty stable for the most part.

There are a few limitations to this setup. VMM currently has no way to allocate more than one CPU core to a VM. This causes two problems for Kubernetes:

First is that Kubernetes’ master node minimum requirement is for 2 cores. We can override it, and it seems to run with just one core, but it’s not optimal.

Second is that some workloads may request more than 1 CPU worth of computing resources for a pod. The master node will be unable to find a node that can support that pod, because these worker nodes will only have one core, or 1000 milli-cores, of CPU capacity each. If you see errors like “Unschedulable” and “Insufficient cpu,” this is one potential reason.

The head of the US Copyright Office has reportedly been fired, the day after agency concluded that builders of AI models use of copyrighted material went beyond existing doctrines of fair use.

The office’s opinion on fair use came in a draft of the third part of its report on copyright and artificial intelligence. The first part considered digital replicas and the second tackled whether it is possible to copyright the output of generative AI.

The office published the draft [PDF] of Part 3, which addresses the use of copyrighted works in the development of generative AI systems, on May 9th.

The draft notes that generative AI systems “draw on massive troves of data, including copyrighted works” and asks: “Do any of the acts involved require the copyright owners’ consent or compensation?”
. . .
Tech law professor Blake. E Reid described the report as “very bad news for the AI companies in litigation” and “A straight-ticket loss for the AI companies”.

Among the AI companies currently in litigation on copyright matters are Google, Meta, OpenAI, and Microsoft. All four made donations to Donald Trump’s inauguration fund.

 Our partners in object storage, Tigris Data, were conducting some kind of load testing exercise. Some aspect of their testing system triggered the TlsStream state machine bug, which locked up one or more TlsStreams in the edge proxy handling whatever corner-casey stream they were sending.

Tigris wasn’t generating a whole lot of traffic; tens of thousands of connections, tops. But all of them sent small HTTP bodies and then terminated early. We figured some of those connections errored out, and set up the “TLS CloseNotify happened before EOF” scenario.

Keep your dependencies updated. Unless you shouldn’t keep your dependencies updated. I mean, if there’s a vulnerability (and, technically, this was a DoS vulnerability), always update. And if there’s an important bugfix, update. But if there isn’t an important bugfix, updating for the hell of it might also destabilize your project? So update maybe? Most of the time?

Really, the truth of this is that keeping track of what needs to be updated is valuable work. The updates themselves are pretty fast and simple, but the process and testing infrastructure to confidently metabolize dependency updates is not.

&mut fp_io::copy::Duplex<&mut fp_io::reusable_reader::ReusableReader<fp_tcp::peek::PeekableReader<tokio_rustls::server::TlsStream<fp_tcp_metered::MeteredIo<fp_tcp::peek::PeekableReader<fp_tcp::permitted::PermittedTcpStream>>>>>, connect::conn::Conn<tokio::net::tcp::stream::TcpStream>

Давайте еще раз вспомним, что поможет нам убить хороший продукт.

- Не тестировать код
Тестирование — это для слабаков! Настоящие разработчики пишут код и надеются на лучшее

- Публиковать релизы в пятницу вечером
Никто не будет работать над исправлениями до понедельника, все хорошенько отдохнут! Суеверия для дураков

- Чрезмерная документация
Напишите столько документации, чтобы пользователи не поняли, зачем они пришли к вашему продукту, а тестировщики забыли что вообще нужно проверить 
Пусть они потратят часы на чтение вместо проверки!

- Использовать устаревшие технологии
Зачем обновлять? Они работали когда-то, значит, будут работать и сейчас

- Игнорировать отзывы пользователей
Зачем слушать тех, кто использует продукт? Это  ведь мы его сделали, значит знаем, что для них лучше

- Обвинять друг друга при любых проблемах на проекте
Потому что гораздо важнее найти крайнего, а не решить проблему

Например, Telegram — не лучшее решение для внутренней корпоративной коммуникации.
Существуют как очевидные проблемы:

- отсутствие SSO (логина через корпоративную учетку)

- слабые возможности по обеспечению безопасности

- невозможность централизованного поиска сотрудников по имени

Так и более тонкие, которые становятся заметны только с опытом:

- отсутствие поддержки внутренних ролей и тегов (команд, гильдий, лидов)

- невозможность задать единые стандарты наименования и организации чатов

- отсутствие глубоких интеграций с другими корпоративными сервисами

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

- неудобная работа с оргструктурой

- отсутствие из коробки набора полезных ботов и автоматизаций

Но, думаю, главный недостаток — невозможность эффективно доносить важную информацию до всей компании. В Telegram невозможно выстроить каналы массовой коммуникации так, чтобы они были одновременно централизованными, структурированными и не утопали в шуме. Универсальный чат на 100+ человек быстро становится бесполезным: уведомления сразу же отключают из-за флуда и хаоса. Результат — бесконечное размножение мелких групп, где каждый раз собирается новый состав и информация теряется. Какой выход? Только искать альтернативы привычному.