Як переконатися, що великий пакет в git repo безпечний?

Я спеціально дивлюся на штурвал Emacs , який має такі властивості:

він має тисячі комітетів
він значною мірою підтримується одним користувачем
у сервісу немає інших профілів (соціальних медіа тощо), які мені вдалося знайти за декілька пошуків
вона активно підтримується (сьогодні)

Оскільки я збираюся встановити довільний код на свій комп’ютер, який потрібно використовувати в моєму текстовому редакторі, я хотів перевірити, чи пройшов цей процес перегляду. Я хотів би сказати "ну це з відкритим кодом", але я дійсно далеко від здатності Elisp перевірити весь код сам. Я хотів би припустити, що інші в спільноті переглянули його, але один, мабуть, помилковий, і два - це поточні комісії. Чи є інші стратегії, які мені не вистачає?

Для запису вектор простий: "відкритий код" не має великого значення, якщо дописувач працює під викинутим обліковим записом або якщо немає процесу перегляду.

— діхлін
джерело

" Перевірити " - велике слово. У звичайному розумінні цього слова, я думаю, що відповідь: "Ти не (не можеш)". Ви можете слідкувати за діяльністю розробки для бібліотеки, ви можете перевіряти цифрові підписи та інше, але я вважаю, що немає нічого впевненого та певного.

— Дрю

Хороше питання. FWIW, код, що постачається з Emacs, переглядається (через список розсилки emacs-diffs), але якщо якийсь учасник додати отвір у захисті, я впевнений, що він зможе це зробити, не помітивши. Звичайно, я був би здивований, якщо в Emacs все-таки не існує безлічі великих дір у безпеці, тому я не впевнений, яка проблема може бути в цьому. Тому я думаю, що для того, щоб отримати більш впевнену відповідь, потрібно зосередитись на конкретних простих загрозах (наприклад, слід досить легко перевірити, чи виконує код якийсь не прихований нагляд).

— Стефан

Технічний

— Том

@Stefan, я думав лише про перевірку на місці. З моєї точки зору, їх mapatomsможна було б включити до "небезпечної" групи разом із start-process, evalта funcall. Звичайно, були б помилкові позитиви, але якщо пакет не використовує жодної з цих функцій, він може бути визначений як нешкідливий з великою визначеністю.

— або-або

Вам потрібно додати новий make-process, а також call-process, dbus-<foo>, make-network-stream, а потім vc-do-command, vc-git-command.... А якщо поставити evalі funcallв «небезпечній» категорії, то більшість / всі пакети небезпечні.

— Стефан

Коротка відповідь - якщо ви самі не читаєте код, ви багато довіряєте. Сказавши, що довіряти проекту, отриманому з SCM вище, є трохи безпечнішим, ніж той, який витягнули, наприклад, з Emacs Wiki . Однак ви принципово довіряєте автору пакету, щоб не заподіювати зло та не зловживати можливістю запускати довільний код під час сесії Emacs.

Деякі речі можуть зробити вас безпечнішими:

Дотримуйтесь популярних пакетів

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

Подивіться на кодові показники

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

Віддайте перевагу GNU ELPA та MELPA Stable в сховищах, які відстежують HEADs (MELPA) або дозволяють подати незавершені подання (Marmalade)

Життя на межі кровотечі має певну привабливість для тих, хто бажає останніх блискучих особливостей, але це означає, що ви можете першим прийняти останнє зобов’язання у вашому оточенні. Навіть якщо це не зловмисно, ви можете отримати пакет у стані потоку, тоді як "офіційний" випуск, принаймні, мав якийсь короткий огляд. Наприклад, пакети GNU ELPA приймаються лише тими користувачами emacs-devel, які мають права на зобов'язання.

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

— stsquad
джерело

Мармелад - це бідний архів, коли йдеться про "довіру". Це дозволяє кожному завантажувати будь-які пакунки під будь-яким іменем, без нульової перевірки чи огляду. І це не зовсім доглянуто (просто подивіться на кількість відкритих питань).

— місячник

@lunaryorn: хороший момент, я поправлю відповідь.

— stsquad

@lunaryorn MELPA має навіть більш відкриті питання, ніж сховище ельмармада, тому я сумніваюся, що це корисний показник.

— wasamasa

@stsquad Єдине, що дає MELPA Stable - це теговані випуски речей, які б у будь-якому випадку закінчилися в MELPA, тому я не бачу, наскільки це безпечніше, ніж використання Marmalade.

— wasamasa

@wasamasa Вибачте, мій коментар був сформульований погано. Число не говорить багато, звичайно, але відкриті питання , які говорять: Існує нульова реакція на нових питаннях , ніяких зауважень, навіть не ярлики або завдань. Мармелад фактично мертвий.

— місячник