Кто там в IT хотел вкатиться 🌝

Освой направление Perl-разработки на оплачиваемой стажировке и получи возможность стать квалифицированным сотрудником Газпромбанка.

 https://gpb.fut.ru/itfactory/ 

Может показаться, что это реклама, но я просто охуел и всё.

Lightweight fuzzing of a memory snapshot using KVM

Snapchange provides the ability to load a raw memory dump and register state into a KVM virtual machine (VM) for execution. At a point in execution, this VM can be reset to its initial state by resetting the dirty pages found by KVM or pages manually dirtied by a fuzzer.

Announcing Snapchange: An Open Source KVM-backed Snapshot Fuzzing Framework
https://aws.amazon.com/blogs/opensource/announcing-snapchange-an-open-source-kvm-backed-snapshot-fuzzing-framework/
+
https://github.com/awslabs/snapchange

Спасибо подписчику за ссылку.

У @flant_ru увидел новость, про то что Ansible на Rust переписывают.

В первую очередь, конечно, интересует совместимость с существующими плейбуками.

Её вроде обещают

> Aiming for roughly 90-95% compatibility with existing playbooks, including all critical language features.

> Ability to execute existing Ansible python modules via a language wrapper, transparently. As such, we may ship with a bare minimum of modules at the first release.

A New IT Automation Project? Moving Beyond Ansible And Keeping The Spirit - An Invitation
https://laserllama.substack.com/p/a-new-it-automation-project-moving
+
https://www.jetporch.com/

Ждём когда на GitHub выложат, будем посмотреть.

Cost Optimisation In The Cloud – Practical Design Steps For Architects and Developers – Part 1
https://automation.baldacchino.net/cost-optimising-your-architecture-on-azure-practical-design-steps-for-builders-to-cost-optimise-your-tech-stack/

Part 2 – Infrastructure Cost Optimisation In The Cloud – Practical Design Steps For Architects and Developers
https://automation.baldacchino.net/cost-optimising-your-architecture-on-azure-practical-design-steps-for-builders-to-cost-optimise-your-tech-stack-part-2/

Part 3 – Architectural Cost Optimisation – Practical Design Steps for Architects and Developers
https://automation.baldacchino.net/part-3-architectural-cost-optimisation-practical-design-steps-for-architects-and-developers/

🫡

Наиболее активный сопровождающий дистрибутива Alpine Linux, работавший под ником psykose, сложил с себя полномочия, заблокировал свои учётные записи и прекратил работу в проекте. После ухода psykose без сопровождения осталось около 400 пакетов. По статистике проекта за 2023 год ушедшим разработчиком было произведено более половины всех изменений в скриптах сборки пакетов aports (13894 из 26893). Для сравнения находящийся на втором месте сопровождающий внёс 2054 изменений, а на третьем - 894. Судя по всему причиной ухода является эмоциональное выгорание и желание сменить деятельность, а в качестве планов упоминается лишь намерение выспаться после хронического недосыпа.

Alpine Linux покинул наиболее активный сопровождающий
https://www.opennet.ru/opennews/art.shtml?num=59526

A new method for container escape using file-based DirtyCred

An article by Choo Yi Kai about escaping a Docker container by overwriting /proc/sys/kernel/modprobe via the DirtyCred exploitation technique.

The article also describes a way to delay the page fault handler via FALLOC_FL_PUNCH_HOLE for winning a race condition, similar to the commonly-used userfaultfd and FUSE–based techniques.

Trail of Bits на грант от DARPA запилили исследование тулинга вокруг Clang

Выглядит оно увлекательно (все врут)

The Clang AST is a lie
The Clang CFG is a (pretty good) lie
LLVM IR as the one true IR is a lie
Encore: the lib in libClang is a lie
Encore the second: compile_commands.json is a lie
Final encore: Compilers textbooks are lying to you (sort of)

На самом деле есть вопросы к посту, потому что в конце они рассказывают про свой тулинг (возможно, пост специально написан в таком ключе), но почитать всё равно интересно.

Тулинг от ToB

VAST is an experimental compiler pipeline designed for program analysis of C and C++
https://github.com/trailofbits/vast

Peter's Amazing Syntax Tree Analyzer
https://github.com/trailofbits/pasta

Полностью по ссылке

The future of Clang-based tooling
https://blog.trailofbits.com/2023/07/28/the-future-of-clang-based-tooling/

До сих пор тестовые выпуски Asahi Linux базировались на пакетной базе Arch Linux. 
. . .
Переход обусловлен тем, что Fedora Linux имеет официальную поддержку ARM64 в upstream ветке. Кроме того, переход поможет команде Asahi Linux сфокусировать усилия на обратном инжиниринге оборудования, в то время как Fedora Asahi будет заниматься поддержкой дистрибутива. Также миграция на Fedora позволит разработчикам Asahi Linux напрямую взаимодействовать с сопровождающими upstream репозиториев Fedora для исправления проблем в сборках ПО.

Проект Asahi переводит свой дистрибутив для ARM-чипов Apple на Fedora Linux
https://www.opennet.ru/opennews/art.shtml?num=59545

Я тут решил разобраться с тем как работает cloud-init чтобы найти хоть какие-то спецификации для конфигурации. Забегая вперёд скажу - их нет. С архитектурной точки зрения это просто какой-то ужас. Но что-то откопать таки удалось.

Начнём с того что cloud-init поддерживает большое количество датасорсов, там и OpenStack, и OpenNebula, и AWS, и Azure, и Google Cloud, и всё такое…

Все они собираются в единую структуру - instance metadata, которая слава богу имеет стандартизированную спеку. Её можно использовать в скриптах и темплейтах, но передать её напрямую ни через один датасорс нельзя.

Что же из себя представляет датасорс? Как правило это метод получения конфигурации из облака, который, в зависимости от облака в котором работает, превращает метаданные облака в instance metadata. Меня интересовали в первую очередь форматы OpenStack configDrive и NoCloud, которые позволяют передавать метаданные инстанса через ISO или файловую систему со специально определённый лейбл.

И тут начинается самое весёлое, так как единого стандарта нет, но есть некоторые негласные соглашения. А именно, что данные передаются в виде четырёх структур: meta-data, user-data, vendor-data и network-config (именование может быть разное, но суть примерно одна)

- meta-data - более-менее общий для всех клаудов, в нём чаще всего передают instance-id, local-hostname и public-keys для ssh.
- user-data - позволяет принимать в себя cloud-config структуру, которая тоже не стандартизирована, но тоже имеет общепринятые поля, либо вообще может быть чем угодно, например баш-скриптом, jinja-темплейтом для cloud-config’а или скрипта, так и конкатенировать в себя всё вышеперечисленное.
- vendor-data - тоже самое что и user-data, но по логике предоставляется вендором, а не пользователем
- network-config - у разных вендоров разный, но в NoCloud он более-менее стандартизирован и представляет собой конфиг netplan в чистом виде.

https://fuckjava.com

Подглядел в одном из закрытых чатов.