Харальд Вельте (Harald Welte), известный разработчик ядра Linux, лауреат премии за значительный вклад в развитие свободного ПО, основатель организации gpl-violations.org, создатель проекта Openmoko и один из разработчиков netfilter/iptables, опубликовал своё мнение относительно удаления участников из списка мэйнтейнеров ядра Linux на основании их предполагаемой работы в подсанкционных компаниях. По словам Харальда, он гордился вовлечённостью в работу сообщества разработчиков ядра, но нынешнее сообщество не похоже на то, которое он помнит, и ему больно видеть, что сейчас там происходит. По его мнению нет ничего хуже дискриминации людей только из-за их паспорта, места жительства или места работы.
. . .
Помимо дискриминации разработчиков на основе их имени, email или работодателя, удивление вызвало то, что удаление произведено без каких-либо объяснений. Последующие разъяснения дали понять, что дело в санкциях, и удаление выполнено на основе консультации с юристами, но при этом не было предоставлено полного юридического анализа и не были отмечены вовлечённые в необходимость выполнения санкций субъекты (Linux Foundation? разработчики из США? Создатели дистрибутивов?).

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

Но даже в случае предоставления убедительных юридических доводов, перед фактическим исключением мэйнтейнеров было бы правильным провести публичное обсуждение, попытаться найти способ обойти требования юристов и организовать общественное движение против. В крайнем случае, если обходные пути не были бы найдены, по мнению Вельте, можно было ожидать гражданского неповиновения или оставления в файле MAINTAINERS пояснений о том, что удаление стало вынужденной мерой. Вместо этого наиболее значимые разработчики без лишней огласки в составе исправлений символьных драйверов применили патч с размытой формулировкой и тем самым проявили неуважение к работе удалённых участников и показали другим разработчикам как в сообществе люди относятся друг к другу.

Харальд Вельте выразил сожаление о том, во что превратилось Linux-сообщество
https://www.opennet.ru/opennews/art.shtml?num=62112

Чат, привет!

Я выпустил новую версию NextBox UI Plugin для отрисовки сетевых топологий в NetBox, и это самый большой релиз за 4 года его существования:

– Новый движок визуализации, написанный мной же с нуля (в итоге назвал его topoSphere).
– Основательно переработанные фильтры.
– Поддержка темного режима.
– Экспорт в PNG/JPEG/JSON.

Обновиться, как и прежде, можно через PIP или из исходников на GitHub. Буду рад обратной связи и багрепортам.

В общем вчера на конфе упомянули новый стандарт "МАРШРУТ ПРОЕКТИРОВАНИЯ И ВЕРИФИКАЦИИ ПРОГРАММИРУЕМЫХ
ЛОГИЧЕСКИХ ИНТЕГРАЛЬНЫХ СХЕМ" от 2024 года. Пока еду в поезде домой решил заглянуть и почитать.

Это &#₽% какой-то, я пока не продвинулся дальше введения, но у меня уже подгорело. (Вложу пдф стандарта в ниже)

Обратите внимание на то, кто сделал этот стандарт ... Там три разных АО, и один из них это бывшие официалы каденса и алдека.

В самом стандарте из разряда - только алдек даст вам благополучие и счастье за небольшую подать в размере покупки одного автоматизированного рабочего места

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

Предлагаю компании макро выпустить стандарт на самые лучшие Плис amd 😁

Ну и второе. Я привел скриншот введения из стандарта. Это ж надо так умудриться в стандарт вставить перевод маркетинговых материалов алдека!!! Мне кажется это финиш

Предлагаю создать Министерство Linux'а.

Минцифры планирует создать собственное Linux-сообщество для разработчиков из стран, готовых сотрудничать с Россией. Такое решение — реакция на отстранение российских разработчиков от мирового IT-сообщества
. . .
Панченко указал, что будет правильно, если новый форк Linux будет сделан сообществом стран, а не отдельной страной. «Это прибавит веса и авторитета. Но чтобы это сообщество заработало, России придется в нем быть лидером и донором программного кода и экспертизы в его разработке. Но есть важное препятствие — в России не так много разработчиков такого уровня, чтобы мы могли полностью взять на себя ответственность за ядро операционной системы. Поэтому важно срочно растить свои кадры», — рассуждает Панченко.
. . .
Идея Минцифры создать собственное Linux-сообщество выглядит слишком амбициозно, считает член совета директоров российского разработчика НТЦ ИТ РОСА и компании «Рутек» Сергей Кравцов. «Не стоит ожидать, что в официальной ветке Linux будут приняты изменения от российского сообщества. Основные решения относительно развития ядра Linux, по сути, будут оставаться международным сообществом, даже если Минцифры организует локальную команду разработчиков», — считает он.

Минцифры предложило создать собственное Linux-сообщество
https://www.rbc.ru/technology_and_media/28/10/2024/671e424c9a7947704249be2c

В последний месяц разработчики, использующие Trivy для сканирования контейнеров, столкнулись с серьёзной проблемой: при попытке загрузить базу данных уязвимостей из GitHub Container Registry (ghcr.io) возникает ошибка TOOMANYREQUESTS. Это связано с тем, что GitHub начал ограничивать количество подключений к своему реестру, что негативно сказывается на работе Trivy и создаёт дополнительные трудности для разработчиков.

https://habr.com/ru/companies/flant/news/854318/

В посте зря трагедию рисуют

На самом деле Trivy выкладывает ещё базы в
- https://hub.docker.com/r/aquasec/trivy-db/tags
- https://gallery.ecr.aws/aquasecurity/trivy-db

Это можно увидеть в их Actions

          declare -A registries=(
            ["ghcr.io"]="${lowercase_repo}"
            ["public.ecr.aws"]="${lowercase_repo}"
            ["docker.io"]="${lowercase_repo}"
          )

https://github.com/aquasecurity/trivy-db/blob/main/.github/workflows/cron.yml#L87C1-L92C1

Для того, что бы указать БД не по умолчанию используйте ключ --db-repository.

А ещё вот вам кусочек GitLab pipeline (написанный своими руками 🌝), которым можно перекладывать к себе в registry базу Trivy

variables:
  TRIVY_DB_ARCHIVE_NAME: "db.tar.gz"
  TRIVY_DB_EXTERNAL_TAG: "2"
  TRIVY_DB_EXTERNAL_IMAGE: "ghcr.io/aquasecurity/trivy-db:${TRIVY_DB_EXTERNAL_TAG}"
  TRIVY_DB_ARTIFACT_TYPE: "application/vnd.aquasec.trivy.config.v1+json"
  TRIVY_DB_ARTIFACT_META: "application/vnd.aquasec.trivy.db.layer.v1.tar+gzip"
  TRIVY_DB_INTERNAL_IMAGE: "${CI_REGISTRY}/path/trivy-db:latest"


pull-push-trivy-db:
  image: ${CI_REGISTRY}/tools/oras:latest
  stage: build
  script:
    - docker login --username "${CI_REGISTRY_USER}" --password "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}"
    - /oras pull "${TRIVY_DB_EXTERNAL_IMAGE}"
    - /oras push --artifact-type "${TRIVY_DB_ARTIFACT_TYPE}" "${TRIVY_DB_INTERNAL_IMAGE}" "${TRIVY_DB_ARCHIVE_NAME}:${TRIVY_DB_ARTIFACT_META}"

в дальнейшем тоже используйте ключик --db-repository, который будет указывать на ваш registry.

Если что, то посмотреть как с публикацией и управлением базами работает Trivy можно тут
https://github.com/aquasecurity/trivy-db/blob/main/.github/workflows/cron.yml#L81

А вообще, собирайте базы сами и держите их при себе 🌝

Коллеги, добрый день
Решили поделиться опытом фаззинга dhcp сервера с помощью фаззера nyx-net. Перед нами стояла задача пофаззить dnsmasq, причём функционал, отвечающий за dhcp сервер. Мы решили, что данная цель хорошо подходит для того, чтобы потренироваться фаззингу клиент-серверных приложений с сохранением состояния (Crusher, AFLNet, StateAFL, SGFuzz). Мы давно хотели попробовать запустить [SGFuzz](https://github.com/bajinsheng/SGFuzz), но он к сожалению работает только с tcp протоколами, а dhcp протокол работает на udp. Поэтому сначала мы решили попробовать запустить AFLNet.

Fuzzing dnsmasq with AFLNet
AFLNet - это graybox фаззер, который позволяет тестировать имплементацию протоколов в сетевых серверах или клиентах. AFLNet выступает в качестве клиента, отправляя серверу смутированные пакеты. При этом фаззер учитывает не только покрытие кода тестируемого проекта, но и его состояние. Состояние сервера определяется с помощью кода возврата в ответе от сервера (например, код 200 в HTTP протоколе). При этом в качестве начального корпуса фаззер использует записанные с помощью tcpdump (или другой утилиты для захвата сетевого трафика) пакеты.
Таким образом, AFLNet пытается обеспечить максимальную имитацию реальных условий использования целевой программы. Ведь фаззить сетевое приложение с помощью стандартных подходов зачастую оказывается довольно сложно, так как какую-нибудь отдельную функцию сложно выделить из приложения из-за глобального состояния сервера. Поэтому в некоторых случаях настройка фаззинга сетевого приложения с помощью AFLNet является в разы проще чем стандартными фаззерами (AFL++, LibFuzzer).
Но к сожалению, у AFLNet есть большой недостаток - скорость фаззинга:
- AFLNet передаёт пакеты по сети, что довольно медленно в условиях фаззинга.
- AFLNet использует задержку по времени для инициализации сервера. То есть AFLNet ждёт определённое количество времени для инициализации сервера прежде чем отправить пакет.
- AFLNet использует задержку по времени чтобы дождаться ответа от сервера. То есть фаззер будет просто ждать некоторое время ответа от сервера и если ответа не поступило, то только после истечения этого таймаута фаззер завершит сессию.
Всё это приводит к очень низкой скорости фаззинга (в наших условиях было ~10 запусков в секунду).

Fuzzing dnsmasq with nyx-net
Мы решили посмотреть, какие существуют альтернативы AFLNet, которые позволяют нам решить перечисленные проблемы. Нас заинтересовал инструмент nyx-net. Nyx-Net - это snapshot based graybox фаззер, основанный на фаззере nyx. Использование снепшотов для фаззинга позволяет решить озвученные проблемы:
- nyx-net подменяет общение по сети на работу с shared memory. Этот механизм используется не только для увеличения скорости доставки тесткейса до целевой программы, но и для определения состояния сервера (например, сервер готов к считыванию пакета).
- nyx-net отслеживает вызовы чтения и записи в сетевой сокет. Таким образом, фаззер создаст базовый снепшот (root snapshot) перед вызовом функции для чтения из сокета. В дальнейшем при фаззинге фаззер будет откатываться до этого базового снепшота, чтобы начать новую сессию. Такой метод позволяет избежать задержки по времени при инициализации серевера.
- nyx-net создаёт возрастающие (incremental) снепшоты. То есть после отправки нескольких пакетов фаззер может сделать снепшот и потом откатываться уже до этого состояния, а не до базового снепшота. Таким образом, фаззеру не нужно воспроизводить цепочку пакетов, чтобы исследовать, как ведёт себя сервер в открытом состоянии при получении новых пакетов.
Но к сожалению, в nyx-net не было реализовано функции для подмены вызова recvmsg(), которая используется в dnsmasq для чтения сообщения и дополнительной информации из сокета. Поэтому мы написали свой патч, который эмулирует работу этого вызова, и отправили его разработчикам.
Таким образом, у нас получилось увеличить скорость фаззинга dnsmasq с помощью Nyx-Net примерно в 450 раз по сравнению с AFLNet. Поэтому рекомендуем добавить этот фаззер в свой набор инструментов.

Не знаю почему сглючила телега, но если что, то комменты к посту выше пишите под этот.

Материалы воркшопа, который я проводил вместе с @ever_secure, лежат тут
https://github.com/rusdacent/cooking-docker-containers

Ссылка на репу с примером pipeline
https://gitlab.com/safecode1/safecode

Презу прикрепил (она в репозитории на GitHub тоже есть)

Так как уже больше трёх человек спросили в личке откуда я форварднул вчерашний пост про фаззинг и где такими вещами занимаются, то решил рассказать на канале. Мало ли кому ещё интересно будет.

Есть такое движение сторонников РБПО (Разработка Безопасного Программного Обеспечения), в котором несколько направлений. Выражу их список через чаты в телеге 🌝

@sdl_static - чат, посвященный вопросам компиляторики и статического анализа (в первую очередь безопасный компилятор/Svace/Svacer, но не только)

@sdl_dynamic - чат, посвященный вопросам динамического анализа (в первую очередь Crusher/Sydr/Casr/Блесна/Natch, но не только). Собственно, вчерашний форвард сделан из него

@sdl_arch - чат, посвященный вопросам композиционного анализа и SBOM, общим вопросам моделирования и архитектуры

@sydr_fuzz - чат пользователей фаззера Sydr

@ispras_natch - чат системы определения поверхности атаки Natch

@sdl_holywar - чат флудилка на тему безопасной и качественно разработки - то, что не укладывается в темы указанных выше чатов

@SDL_Community_SPb - локальный чат Питерской ветки сообщества

Так же рядом со всей этой движухой проводится открытая конференция ИСП РАН, которая является ежегодной и там регулярно появляются интересные доклады. Например, список докладов за 2023 год можно посмотреть тут https://www.isprasopen.ru/2023/#Agenda

В этом году она тоже будет проходить в декабре, так что кому интересно можно подавать свои доклады и регистрироваться https://www.isprasopen.ru/

Так же напоминаю про "Центр исследований безопасности системного программного обеспечения" https://xn--r1a.website/tech_b0lt_Genona/4755, который идейно очень близок и сильно пересекается по группам интересов.

Вроде, ничего не забыл и покрыл тему, но если что задавайте вопросы в личку или в комментах.