27 ноября 2024 в 19:30 состоится очередная встреча Санкт-Петербургской группы пользователей Linux.

Тема: "От бумажной ленты до полной интерактивности: 60 лет эволюции редактора TECO"

Редактор и язык TECO (Text Editor and Corrector) является по некоторым данным старейшим текстовым редактором и остался в общественной памяти из-за его исторической связи с Emacs и как прообраз "патологического языка программирования". В докладе представляются история редактора, основы синтаксиса и демонстрируются различные реализации. Эволюция редактора и языка TECO продолжается до сих пор в виде современного интерактивного редактора SciTECO для UNIX-систем и Windows, указывая на альтернативный путь развития текстовых редакторов.

Доклад ведёт сам автор SciTECO - Робин Хаберкорн.

Место: Миран, Евпаторийский переулок, 7, вход со стороны Пироговской набережной.

Сайт сообщества: spblug.org, вход - свободный, но объект - режимный, при себе нужно иметь документ удостоверяющий личность, паспорт или права.

Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешников" и "айтишников" заменят "роботы" 🌝

Сегодня мы с радостью готовы поделиться первой уязвимостью из реального мира, обнаруженной агентом Big Sleep: отрицательным переполнением (underflow) буфера стека с возможностью реализации эксплойтов в SQLite, — широко используемом опенсорсном движке баз данных. Мы обнаружили уязвимость и сообщили о ней разработчикам в начале октября, и они устранили её в тот же день. К счастью, мы обнаружили эту проблему до её появления в официальном релизе, так что она не затронула пользователей SQLite.

Как мы нашли уязвимость в SQLite при помощи LLM
https://habr.com/ru/articles/855882/

Оригинальный пост
https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html

Но я сейчас хотел бы не про это.

SQLite знаменит тем, что они очень трепетно относятся к тестированию своего кода.

В частности, тестового кода в 590 (пятьсот девяносто) раз больше, чем кода самого проекта

As of version 3.42.0 (2023-05-16), the SQLite library consists of approximately 155.8 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 590 times as much test code and test scripts - 92053.1 KSLOC.

Думаю говорить о том, что там 100% покрытие ветвлений не надо.

SQLite активно использует fuzzing. Использовать они его начали после того исследователь Михал Залевски (Michał Zalewski) нашёл 22 бага с помощью фаззера

Фаззинг нашёл 22 бага в SQLite за полчаса
https://xakep.ru/2015/04/16/fazzing-sqlite/

Оригинальный пост
Finding bugs in SQLite, the easy way
https://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html

Или, например, у них есть Valgrind, который позволяет отлаживать работу с оперативой, делать профилировку и обнаруживать утечки

SQLite делает ещё кучу всего, что бы сделать свой продукт лучше. Подробней можно почитать на отдельной странице - https://www.sqlite.org/testing.html

И в таких условиях всё равно находятся регулярно баги, что-то нужно править и т.д.

А теперь посмотрите на весь остальной код, который используется вами, пишется вами и в целом существует вокруг вас. Много ли проектов так же щепетильно подходят к его качеству? 🌝

Тут @SergeySabbath, закинул мой канал в тройку своих самых любимых. Скрывать не буду, мне очень приятно.

https://xn--r1a.website/IT_Friday/646

А накидайте в комменты свои любимые каналы по IT-шной тематике или около неё. Можно несколько.

Может я и подписчики найдут что-то новое и интересное для себя

Если брать строго IT, то я регулярно слежу за

https://xn--r1a.website/SysadminNotes

https://xn--r1a.website/itpgchannel

https://xn--r1a.website/dereference_pointer_there

https://xn--r1a.website/sysadmin_tools

Есть большое количество ещё других, ни о ком не забыл и всех помню, но как-нибудь сделаю ещё отдельный пост 🌝

LazyJournal - это терминальный пользовательский интерфейс (TUI) для journalctl, логов файловой системе и контейнеров Docker для быстрого просмотра и фильтрации, написанный на языке Go с использованием библиотеки gocui.

— Простая установка, для запуска достаточно загрузить в систему один исполняемый файл без зависимостей.
— Проект вдохновлен работами Jesse Duffield, по этому интерфейс будет знаком всем тем, кто уже использует LazyDocker и LazyGit.
— Для всех журналов присутствует возможность динамической фильтрации вывода с поддержкой нечеткого поиска (поиск всех фраз, разделенных пробелом в любом месте строки) и регулярных выражений (в стиле fzf и grep), а также подсветкой найденных слов.
— Позволяет получить список всех доступных журналов юнитов из journalctl (используется для чтения логов из подсистемы systemd).
— Возможность просматривать все доступные лог-файлы из каталога /var/log с сортировкой по дате изменения (например, для Apache, Nginx или СУБД), включая доступ к архивным логам.
— Поддержка логов контейнеров Docker.
— Проект будет полезен в первую очередь для системных администраторов Linux, больше не нужно вручную искать журналы в системе и каждый раз вызывать grep.

GitHub: https://github.com/Lifailon/lazyjournal

Лицо тех, кто предлагает SAP на 1С менять, представили?
https://xn--r1a.website/tech_b0lt_Genona/3093

«Сейчас большинство представителей ИТ-сферы объявляют, что могут практически все. – Рассуждает Ирина Пирогова. – Но, к сожалению это не так. Для нашей отрасли вся технология, а также соответствующие железо и софт были зарубежными. Мы не госструктура и мы не вынуждены замещать наш импортный и хорошо работающий у нас софт на российские программные продукты. На нашем рынке я не вижу желающих прийти и предложить нам импортозамещение».

В числе потерь в результате санкций «Илим» числит два зарубежных ПО, поставляемых по подписке: Think-cell (надстройка над PowerPoint) и Adobe для работы с pdf-файлами. Think-cell какое-то время удавалось использовать с помощью параллельного импорта, затем были предприняты попытки найти отечественное решение на замену, но они не увенчались успехом.
. . .
 «Илим» использует на производстве для развития технического обслуживания и ремонта веб-интерфейсы SAP PM (TOPO) для мобильных устройств и стационарных ПК с целью повышения удобства и эффективности использования SAP работниками технических служб
. . .
Измерительные системы лесозаготовки фиксируют данные об объеме заготовки, выполняемых работах и расходе горюче-смазочных материалов. Данные передаются по спутниковым каналам в систему SAP.
. . .
На горизонте планирования менее суток работа лесовозной техники выстраивается через оптимизатор SAP TM с целевой функцией минимизации затрат на вывоз.
. . .
«Мы будем использовать SAP до тех пор пока нам не предложат что-то лучшее, – констатирует Ирина Пирогова. – На наш взгляд вообще ничего не подлежит замене – нам просто это не нужно. Единственное с чем у нас реально проблема – это с АСУТП (автоматизированные системы управления технологическим процессом). Там у нас есть вопросы, потому что вендоры ушли, нет поддержки, местных специалистов у нас не хватает. Мы будем заменять системы АСУТП, но постепенно – в первую очередь то, что относится к объектам критической инфраструктуры».
. . .
Кроме SAP компания использует другие западные ИТ-решения. Например, PiSystem, работать с которой помогает российская компания и немецкая автоматизированная система управления производственными процессами MES, для которой у «Илим» есть собственные специалисты.

Из используемого отечественного ПО в компании используют «Систему слежения за вагонами и контейнерами «МЦ-Слежение», а также систему учета «Проконт». Впрочем в ближайшее время «Проконт» будет заменен на более современную систему на базе SAP.
. . .
«И когда к нам приходят представители ИТ-компаний – без этой цифры все остальное уже не интересно. – Рассказывает Ирина Пирогова. – Проекты должны приносить не только хайп, но и реальный экономический эффект. Пока мы нашли только одну компанию, которая готова идти с нами в какую-то конгломерацию, которая готова не за наш счет вести научно-исследовательские и опытно-конструкторские работы, а нести такие же риски как и мы в случае неудачного выполнения пилотного проекта».

Почему ИТ-директор крупной компании разгромила красивые презентации российских поставщиков
https://www.cnews.ru/news/top/2024-11-20_pochemu_biznes_ostaetsya_na

Тут wildberries выкатил набор утилит для анализа и визуализации сетевого трафика.

We support:
- Collecting network packets passing through nftables rules marked as 'nftrace set 1'.
- Storing collected traces in the Clickhouse database.
- Providing access to stored traces and flexible analytics.

Visor includes following utilities:
- pkt-tracer - daemon for collecting network packets that pass through nftables rules marked as 'nftrace set 1', and forward them to a server for storage.
- trace-hub - server that implements an API for receiving and storing traces in a database and providing access to them via an API.
- visor-cli - command-line network traffic analyzer for fetching and analyzing traces by applied filters.
- visor-ui - terminal user interface tier of visor-cli.

https://github.com/FR-Solution/pkt-tracer

В nftables существует метка для правил nftrace set 1; когда вы её устанавливаете, netlink может отслеживать трассировку трафика. Этот инструмент позволяет перехватывать данные и отправлять их в ClickHouse. Если имеется централизованный инструмент управления этими метками например SGroups (https://h-bf.prorobotech.ru/), то можно включать и отключать детектирование. Далее есть API-шлюз, через который можно получить трассировки по фильтрам и как в Cilium Hubble Relay (https://docs.cilium.io/en/stable/internals/hubble/#hubble-relay) визуализировать весь трафик со всех нод. Кроме того, он показывает, какое правило пропустило этот трафик, как оно выглядело на хосте и его расположение в момент разрешения.

Писать всякое можно только великодушным пожизненным диктаторам 🌝

Кент Оверстрит (Kent Overstreet), разработчик ФС Bcachefs, сообщил, что будущее развиваемой им файловой системы в ядре под вопросом из-за действий комитета, отвечающего за соблюдение кодекса поведения в сообществе разработчиков (CoC Committee). Линус Торвальдс отказался принимать очередной набор исправлений к Bcachefs в состав ветки ядра 6.13, сославшись на наличие претензий со стороны комитета CoC.
. . .
Блокировка Кента Оверстрита связана с оскорбительным выражением "Get your head examined. And get the fuck out of here with this shit.", высказанным в ходе дискуссии с Михалом Хочко (Michal Hocko), одним из разработчиков системы распределения памяти в ядре. Оскорбление заметили члены комитета CoC и попросили принести публичное извинение, на что Кент ответил отказом, посчитав недопустимым поднятие личных дел на публику и заявив, что они c Михалом уже решили этот вопрос в личном порядке. Кент также упомянул оставившие неприятный осадок уговоры с упоминанием необходимости поддержать имидж сообщества, но, по мнению Кента, продиктованные желанием сохранить привлекательность участия в проекте корпораций.
. . .
Кент подробно описал историю и своё видение конфликта, а также раскритиковал навязывание комитетом CoC рафинированного общения в сообществе, которое, по его мнению, нарушает сложившуюся инженерную культуру. Cпоры обычно возникают между людьми, глубоко заботящимися о своей работе, но имеющими разные точки зрения. В ходе горячих споров разработчики могут не сдержать свои эмоции и накричать друг на друга, но это принимаемый участниками рабочий процесс, который в итоге приводит к нахождению эффективного решения и движению проекта вперёд.
. . .
Кент признаёт, что не сдержался, пытаясь привести технические доводы, но получив в ответ формальные отговорки и не желание углубляться в детали. Отмечается, что конфликт с сопровождающим подсистему управления памятью (mm) зародился ещё год назад, когда сопровождающий отказался принимать изменение, необходимое для реализации легковесного механизма профилирования операций выделения памяти. Для работы механизма требовалось добавить макро-обвязки над функциями выделения памяти и сопровождающий отклонил их, опасаясь, что они могут негативно повлиять на производительность.

Спустя год ситуация повторилась при попытке добиться изменения, связанного с обработкой ошибок в файловых системах - сопровождающий подсистему mm опять отклонил изменение, на этот раз сославшись на возможное влияние на безопасность. По мнению Кента, сопровождающий не пожелал углубиться в детали и выслушать аргументы других разработчиков, согласившихся с необходимостью изменения, а ограничился лишь поверхностными суждениями (изменение было связано с принятием исключения, допускавшего обработку некоторых ошибок выделения памяти при выставленном режиме GFP_NOFAIL, запрещающем внешнюю обработку ошибок в критических секциях, таких как обработки транзакции журналирования в ФС, что приводит к принудительному завершению процесса, даже в ситуации, когда ошибку можно было обработать).

Кент также упомянул, что члены комитета CoC тоже не лишены эмоциональных выпадов, например, один из его участников при обсуждении в кулуарах на конференции позволял себе вполне оскорбительные выражения (назвал других разработчиков "asshole"). Такое поведение при личном общении на конференции не более приемлемо, чем в списке рассылки, и получается, что сторонники кодекса пытаются навязать другим правила, которые нарушают сами.

Автора BcacheFS временно отстранили от разработки ядра Linux из-за нарушения кодекса поведения
https://www.opennet.me/opennews/art.shtml?num=62276

https://www.opennet.ru/opennews/art.shtml?num=62286

https://foundation.rust-lang.org/news/rust-foundation-collaborates-with-aws-initiative-to-verify-rust-standard-libraries/

TL;DR - пока фанбои кричат, что "soundness достаточно", взрослые дяди занимаются формальной верификацией unsafe кода, потому что понимают, что memory "мамой клянусь"-safety - недостаточно!

А unsafe кода там прилично:

Currently, the Rust standard library contains approximately 35,000 functions, including 7,500 marked as unsafe.

Выложили доклады с UnderConf

https://plvideo.ru/@underconf/videos

Канал - @und3rc0nf
Чат - @und3rc0nf_chat

В апреле я выступал на DEFCON Ульяновск (https://xn--r1a.website/tech_b0lt_Genona/4418, @dc78422) и ребята пару дней назад домонтировали и выложили мой доклад

https://www.youtube.com/watch?v=8at3dX6UT6I

Этот доклад был сделан на основе моего воркшопа, который я делал на DEFCON в Нижнем Новгороде (https://xn--r1a.website/tech_b0lt_Genona/4304, @defcon_nn), но в Нижнем запись не велась (была любительская, собрать её в полноценный нормальный материал не удалось). Формат в Ульяновске не позволял воркшоп, поэтому я слегка переделал презу под доклад.

На основе воркшопа, который я проводил в Нижнем, я сделал воркшоп на SafeCode
https://safecodeconf.ru/talks/aae5116ee0fc4c8f8b921ebb46a14231/ и обязательно выложу запись сюда, когда она появится. Таким образом я смогу "закрыть" просьбы тех, кто спрашивал о записи из Нижнего Новгорода хотя бы таким образом.

ЗЫ Полный плейлист DEFCON Ульяновск 0x09
https://www.youtube.com/playlist?list=PLlZLWgwmfwCNDiMI6axyLnHfTGD_zjfK7

ЗЫЫ Мем для презы отдельно выдумывал, сюда закидывал https://xn--r1a.website/mem_b0lt_Genona/170 🌝

А когда начнут наказывать программистов за то что они пишут программы с багами? 🌝

Минэк предложил распространить оборотные штрафы за утечки персональных данных на поставщиков решений инфорбезопасности. В противном случае, введение штрафов приведет к банкротству четырех из пяти компаний малого и среднего бизнеса
. . .
 «Судя по комментариям представителей разработчиков продуктов информационной безопасности, они уверены в наличии всех необходимых решений для защиты данных. В связи с этим предлагается рассмотреть возможность распространения оборотных штрафов на самих разработчиков в случае, если утечка произошла, и специализированное программное обеспечение не смогло обеспечить должный уровень защиты», — отметил Владимир Волошин.
. . .
Руководитель группы по сопровождению GR-проектов ГК «Солар» Андрей Медунов отметил, что любая ответственность должна распространяться на лиц, которые повлияли на появление негативных последствий, но он не уверен, что этот вопрос необходимо вписывать в законодательство, поскольку его можно урегулировать в договорах.

Минэк предложил штрафовать разработчиков антивирусов за утечки данных
https://www.rbc.ru/technology_and_media/25/11/2024/6744c35a9a7947a67c8f5776

Мы обновили плагин kubectl-node-shell v1.11.0

- Добавились опции --no-mount, --no-net, --no-ipc, --no-uts для отключения автоматического входа в указанные linux-неймспейсы
- Добавилась переменная KUBECTL_NODE_SHELL_IMAGE_PULL_SECRET_NAME для указания pullSecret для пуллинга образа
- Добавилась возможность подключения томов с помощью опции -m, подключённые тома могут быть найдены в директории /opt-pvc

Большое спасибо @jmcshane, @huandu и @bernardgut, которые добавили эти замечательные функции в новую версию плагина

Выложены доклады с KazHackStan 2024

Плейлист
https://www.youtube.com/playlist?list=PL6yKM2nb4YL2v-0P7GHXyfps46g1OQoTu

Программа доступна тут
https://kazhackstan.com/ru

ЗЫ Есть кто из подписчиков, кто может передать оргам, у них там серт на сайте протух 3 дня назад 🌝

ЗЫЫ Обновили серт

Яндекс признал и осознал, что не может не радовать

15 октября мы раскатили прошивку на 10% устройств. Поэтапная раскатка обновления — это стандартная практика. Она предназначена в том числе для того, чтобы выявлять проблемы новых версий на ранней стадии. И прежде чем увеличивать процент раскатки, мы отсматриваем метрики всех ключевых пользовательских сценариев. Но число генерируемых нами NTP‑запросов исторически никогда не входило в метрики, требующие валидации, потому что NTP‑клиент годами существовал практически без изменений и не приводил к проблемам.

К 24 октября новая прошивка докатилась до 100% колонок. Опять же, критичные для пользователей сценарии покрыты автоматическим мониторингом. Если что‑то важное ломается, мы получаем уведомление. Но, как вы уже догадались, для NTP‑клиента таких уведомлений настроено не было.
. . .
Жалоб было мало, действующий регламент поддержки не был рассчитан на подобные ситуации, поэтому обращения рассматривали не в самом высоком приоритете. К 20 ноября мы нашли ошибку, внесли исправление в код и начали готовить новый релиз.

В выходные 23–24 ноября ситуация с NTP‑серверами обостряется: доступными остаются лишь четыре сервера. К этому моменту мы уже начали раскатывать релиз с исправлением на 10% устройств.
. . .
В воскресенье мы выпустили хотфикс в виде новой рантайм‑конфигурации для NTP‑клиента, который увеличивал период перезапроса с 5 до 600 секунд, уменьшая нагрузку на серверы в 120 раз. Хотфикс не исправлял проблему полностью, но был единственным быстрым способом снять чрезмерную нагрузку с NTP-серверов.
. . .
мы запланировали выделить ресурсы в общий пул NTP‑серверов. Это займёт некоторое время, потому что наши дата‑центры удалены от основных точек обмена трафиком, а для NTP‑серверов RTT (Round Trip Time) это — ключевой фактор качества. Мы установим и запустим мощности на основных точках обмена трафиком.

Для наших устройств мы заведём именную зону в соответствии с гайдлайнами проекта NTPPool.org для бо́льшей прозрачности. Генерируемый ими трафик будет локализован на наших NTP‑серверах, если мы продолжим полагаться на публичную инфраструктуру проекта.

Ещё мы добавим метрики, связанные с NTP, на этап валидации A/Б‑экспериментов, а также реалтайм‑уведомления о неполадках в этом компоненте. В том числе расширим сценарии мониторинга исходящего и входящего служебного трафика устройства в целом. Также поработаем над каналами коммуникаций и поддержкой, чтобы подобные проблемы быстрее до нас эскалировались.

Об инциденте с NTP-серверами
https://habr.com/ru/companies/yandex/articles/861538/

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