Опаснее, быстрее, умнее

Атаки на PyPI набирают обороты, Google пытается приучить сообщество к своему стайлгайду, линтер Ruff бьёт рекорды скорости, а генеративные сети продолжают задавать тренды. Всё это вы найдёте в нашем мартовском Python-дайджесте. Поехали!

Ещё одна серия атак на PyPi

Американская компания Phylum специализируется на безопасности цепочек поставок. Их команда исследователей и программистов разработала автоматизированную платформу, постоянно отслеживающую необычные публикации на PyPI. 23 февраля 2023 года эта система зафиксировала аномальную активность. Количество опубликованных пакетов быстро увеличивалось с нескольких десятков до нескольких сотен. Новые пакеты публиковались каждые 4-8 секунд.

Основная опасность каждого из таких пакетов состояла в том, что файл setup.py имел фрагмент, вызывающий команду Powershell. Сама команда была закодирована в Base64, чтобы не привлекать лишнего внимания. В расшифрованном виде эта команда выполняет веб-запрос в Dropbox, где лежит вредоносная нагрузка: дроппер на Rust. Но это лишь «верхушка айсберга» и первый этап заражения. Далее вредонос вызывает второй этап и сброс на диск нескольких бинарников. Каждый из них служит для маскировки под легитимные программы, если судить по названиям.

Одно из названий весьма примечательно — Esquele.exe. Гугл-переводчик переводит esquele, как искажённое слово «скелет» (esqueleto) на испанском языке. Тоже самое определение дают и генеративные нейросети — ChatGPT и NotionAI. Весьма точное наименование для дроппера. (прим. автора)

Детальный анализ механизма атаки позволил найти сходство с той, которую платформа зафиксировала в январе 2023 года. Тогда были опубликованы три библиотеки httpslib, colorslib и libhttps, в установочном коде которых был схожий порядок команд и маскировки, вроде переименования бинарника в WindowsCache.exe. Специалисты Phylum подозревают, что январская атака была лишь разминкой и тестированием эффективности. Так что советуем быть крайне осторожными при использовании PyPI, вероятнее всего атака продолжается и на момент публикации этого дайджеста.

Google Python Style Guide

Хороший код, как и хороший текст, начинается с правил и соглашений. Такой сборник может носить разные названия: coding standard, style guide, code style, programming style и тому подобные. Целью является единообразие, консистентность и отсутствие конфликтов между разными участниками команды. При этом новым разработчикам значительно проще адаптироваться к чтению кода, не упираясь в специфическое оформление. Общие стандарты развивают культуру разработки и улучшают комфорт чтения кода.

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

Авторы документа составили его в виде списка советов. Их можно разделить на две категории: что стоит делать, а чего лучше избегать. Любители Vim останутся довольны, ведь им подготовили файл настроек, помогающий корректно форматировать код. А вот для Emacs прекрасно подойдут и дефолтные настройки. Упоминается также использование инструментов автоматического форматирования Black и Pyink.

Отдельно отметим, что каждая рекомендация имеет чёткое обоснование и отвечает на вопрос «почему так, а не иначе?». Если какой-то совет может быть неоднозначным, то приводятся как плюсы, так и минусы решения. Большое внимание уделяется правильному комментированию кода, но при этом авторы советуют не пытаться описывать его. Что логично — люди, читающие ваш код, вполне могут разбираться в Python лучше вас. Здесь много советов из серии «Капитан Очевидность», но это всё равно полезно, ведь никто не может идеально знать все детали и нюансы.

Такой стайлгайд — отличная возможность ознакомиться с концентрированным экстрактом опыта разработчиков Google и выработать своё персональное руководство по стилю.

Экстремально быстрый линтер ruff

Если загуглить, какой из линтеров стоит выбрать, то чаще всего предлагается два самых популярных: Pylint и Flake8. Оба этих инструмента работают отлично, но в больших проектах имеет значение другой фактор — скорость. В этом плане можно привести в пример экосистему вокруг JavaScript, где тулинг должен работать очень быстро. Использование быстрых языков, таких как Go и Rust, в swc, esbuild и Rome позволило получить изначально высокую производительность. А раз такой подход сработал для JS, то вполне подойдёт и для Python.

Ruff — это Proof-of-Concept сразу двух идей:

1. Реализованные на более производительных языках инструменты Python работают быстрее. 
2. Встроенные цепочки инструментов работают эффективнее их разрозненного набора.

Всё это легко подтверждается бенчмарками. В качестве языка был выбран Rust и это действительно сделало линтер на 1-2 порядка быстрее конкурентов. Замеры на кодовой базе CPython показали, что Ruff работает молниеносно:

Доходит до смешного. Sebastián Ramírez (интервью с ним есть на нашем сайте), автор FastAPI, признался, что иногда добавляет преднамеренные ошибки в код. Так можно убедиться, что Ruff запущен и исправно функционирует. Вишенкой на торте может стать то, что несколько дней назад разработчики линтера Pylint начали переходить с Flake8/Autoflake именно на Ruff. Будем следить за его развитием и обязательно расскажем о нём в будущих дайджестах.

Локальный аналог CoPilot

CoPilot обычно критикуют за архитектуру и стоимость. Это сервис, а значит ему нужно постоянное и качественное интернет-соединение. Кроме того, для большинства разработчиков его ценность не соответствует текущей стоимости, особенно, с учётом юридической неопределённости. Кому, например, будут принадлежать авторские права на сгенерированный код? Да и обучение генеративных нейросетей требует огромных датасетов, в которых вполне может обнаружиться чей-то проприетарный фрагмент кода.

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

Но что, если всё-таки хочется получить локального AI-помощника на своей машине? У модели OpenAI Codex, на которой построен CoPilot, есть бесплатный конкурент — CodeGen. Он представляет собой 4 предварительно обученных модели с разным количеством параметров: 350M, 2B, 6B, 16B. Если у вас под рукой компьютер с хорошей видеокартой на 16 Гб видеопамяти, то можно выбрать вариант с 2B. На меньшем количестве VRAM можно попробовать вариант 350M. Совсем недавно о своём опыте использования CodeGen рассказал один из пользователей Хабра.

В обозримом будущем можно обратить внимание на хитрую утилиту FlexGen, позволяющую запускать большие языковые модели на системах с недостаточным количеством видеопамяти. Их дорожная карта указывает, что в будущем разработчики добавят поддержку моделей CodeGen, а также ускорителей ANE (Apple Neural Engine), встроенных в процессоры Apple Silicone.

Митапы