Як використовується ШІ в KeePassXC: деталі від команди розробників

Команда популярного відкритого крос-платформенного менеджера паролів KeePassXC надала детальне пояснення про те, як використовується ШІ у їхньому робочому процесі. Це стало відповіддю на зауваження спільноти після недавнього оновлення політики внесків до проекту. Особливу увагу було приділено аспектам, пов’язаним із ШІ.

Секрети контролю якості коду в KeePassXC

У нещодавно опублікованому блозі з заголовком “Про контроль якості коду KeePassXC”, команда наголошує, що ШІ допомагає розробникам у процесі перевірки та складання, але код, згенерований ШІ, не інтегрується до кодової бази KeePassXC. Додаток повністю написаний людьми та продовжує дотримуватися суворих стандартів безпеки.

Як проходить процес внесення змін?

Внесення змін контролюють п’ять утримувачів, з яких двоє є основними. Кожне внесення — будь то від новачка чи давнього учасника — подається через GitHub, проходить через безперервну інтеграцію та перевіряється рядок за рядком.

Об’єднання змін блокується, поки не отримає схвалення хоча б одного утримувача. Якщо зміни вніс один з утримувачів, їх повинен перевірити інший. Команда зазначає, що ШІ використовується в двох контрольованих способах:

• ШІ використовується як додатковий рецензент, підсумовуючи зміни в коді та виявляючи потенційні проблеми. Ці пропозиції лише доповнюють існуючі перевірки.
• Для складання простих запитів на внесення змін, такі інструменти, як GitHub Copilot, можуть пропонувати шаблонний код або прості виправлення. Утримувачі уточнюють ці проекти після додаткових комітів і перевіряють їх з тією ж увагою, що й будь-які інші внески.

Прозорість використання ШІ вKeePassXC

Розробники зазначають, що в обох випадках ШІ не замінює людську перевірку. Кожне внесення ретельно перевіряється, тестується та об’єднується в один коміт. Реагуючи на спекуляції про більш широке впровадження ШІ, команда KeePassXC робить свою позицію чіткою: “У KeePassXC немає жодних функцій ШІ, і їх ніколи не буде.”

Команда підкреслює, що проект не буде використовувати ШІ для переписування, рефакторингу або впливу на компоненти, критично важливі для безпеки. Чутливі області, такі як криптографія, залишаються суворо під забороною, і команда відкидає будь-які твердження про “код з настроєм”. ШІ використовується лише в тому випадку, якщо це не може негативно вплинути на безпеку фінального продукту.

Чи може ШІ створити шкідливий код?

Стаття також порушує цікаве питання: чи може ШІ згенерувати шкідливий або ненадійно виглядаючий код? KeePassXC займає більш прагматичну позицію. Утримувачі стверджують, що якість коду визначається його правильністю, а не особою автора.

На їхню думку, дефектний код, скопійований з форуму, не відрізняється від дефектної пропозиції ШІ, але обидва потрапляють під встановлений процес перевірки і тестування. Зрештою, вони наголошують, що вмілий людський саботажник значно небезпечніший, ніж універсальна мовна модель, і недавні атаки на ланцюг постачання підкреслюють цю думку.

Додаткова інформація доступна на офіційному блозі KeePassXC.