Cosign: подпись образа нужно связать с ожидаемым автором

Проверяя скачанный контейнерный образ через Cosign, заранее задайте, чью подпись вы готовы принять. В keyless-сценарии документация требует проверить и личность подписанта, и OIDC-провайдера.

За личность отвечает --certificate-identity, за провайдера — --certificate-oidc-issuer. Проверяйте оба значения: просто найти подпись у образа недостаточно, если вам нужен артефакт конкретного проекта. Ожидаемые значения берите из доверенного процесса выпуска, а не из самого непроверенного файла.

По умолчанию Cosign также сверяет digest образа с digest в подписанных данных. Это связывает подпись с конкретным содержимым. Успешная проверка подтверждает эти условия, но не подтверждает отсутствие уязвимостей в образе.

sccache и промахи кэша из-за пути к проекту

Два CI-задания собирают один код, но checkout лежит в разных абсолютных каталогах. Для sccache это существенная разница: по умолчанию абсолютные пути должны совпадать, чтобы использовать сохранённый результат компиляции.

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

Это настройка для повторных сборок с разными корнями checkout. Она не делает любую компиляцию кэшируемой: например, у Rust не кэшируются инкрементальные сборки и crates, вызывающие системный линкер. Проверяйте попадания и промахи по статистике sccache.

Найти тяжёлый каталог с gdu и запретить удаление

Если нужно разобраться, что занимает место в проекте, gdu покажет размеры каталогов и файлов. Для первичного осмотра можно сразу отключить удаление и получить текстовый отчёт по текущему каталогу:

gdu -n --no-delete .

Флаг -n выбирает неинтерактивный режим, --no-delete запрещает удаление. В интерактивном интерфейсе без этого ограничения есть клавиши удаления и очистки каталога, поэтому режим осмотра стоит выбрать заранее.

По умолчанию gdu считает занятое место на диске. Видимый размер содержимого файла можно посмотреть отдельно с -a. Эти величины могут различаться. Прежде чем очищать самый большой каталог, проверьте, какие данные в нём лежат.

Версии Rust для сборки и запуска nextest

cargo-nextest — отдельный запускатель тестов Cargo. Перед добавлением в CI проверьте, собираете ли вы сам nextest из исходников или используете готовую утилиту: в README для этих случаев указаны разные требования.

Минимальная версия Rust для сборки nextest — 1.91. Для запуска указан Rust 1.41, но авторы отдельно оговаривают, что столь старые версии не тестируют. Они ожидают совместимость с версиями Rust, выпущенными за последний год. Старый номер в таблице не стоит читать как гарантию для давно замороженного CI-образа.

В репозитории также есть библиотеки runner, metadata и filtering. Если вам нужен именно инструмент запуска тестов, ориентируйтесь на пакет cargo-nextest. Подробный выбор тестов и режимов вынесен в руководство проекта.

jwt-cli для разбора токена в терминале

При отладке авторизации бывает нужно увидеть заголовок и claims JWT: например, проверить, какое значение передаёт тестовый клиент. jwt-cli декодирует их локально, без вставки токена на сторонний сайт.

Утилита принимает токен из стандартного ввода. В примере из README сначала создаётся токен с заведомо учебным секретом, затем сразу разбирается:

jwt encode --secret=fake '{"hello":"world"}' | jwt decode -

Аргумент - означает чтение из stdin. Такой способ подходит и для цепочки команд, которая уже получила тестовый JWT. Не подставляйте рабочие токены и секреты в пример или общий журнал команд.

Декодирование показывает содержимое, но не доказывает подлинность подписи. По прочитанным claims нельзя принимать решение о доступе: проверка подписи и условий доверия должна оставаться в обработчике авторизации.

cargo-audit проверяет версии из Cargo.lock по RustSec

Перед обновлением Rust-проекта cargo-audit помогает найти зависимости с описанными в RustSec уязвимостями. Проверка относится к конкретным версиям из Cargo.lock, поэтому отчёт удобно разбирать вместе с изменением lockfile.

Смотрите, какая версия затронута и какие условия описаны в advisory. Наличие записи в базе ещё не показывает, вызываете ли вы уязвимый API или включили нужную для проблемы feature. Обычная проверка не обновляет зависимости. Экспериментальное автоматическое исправление — отдельный режим, который меняет Cargo.toml.

Запускайте Cargo только в доверенных проектах. Если lockfile отсутствует, cargo-audit может вызвать Cargo для его создания. Для чужого lockfile README предлагает передавать файл явно и работать из каталога вне недоверенного проекта. Утилите нужен Rust 1.74 или новее.

Vegeta задаёт темп HTTP-нагрузки

Для тестового сервиса полезно проверить поведение при заданной частоте запросов. Vegeta позволяет задать темп и длительность отдельно, а результаты передать в генератор отчёта. Небольшой пример для вашего локального HTTP-сервера на порту 8080:

printf 'GET http://127.0.0.1:8080/\n' | vegeta attack -rate=2/s -duration=2s | vegeta report

Здесь генератор планирует два запроса в секунду в течение двух секунд. Отчёт показывает число запросов, задержки, коды ответов и ошибки. Фактический темп может отличаться от заданного.

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

Проверка конфигурации GoReleaser до выпуска

После изменения настроек релиза запустите check у GoReleaser. Команда читает конфигурацию и проверяет её допустимость, без запуска публикации.

В корне Git-проекта с файлом конфигурации:

goreleaser check

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

В репозитории GoReleaser есть ссылки на инструкции для локальной машины и CI. Поведение check также видно в открытом исходнике команды. После правки YAML сначала проверьте настройки, затем отдельно — сборку и доставку артефактов.

bandwhich показывает сетевую активность процессов

Общая скорость соединения не объясняет, какое приложение передаёт данные. bandwhich раскладывает текущую сетевую активность по процессам, соединениям и удалённым адресам. Это помогает проверить, связан ли трафик со сборкой, браузером или отдельным фоновым процессом.

Утилита захватывает пакеты выбранного интерфейса и сопоставляет их с процессами. Для этого она использует /proc в Linux, lsof в macOS и WinAPI в Windows. Имена хостов определяет обратным DNS-запросом, когда это возможно.

Для захвата нужны соответствующие права. README отдельно предупреждает: постоянные capabilities в Linux открывают мониторинг всем пользователям машины, которым доступна утилита. На общей машине учитывайте, кто сможет наблюдать чужой трафик. Проект находится в пассивном сопровождении: критические проблемы исправляют, новые функции сейчас не разрабатывают.

cargo-deny сверяет зависимости с правилами проекта

Сообщения об уязвимостях — только одна причина отклонить зависимость. Если проект разрешает определённые лицензии или источники crates, cargo-deny проверяет соответствие графа зависимостей этим правилам.

Например, лицензия новой транзитивной зависимости может не входить в разрешённый проектом список. Проверка лицензий обнаружит такое расхождение. Другие проверки выявляют запрещённые crates и несколько версий одной crate, ищут известные проблемы по advisory-базе и проверяют источники пакетов.

Это отличается от узкой проверки Cargo.lock по RustSec: здесь вы сначала определяете собственную политику, затем проверяете соответствие ей. Разрешённая лицензия и доверенный источник не означают отсутствия уязвимостей. В README указан минимальный Rust 1.88.0. Авторы отдельно предупреждают: результат cargo-deny не является юридической консультацией.

hey: ограничить число запросов и параллелизм

Если нужно отправить небольшую фиксированную серию запросов к своему HTTP-стенду, у hey для этого есть два отдельных параметра. Один задаёт общий объём, другой — число параллельных исполнителей.

Для локального сервера на порту 8080:

hey -n 12 -c 2 http://127.0.0.1:8080/

Будет отправлено 12 запросов с двумя параллельными workers. В итоговом отчёте можно посмотреть распределение времени ответов и статусы. Общее число запросов не может быть меньше числа workers.

Это сценарий с ограниченным числом запросов, а не расписание с заданным общим темпом, как у Vegeta. У hey есть и ограничитель -q, но он задаёт QPS на каждого worker, а не на весь запуск. Если выбираете режим по длительности -z, значение -n игнорируется.

dist собирает бинарник, установщик и данные о выпуске

Скомпилированный CLI ещё нужно передать пользователям: подготовить архивы под платформы, установщики и описание артефактов. dist, прежде известный как cargo-dist, связывает эти задачи в процесс распространения бинарников.

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

В полном варианте dist генерирует CI-процесс: по тегу определяет приложения для выпуска, готовит план, собирает артефакты и размещает их. Название cargo-dist сохранилось у пакета и в части адресов документации, но сам README называет инструмент dist. Сначала решите, нужен ли вам полный процесс публикации или только повторяемая упаковка.

Baseline в Gitleaks выделяет новые находки

Первый запуск Gitleaks по старому репозиторию может дать длинный список возможных секретов. Если нужно следить за новыми находками, инструмент умеет использовать прежний отчёт как baseline и исключать уже записанные совпадения из следующего отчёта.

Это удобно после первичного разбора: отдельно хранится перечень известных находок, а CI показывает новые. Baseline не исправляет старые утечки и не доказывает, что их безопасно игнорировать. Он только меняет, какие совпадения попадут в отчёт.

У Gitleaks есть разные области сканирования. Режим git читает патчи истории, dir проверяет файлы и каталоги, stdin — входной поток. Для поиска секрета, удалённого из рабочей копии, важен именно просмотр истории.

При выборе инструмента учтите статус проекта: автор объявил Gitleaks функционально завершённым. Новых возможностей не планирует, будущие релизы — только исправления безопасности.

gh-dash: сохранённые подборки PR для каждого репозитория

В gh-dash можно завести разделы с нужными PR и issue, чтобы не собирать поисковый запрос заново. Раздел получает название и фильтр GitHub Search в YAML. Например, в документации есть подборка открытых PR других авторов, обновлённых за последние две недели.

У таких разделов есть привязка к репозиторию. Если запустить дашборд из клона или задать GH_REPO, к фильтру без явного repo: по умолчанию добавится текущий репозиторий. Это удобно для одинаковых подборок в разных проектах, но само по себе не даёт общую очередь по всем репозиториям.

Нужен настроенный GitHub CLI с авторизацией. Начните с одного раздела и сравните выдачу с тем же поиском на GitHub. Пример фильтра есть в документации.

В ролике — демо из репозитория с интерфейсом v4.16.1.

Какие хуки запустятся? Сначала проверьте выборку в prek

Если в проекте уже настроен pre-commit, альтернативный раннер можно оценить на небольшой выборке файлов. Авторы prek заявляют совместимость с существующими конфигурациями и хуками. Сам раннер написан на Rust и управляет окружениями для проверок.

В prek run флаг --dry-run показывает выбранные хуки и файлы перед запуском проверок. Область можно ограничить шаблоном --glob для отслеживаемых файлов или перечислить пути через --files. Так проще заметить, что нужная проверка пропускает файл или захватывает лишнее.

Начните с копии рабочего проекта: изучите выборку, затем запустите проверки и сравните результат с привычным pre-commit. Совместимость стоит проверить на ваших хуках. Отдельный бинарник prek не отменяет зависимости и среды выполнения самих проверок. Способы установки есть в репозитории.

mkcert выдаёт сертификат для localhost. Сервер настраиваете вы

Для локальной разработки mkcert создаёт свой центр сертификации — CA — и выпускает сертификаты для localhost, тестовых доменов и адресов вроде 127.0.0.1. Это позволяет проверять приложение по HTTPS с локальной цепочкой доверия.

Здесь три отдельных действия: создать CA и добавить его в поддерживаемые хранилища доверия, выпустить сертификат с ключом, подключить файлы к веб-серверу. Флаг -install меняет хранилища доверенных корневых сертификатов. Сам mkcert HTTPS на сервере не включает. На другом устройстве доверие к CA нужно настраивать отдельно.

Используйте такой CA только для разработки, не для production и компьютеров конечных пользователей. Не передавайте rootCA-key.pem: этот ключ позволяет выпускать сертификаты, которым доверяет ваша машина, и перехватывать защищённые запросы. Порядок работы и ограничения — в README.

dekit запускает API, когда база сообщит о готовности

В примере dekit задача db ждёт ready.log: "ready to accept connections", а у api указано deps: [db]. dekit запустит зависимость и задержит API до появления этой подстроки в строке вывода базы. Это поиск текста, не регулярное выражение.

Условие ready нужно задать явно. Без него задача считается готовой сразу при старте процесса. Если зависимость — разовая задача job, запуск продолжится после её завершения с кодом 0. По умолчанию autostart выключен. В примере он включён у API, который запускает и свою зависимость.

dekit — преемник mprocs. Для проверки сценария нужен подготовленный проект с базой и API. Условия готовности управляют порядком запуска, а не непрерывной проверкой здоровья. Пример конфигурации и точные условия есть в документации.

git-absorb раскладывает правки после ревью по коммитам

В ветке несколько небольших коммитов, а замечания ревьюера касаются разных частей кода. git-absorb берёт только изменения из индекса Git и пытается подобрать для каждого фрагмента исходный коммит. Для найденных соответствий создаёт коммиты fixup!.

Основа подбора — перестановка патчей: меняется ли результат, если применить их в другом порядке. Это не понимание смысла исправления. По умолчанию поиск идёт по последним десяти коммитам, диапазон можно задать через --base. Фрагменты без подходящего коммита остаются в индексе с предупреждением.

Начните на одноразовой локальной ветке. Добавьте нужные правки в индекс, выполните git absorb и изучите новые коммиты через git log. Обычный запуск только создаёт fixup-коммиты. Их объединение с исходными через autosquash — отдельный этап с переписыванием истории. Механика и ограничения разобраны в README.

Из stdin в SQLite и обратно в JSON с sqlite-utils

Вывод команды можно передать в SQLite, выбрать нужные поля SQL-запросом и отдать результат следующему шагу пайплайна. У sqlite-utils memory база живёт в оперативной памяти. Для такого разового запроса не нужен постоянный файл базы.

В README показан пример для CSV с колонками name и age:

cat dogs.csv | sqlite-utils memory - "select name, age from stdin"

Знак - означает чтение стандартного ввода. Поэтому таблица в запросе называется stdin, а не dogs. По умолчанию результат выводится как JSON, флаг --csv переключает его на CSV.

Для входа поддерживаются CSV, TSV, JSON-объект или список объектов. Если автоопределение не подходит, формат задаётся явно, например stdin:csv. Начните с небольшого экспорта, который помещается в память. Форматы и параметры описаны в документации.

OpenAPI-спецификация как инструмент фронтенд-разработчика: практическое применение и типичные проблемы

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

В статье:
— Как найти исходную OpenAPI-спецификацию через Swagger UI или ReDoc.
— Как генерировать TypeScript-типы и использовать их с RTK Query, React Query и fetch.
— Как генерировать API-клиенты и типизировать BFF-роуты на Node.js с Express.
— Как создавать моковые данные и запускать mock-серверы по спецификации.
— Какие проблемы мешают кодогенерации и как автоматизировать подготовку спецификации с помощью openapi-modifier.

Последний пункт пригодится, если спецификация с ошибками: int вместо integer, лишние XML-ответы, внутренние пути. Автор показывает, как исправлять её на своей стороне своим инструментом openapi-modifier, не дожидаясь бэкенда.

https://habr.com/ru/articles/1105006/