В команде OpenBSD решили переименовать поле в pfsync после ложного отчёта от ИИ об уязвимости в коде

Разработчик Тэо де Раадт (Theo de Raadt) из OpenBSD сообщил ^[1] о переименовании названия поля в заголовке пакета pfsync ^[2] после поступления ложного отчёта об уязвимости, сгенерированного ИИ‑инструментами. Согласно пояснению команды проекта, поле pfcksum[PF_MD5_DIGEST_LENGTH] переименовано в spare[16], так как сторонняя ИИ‑модель полагала, что имя pfcksum свидетельствует о хранении в поле хэша или контрольной суммы содержимого пакета и, так как поле не проверялось, ИИ считал, что в коде в любом случае есть уязвимость.

Де Раадт пояснил ^[3], что на раннем этапе разработки pfsync указанное поле было добавлено для хранения хэша набора правил с целью оптимизации проверки состояния. В конечном счёте от этой идеи отказались, но поле оставили для сохранения обратной совместимости. Оно всегда оставалось заполненным нулями. В коде проекта это поле лишь упоминалось в структуре пакета, но не проверялось и не заполнялось.

В сгенерированном ИИ отчёте утверждалось о наличии уязвимости на основании предположения, что поле вычисляется при отправке пакета, но не проверяется при получении. В отчёте от ИИ детально пояснялся принцип работы и источник проблемы, но на деле — это было галлюцинацией от нейросети, выдуманной лишь на основании использования в коде слов pfcksum и PF_MD5_DIGEST_LENGTH. Причём разработчик, использовавший ИИ для поиска уязвимости в коде OpenBSD, даже не потрудился проверить результат перед отправкой отчёта.

Ранее на Hacker News появился ^[4] документ, объясняющий ^[5] требования к коду с поддержкой ИИ в ядре Linux. Этот документ RST доступен ^[6] в репозитории Linux, принадлежащем руководителю проекта Линусу Торвальдсу на GitHub. Он содержит рекомендации для разработчиков, использующих код с поддержкой ИИ для внесения вклада в ядро ​​Linux.

Так, любой код, созданный с помощью ИИ, должен следовать тем же процессам, что и код, созданный людьми, описанным в файлах development-process.rst, coding-style.rst и submitting-patches.rst. Кроме того, он должен соответствовать существующим требованиям ядра Linux, таким как совместимость с лицензией GPL 2.0, использование соответствующих идентификаторов лицензии SPDX и соответствие всем правилам, изложенным в файле license-rules.rst.