Git *

Обнаружение бэкдора в XZ Utils весной 2024 года поразило опенсорс-сообщество и подняло серьёзные вопросы о безопасности цепочки поставок ПО. В этом посте мы изучим, могло ли улучшение практик работы с пакетами Debian помочь в выявлении этой угрозы, приведём руководство по аудиту пакетов и предложим улучшения на будущее.

Бэкдор XZ в версиях 5.6.0/5.6.1 быстро попал во многие крупные дистрибутивы Linux наподобие Debian и Fedora, но, к счастью, не добрался до многих реальных пользователей, потому что благодаря героическому усердию Андреса Фройнда релизы с бэкдором были быстро удалены. Нам крайне повезло, что мы выявили регрессию производительности SSH в полсекунды, уделили время её трассировке, обнаружили зловредный код в загружаемой SSH библиотеке XZ и быстро сообщили о нём различным командам безопасников для принятия быстрых координированных мер защиты.

Этот эпизод заставил разработчиков ПО задаться следующими вопросами:

• Почему ни один из упаковщиков дистрибутивов Linux не заметил ничего странного при импорте новой версии XZ 5.6.0/5.6.1 из апстрима?

• Легко ли проводить аудит современной цепочки поставок в самых популярных дистрибутивах Linux?

• Возможно ли наличие других подобных бэкдоров, которые мы пока не выявили?

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

Стоит отметить, что мы ограничимся только изучением способа импорта ПО дистрибутивом Debian из его апстрима, а также его распространения среди пользователей Debian. При этом мы никак не затронем тему оценки соответствия проекта апстрима best practices по безопасности разработки ПО. В этом посте мы не будем и говорить о том, какие меры следует предпринять на компьютере с Debian, чтобы гарантировать его защиту, потому что таких руководств и так уже много.

Сегодня мы с вами на практике разберем что такое динамические матрицы в Github Actions и как с их помощью экономить время и ресурсы на практике.

Я подготовил монорепозиторий с несколькими микросервисами url-shortener-demo с очень коротким флоу: feature_branch(через PR) →  main. Как понятно из названия это проект позволяющий генерировать короткие ссылки.

Если тебе не нравится Jujutsu - ты не прав.

Как и многие разработчики, я пользуюсь git с начала времён - с тех пор, как его команды были непостижимым набором плохо сочетающихся заклинаний. И таким, по большей части, он остаётся по сей день. Не нужно и говорить, что я просто не понимаю git. Никогда не понимал, хотя прочитал кучу материалов о том, как он всё это внутри представляет. Годами я пользовался им, зная, что делают несколько команд, и каждый раз, когда git входил в какое-то странное состояние из-за того, что я промахнулся по клавише, у меня был мой надёжный алиас fuckgit, который удаляет директорию .git, клонирует репозиторий заново во временную папку, переносит оттуда .git в мою директорию - и так я как-то ухитрялся зарабатывать на жизнь и кормить семью.

За последние несколько лет я всё чаще видел, как люди восторгаются Jujutsu, и всегда хотел попробовать, но мне казалось, что возни слишком много - даже несмотря на то, что я ненавижу git. Я лениво почитал несколько туториалов, пытаясь понять, как это работает, но в итоге решил, что это не для меня.

Однажды я случайно решил попробовать снова, но на этот раз попросил Claude объяснить, как сделать в Jujutsu то, что я хотел сделать в git. И вот тогда в моей голове наконец сложилась ментальная модель jj - и я понял всё. Даже то, как работает git. Никогда бы не подумал, что система контроля версий может приносить радость, но вот я тут. И я решил, что, может быть, смогу написать что-то, что заставит jj «щёлкнуть» и у тебя.

В предыдущей статье рассмотрены основы сборки RPM пакета и автоматизации процесса.

Данная публикация завершает цикл. Продемонстрировав практическую реализацию готового решения, включая:

Разработку Web сервиса.

Регистрацию сервиса в качестве системной службы с автозагрузкой (systemd) при установке пакета.

Внедрение централизованного логирования через journald.

В результате создана полнофункциональная заготовка для быстрого развертывания сервисов с последующей публикацией их в RPM пакет.

runo — ассистент для репозиториев, который позволяет забыть о проблемах с настройкой локальной среды разработки и переключаться между репозиториями быстро и безболезненно. Больше не надо запоминать что, где и как можно/нужно запускать и что перед этим требуется сделать — обо всём позаботится ассистент.

При работе с поддержкой GitLab, будь то установка из Omnibus пакета или Docker-контейнер, иногда приходится запускать руки в консоль gitlab-rails. Причин тому может быть много в зависимости от версии GitLab и задач, стоящих перед вами, например, чистка артефактов, исправление ошибок блокирующих обновление, или массовые операции с проектами/пользователями/токенами и так далее.

Некоторые такие задачи может потребоваться запускать регулярно, и как раз на примере одной из них мы и попробуем написать Cron-задание для Sidekiq.

Вы много своих приложений упаковывали, как RPM пакет? Мне, до недавних пор, не доводилось. Тенденция импортозамещения и перехода на OC Linux потребовала освоить и это умение. Ничего сложного, но, как и везде, есть нюансы, детали и особенности.

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

Статья - достаточно подробная инструкция, как решить эту задачу и автоматизировать ее с помощью GitLab CI/CD.

Да, это очередная статья по чистому коду. Но по разным источникам, соотношение времени, затрачиваемого на чтение и написание кода, может достигать 7 к 1 и даже больше. Когда вы исправляете ошибку, добавляете новую функциональность или проводите рефакторинг, вы сначала погружаетесь в логику, написанную другими людьми (или вами же, но несколько месяцев назад). Именно поэтому читаемость кода становится более важным фактором, чем скорость его первоначального написания. Нечитаемый код — это технический долг, который замедляет всю команду и увеличивает стоимость разработки в долгосрочной перспективе.

Представь мир, где каждый сервер, приложение и сетевая конфигурация тщательно оркестрируются через Git, где обновления, аудиты и восстановления происходят с помощью одного коммита. Эти и другие возможности открывает GitOps. Особенно мощно он проявляет себя в сочетании с универсальностью Linux-систем. Как же преобразить управление инфраструктурой Linux? И каким образом с помощью Git добиться ясности, контроля и уверенности в каждом изменении?

Представьте, что вы DevOps-инженер и разработчик просит развернуть новое приложение в Kubernetes. В большинстве случаев в нем будут секреты: логин или пароль от базы данных, ключи для S3-бакета и так далее. Эти секреты желательно спрятать.

Есть несколько способов это сделать. Мы в команде используем HashiCorp Vault. Храним там секреты в формате key-value, откуда они попадают в приложения, развернутые в ArgoCD с помощью ArgoCD Vault Plugin или аналогичных решений. Звучит не очень сложно, но кое-что в такой схеме нам не нравилось: ручное добавление или изменение существующих секретов в Vault, а также необходимость периодически создавать руками новые key-value secrets engine. Еще стоит упомянуть, что Vault используется не только DevOps-инженерами, но и разработчиками, например в их Jenkins-джобах, а у разработчиков нет доступа на запись в Vault, поэтому любой запрос на добавление/изменение секретов с их стороны выполнялся в рамках заведенного на DevOps-инженера Jira-тикета. Тикеты не всегда вовремя замечались в бэклоге, поэтому такая простая задачка, как добавление секретов, могла растянуться на пару дней.

Поэтому процесс взаимодействия с Vault мы в YADRO решили автоматизировать. В статье я расскажу, как можно управлять Vault через подход IaC (Infrastructure as a Code) с использованием OpenTofu — open source-форка Terraform.

Есть такой род статей на Хабре — читаешь ее и думаешь — вот как она была написана? Материал большой, длинный, много кода, и он в процессе повествования эволюционирует, улучшается. Автор показывает результаты выполнения, прогоны, бенчмарки. У статьи есть сюжет, драматургия, насколько это возможно для технической статьи — баги, тупики, отчаяние, метания и неожиданные озарения.

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

краткое описание пути С++ от прямого вызова компилятора в 90х до создания проекта по шаблону в одну команду сегодня

Привет! Меня зовут Дима Иванов, я руковожу SourceCraft — это платформа для разработки, которая поддерживает полный цикл работы с кодом.

За последние два года ИИ‑революция изменила инструменты разработки и сделала кодогенерацию массовой и доступной, меняя наши представления об эффективности. В 2021 году появился GitHub Copilot — первый массовый помощник для написания кода, а сегодня нейросети и специализированные опенсорс‑решения помогают разработчикам на многих этапах создания ПО.

Совместно с коллегами из Университета ИТМО мы захотели больше узнать, как такая ситуация влияет на работу российских специалистов. Мы провели исследование рынка разработки, чтобы понять, что нейросети меняют в его отечественном сегменте. Выяснили, как ИИ‑инструменты для разработки изменили ежедневную рутину IT‑специалистов, какие кодовые ассистенты приживаются в командах и каким видят будущее профессии программисты и выпускники профильных специальностей.

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

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

С подключением, хабровчане! Меня зовут Роман Волков, я Senior DevOps в МТС Web Services. Последние несколько лет мне приходилось создавать и адаптировать конвейеры на базе GItLab-CI, изменяя процесс автоматизации под каждую новую команду, стек, продукт и окружения эксплуатации. Чтобы облегчить жизнь себе и коллегам, я сделал небольшой внутренний фреймворк — FundaPipe, значительно упрощающий создание, развитие, переиспользование и применение самих конвейеров разработчиками.

Flutter & GitLab CI/CD. Сборка и подписание мобильных приложений

Привет! Меня зовут Данил Абдрафиков, я мобильный разработчик в компании TAGES. Эта статья является продолжением первой части руководства по настройке GitLab CI/CD для Flutter приложений, в котором мы подробно разобрали настройку физической машины и подготовили GitLab Runner для работы. Теперь, когда инфраструктура готова, перейдем к самому интересному – автоматизации сборки и подписания мобильных приложений.

Готовы превратить сборку мобильных приложений из рутинной задачи в полностью автоматизированный процесс? Тогда начинаем!

Привет, Хабр!

Монорепозитории удобны, пока CI не начинает пробегаться по всему дереву. Сегодня рассмотрим, как на GitLab собрать внятный pipeline для монорепы так, чтобы на каждое изменение реагировали только нужные куски. Базовых кирпичиков тут три: rules:changes, условные include и тонкое клонирование репозитория.

Если вы используете код десктопа, курсор или другие инструменты, то знаете: ИИ уже не просто генерирует код — он читает файлы, делает коммиты, отправляет письма. Эта интеграция работает через протокол MCP, который позволяет подключать серверы буквально в пару кликов. Увидели интересный GitHub-сервер, установили — и готово.

Но у MCP есть обратная сторона: каждый сервер требует широкие права. Gmail-сервер просит полный доступ к почте, GitHub-сервер — ко всем репозиториям, файловый сервер — к домашней папке. Microsoft уже фиксирует рост «теневых MCP-серверов», которые сотрудники ставят без ведома IT-отдела. Palo Alto предупреждает: злоумышленники маскируют вредоносные серверы под полезные.

Мы провели собственное исследование MCP, изучили отчёты Microsoft, Invariant Labs, Trail of Bits и протестировали разные атаки. В этой статье — разбор протокола и ключевых рисков безопасности.

Git как краеугольный камень современной разработки программного обеспечения эффективно управляет версиями проектов и особенно хорошо справляется со сложными сценариями совместной работы нескольких разработчиков.

А Claude Code, как передовой инструмент AI-программирования, не только полностью совместим с рабочими процессами Git, но и благодаря глубокой интеграции предоставляет разработчикам беспрецедентную автоматизацию и удобство.

Из этой статьи вы получите следующее:

Своевременное выявление уязвимостей в коде является одной из важнейших задач конвейера CI/CD, ведь чем раньше мы обнаружим ошибку в коде, тем дешевле нам обойдется ее исправление. Для решения этой задачи существует множество различных решений. Но если мы используем конвейер CI/CD то нам необходимо интегрировать наш анализатор в этот процесс. Однако, в GitLab имеется своя функциональность для анализа исходного кода. В этой статье мы настроим GitLab SAST для автоматического анализа исходного кода на наличие уязвимостей.