Папищек подсказал про #prog квиз по email-адресам:

e-mail.wtf

Я набрал 15/21

(thanks @bushes_in_my_mind)

#prog #rust хайлайты:

Реализовали derive через macro_rules!-макросы. Учитывая, насколько часто код, генерируемый derive, весьма простой, это позволит сильно упростить их написание, а также избежать выделения отдельного крейта только под процедурный макрос и, разумеется, не компилировать макрос в отдельную программу, которая общается с компилятором по RPC.

#prog #rust #itsec #article

hyper HTTP/2 (Didn't) MadeYouReset

Протокол HTTP/2 позволяет открыть несколько стримов поверх одного соединения, каждый из которых может быть отменён (reset) любой стороной в любой момент. В некоторых случаях это нужно сделать обязательно — например, когда одна из сторон присылает невалидные сообщения. Это сделало возможным уязвимость, названную MadeYouReset. Суть её в том, что злоумышленник инициирует соединение с максимально возможным числом стримов, а затем постоянно их сбрасывает путём отправки невалидных фреймов. Обработка всех этих запросов и следование протоколу отнимает ресурсы сервера, что делает возможным Denial of service.

Эта уязвимость очень схожа с уязвимостью Rapid Reset, но, как описано в статье от Cloudflare, она несколько более хитрая. Rapid Reset полагается на явную отмену стримов клиентом через посылку фрейма RST_STREAM. MadeYouReset же работает через посылку невалидных фреймов, заставляя сервер парсить запросы и отменять стримы уже с его стороны.

Многие реализации HTTP/2 на практике делали работу по обработке запроса даже после закрытия стрима. Простые меры предосторожности против Rapid Reset, отслеживающие только фреймы RST_STREAM от клиента, бесполезны против MadeYouReset.

h2 (Rust-библиотека для работы с протоколом HTTP/2) оказалась не подвержена этой уязвимости. Почему? На это есть несколько причин.

Во-первых, в h2 несколько лет назад добавили меру предосторожности против абьюза клиентами отмен стримов. Именно, h2 отслеживает, сколько раз фрейм от клиента привёл к отмене стрима со стороны клиента, и когда это число достигает настраиваемого порога, закрывает соединение целиком. Это уже хорошая защита, которая на практике успешно защищала от Rapid Reset, но она была не безупречна — для одного типа фреймов (WINDOW_UPDATE) на одном из путей исполнения это число не обновлялось (разумеется, это поправили).

Во-вторых, h2 — библиотека, а не фреймворк, и всегда передаёт вызывающему коду информацию об отмене стрима. Разумеется, от этого мало толку, если вызывающий код на это никак не реагирует.

И это подводит нас к третьей причине: контекст использования. На практике h2 использовалась совместно с hyper, Rust-библиотеке для HTTP, абстрагированной от конкретной версии протокола. В коде hyper для стримов ожидается исполнение двух футур: поставляющей новые фреймы из стрима и обрабатывающей запросы из этого стрима. При получении отмены стрима hyper отменяет футуру, обрабатывающую запрос.

Итого: даже без закрытия бага с WINDOW_UPDATE h2 не был подвержен MadeYouReset. Разумеется, это во многом заслуга продуманной архитектуры h2 и hyper. Но также это и заслуга того, как реализована асинхронность в Rust: с ключевым методом Future::poll, позволяющим достаточно просто дожидаться исполнения нескольких футур одновременно, и встроенная поддержка отмены футур просто через вызов drop. Добиться подобной защиты от MadeYouReset в языке с активными тасками и явной в коде отменой (как, например, в C# или в Go с context.Done) значительно сложнее.

— У вас стандартная библиотека работает неправильно.
— Используйте железо, на котором работает правильно.

#prog #go #suckassstory

Source

#prog #abnormalprogramming #article

This blog is hosted on a Nintendo Wii

#prog #rust #article

Shortcomings of Procedural Macros

Или как в процедурный макрос, определённый на impl-блоке, прокинуть информацию о методах с реализацией по умолчанию из определения трейта.

Спойлер: всё в рамках языка, без IO между макросами, но выглядит всё равно как хак.

#prog #rust

TIL что квалификатор видимости pub в Rust может иметь форму pub(self), что эквивалентно pub(in self) или отсутствию pub вообще.

Нет, я не знаю, зачем.

#prog #article

Writing Mac and iOS Apps Shouldn’t Be So Difficult

Вопреки названию, не специфично для эппловских платформ.

The app was implemented in two pieces:

The kernel, written in C, implemented the database, networking, inter-application communication, various built-in data types, script compiler and evaluator and debugger, and so on
The scripts used the kernel and implemented most of the actual app behavior

Since it was an app, it had plenty of UI — menus, contextual menus, buttons, larger UI components, and so on. What was brilliant was that you could, for instance, add and edit menus, and when you chose a menu command it would run your script. (Or when you clicked a toolbar button, etc.)

You could write an entire static blog publishing system and the UI to go with it without ever restarting the app. Click a thing, then see what happens in the app — and if it’s not right you’d edit the script, which would be automatically recompiled when called the next time.

In other words, there was absolutely no friction when it came to iteration. Write some code without restarting and see your changes immediately.

But I wanted to bring up a second aspect to this: it’s not just frictionless iteration that was so great, it was also the scripting language and environment.

One of the best parts of this was how easy persistence was. I mentioned the hash-table-based database. Hash tables could contain hash tables

<...>

In any script, at any time, without any ceremony, you could read and write from the database simply using dot notation: user.prefs.city = "Seattle" would set the value of city in the prefs table which was contained by the user table. This value would persist between runs of the app, because it was stored in the database.

I’ll remind you of the timing: this was the ’90s. We worked this way for real, and we were amazingly productive.


Автор также отмечает, что в силу того, что скрипты также хранились в базе данных, это позволяло применять обновления приложения без рестарта и без копирования большого количества нативного кода.

#prog #article

Faster Rust builds on Mac

Did you know that macOS has a secret setting that can make Rust builds faster? It can also make Rust tests faster (sometimes massively so). It probably even has similar effects for other compiled languages such as C, C++, Go, and Swift. It sounds crazy, but read on…

Nicholas Nethercote заметил, что на Mac компиляция одного Rust-проекта была подозрительно долгой. Замеры времени компиляции через cargo показали, что очень долго исполняются билд-скрипты, причём каждый следующий дольше предыдущего. Как оказалась, это антивирусная фича MacOS (называется XProtect), которая сканирует исполняемые файлы на признаки malware при первом запуске. Билд-скрипты компилируются и исполняются каждый раз заново при компиляции, поэтому постоянно страдают от этих задержек. Замедление же объясняется тем, что процесс, который сканирует исполняемые файлы, однопоточный.

You can avoid these scans by adding Terminal (or any alternative terminal app you are using, such as iTerm) as a “developer tool” in System Settings. See these docs for details.

<...>

Please note that if you do this you are disabling an OS security feature. You should not do it unless you are comfortable with the potential speed/security trade-off.

По очевидным причинам это ускоряет и cargo run, и cargo test (особенно для доктестов до edition 2024, каждый из которых компилируется в отдельный бинарник).

The status quo is that this behaviour is documented in a few obscure places and 99%+ of Mac users are unaware. Fortunately, Mads [Marquart] has a draft PR for Cargo that detects if XProtect is enabled and issues a warning to the user explaining its impact and how to disable it.

Из забавного: отключение XProtect снизило для Mads Marquart время для прогона всех UI-тестов rustc (около 4000 исполняемых файлов) с 9 мин 42 с до 3 мин 33 с.

#prog #rust

Faster linking times with 1.90.0 stable on Linux using the LLD linker

TL;DR: rustc will start using the LLD linker by default on the x86_64-unknown-linux-gnu target starting with the next stable release (1.90.0, scheduled for 2025-09-18), which should significantly reduce linking times.

From our prior testing, we don't really expect issues to happen in practice. It is a drop-in replacement for the vast majority of cases, but lld is not bug-for-bug compatible with GNU ld.

In any case, using rust-lld can be disabled if any problem occurs: use the -C linker-features=-lld flag to revert to using the system's default linker.