Комментарии 125
Нормально было бы, если бы эти Qiushi Wu и Kangjie Lu вместе с публикацией статьи https://github.com/QiushiWu/qiushiwu.github.io/blob/main/papers/OpenSourceInsecurity.pdf (стоит кстати добавить ссылку в пост — из-за этой статьи весь шум) отослали бы Грегу точный список всех этих коммитов, желательно в виде ещё одного коммита, который всё ревертит. Рожу бы конечно он скривил и в этом случае, но совесть была бы чиста, потому как ему не пришлось бы делать теперь всю эту работу.
А они этого не сделали. За что их университет забанили (ведь они действовали от имени университета, который в данном случае выступил этаким "обезличнным хакером"). Воспользовались его авторитетом (и подорвали его). По сути сообщество идентифицировало и забанило злоумышленника (университет), ищет и отзывает его коммиты, т.е. среагировало в общем-то нормально.
У простого хакера со стороны так не получится сделать — он не сможет слать коммиты с университетского имейла, поэтому на него по-любому сразу будут смотреть с бОльшим подозрением, про что кстати и в почтовой рассылке упоминалось.
У простого хакера со стороны так не получится сделать — он не сможет слать коммиты с университетского имейла, поэтому на него по-любому сразу будут смотреть с бОльшим подозрением
А вот тут вопрос — использовался ли какой либо «доверенный» аккаунт университета, или же просто «вася пупкин из университета».
Если первый — то согласен, они пользовались незаслуженным доверием.
Если же «Вася Пупкин», то стоит помнить что обычно его может получить любой студент университета. Т.е. только поступил — и уже у тебя есть такой емайл, т.е. ни о каком спец доверии говорить не имеет смысла — то что Вася Пупкин поступил в университет не даёт ему особого доверия.
И второй вопрос — что же там были за уязвимости, которые удалось протолкнуть в основной код? Т.е. если исследователи смогли, и их смогли поймать только когда они опубликовали статью об этом, то фактически, получается, что кто угодно с большим желанием сможет протолкнуть такие проблемные изменения в основной код :) Т.е. проблема и в самому процессе ревью комитов.
"Вася Пупкин из университета" считается (лся) доверенным потому, что "из университета".
Если это студент и его поймают за злоупотреблениями от имени университета, он оттуда быстро вылетит, и дело тут вовсе не в опенсорсе — любые злоупотребления от имени университета не будут долго терпеть. Есть предположение, что даже и авторам указанной статьи, которые уже далеко не студенты, не поздоровится, и даже наверняка перепадёт комитету по этике, который дал дорогу проекту. И разумно будет, если всем влетит именно за то, что не сообщили список коммитов/не предложили реверты, а не за то, что занимались исследованиями, хотя это ещё посмотрим.
Авторов поймали не после публикации статьи. Вы переписку-то почитайте в рассылки. Началось всё как раз с того, что кто-то начал ругаться на бессмысленный подозрительный коммит, а тот, кто его запостил (Aditya Pakki), стал отбиваться, мол, "у меня есть право на ошибку" и юлить всячески, изобрёл байку про новый статический анализатор, который он якобы разрабатывает и это, мол, анализатор предложил такой фикс, поймите правильно, он ещё совсем в ранней стадии разработки. Далее нашли и ревертнули ещё несколько его подобных коммитов и несколько похожих штук от других людей, в том числе задели пару невинных. И только через некоторое время Грег раскопал эту статью и уже после этого забанил университет и затеял масштабную проверку.
Кстати, Aditya Pakki как раз, вероятно, студент. Среди авторов статьи его нет, а коммиты от его имени.
Я не говорю, что "всё хорошо". Я говорю, что исследование само по себе херовое, так заниматься исследованиями нельзя. Его нельзя называть "исследованием", это явное вредительство. Не столько для коммьюнити линукс, сколько для репутации университета. В принципе, там же в рассылке учёные уже высказались в этом духе.
«Вася Пупкин из университета» считается (лся) доверенным потому, что «из университета».Для хакера завладеть чужим университетским e-мейлом такая непосильная задача?
Если это студент и его поймают за злоупотреблениями от имени университета, он оттуда быстро вылетит, и дело тут вовсе не в опенсорсе — любые злоупотребления от имени университета не будут долго терпеть.
Кстати, Aditya Pakki как раз, вероятно, студент.
Он аспирант. Там один профессор проводит исследования на тему безопасности и разные его аспиранты эксперементируют и пишут статьи. Видимо, по результатам этих бессмыссленых найденных комитов Aditya собирался написать статью. Но не прокатило.
Теодор Цо заметил, что этот "один профессор" в прошлом сабмитил и нормальные фиксы настоящих багов, но вообще у него, так сказать, особое понимание этики, а в университете, похоже, нет настоящей проверки на этичность и поэтому правильно забанили.
Qiushi Wu и Kangjie Lu
На фоне синофобии, проталкиваемой западными СМИ, с такими фамилиями я бы поостерёгся заниматься намеренным вредительством.
Я думаю, другие исследователи будут с сомнением относиться к коллаборации с этими персонами, а уважаемые журналы будут не очень охотно принимать их статьи к публикации.
Китайцы, под прикрытием имени американского университета, намеренно компрометировали линукс и вкрячивали дыры. Если по простому.
Называя это "исследованиями" — так что еще и на американские деньги, что совсем молодца.
всякие бывают в жизни накладки. Может им славы захотелось, а не безликого "1001й в 100ом ряду слева на церемонии вручения одного на всех ордена в китайском кгб". А может индус подвел и пришлось план Б.
All the bug-introducing patches stayed only in the email exchanges, without being adopted or merged into any Linux branch, which was explicitly confirmed by maintainers. Therefore, the bug-introducing patches in the email did not even become a Git commit in any Linux branch. None of the Linux users would be affected.Эти коммиты даже не пушились никуда. Так что да, шапочка из фольги.
Другая сторона заявляет обратное — что комиты (минимум один) из статьи в мэйнлайне: https://m.habr.com/ru/news/t/553712/#comment_22960362
отослали бы Грегу точный список всех этих коммитов, желательно в виде ещё одного коммита, который всё ревертит. Рожу бы конечно он скривил и в этом случае, но совесть была бы чиста, потому как ему не пришлось бы делать теперь всю эту работу.
Вообще говоря разработчикам нужно проделать теперь всю эту работу в любом случае. Патчи для реверта слать пока не надо, потому что весьма интересно, какой процент лазеек в безопасности разработчики найдут теперь, после того как им уже известно где их искать! Было бы интересно по этим результатам почитать ещё одно исследование.
По сути сообщество идентифицировало и забанило злоумышленника (университет), ищет и отзывает его коммиты, т.е. среагировало в общем-то нормально.
«Университет» это большая организация, причём с запрограммированной текучкой. Бездумно принимать коммиты без проверок, лишь потому что они исходят от «проверенной» организации, довольно легкомысленно. От отдельных проверенных разработчиков, зарекомендовавших себя, ещё куда ни шло.
Но даже если код исходит от проверенных разработчиков, аудит всё равно не помешает.
Очень полезная работа, на месте разработчиков Линукса, я бы поблагодарил.
Вообще говоря разработчикам нужно проделать теперь всю эту работу в любом случае. Патчи для реверта слать не надо, потому что весьма интересно, какой процент лазеек в безопасности разработчики найдут теперь, после того как им уже известно где их искать!
Нет-нет-нет. Надо обязательно. Иначе реальные баги окажутся в боевой системе, например, моей или того парня.
Я имел ввиду, что если бы список они с самого начала отослали, вместе со статьёй, это с натяжкой, но можно было бы назвать этичным. Они хотя бы таким образом не добавили лишней работы и так занятым людям. А сейчас, занимаясь сомнительными исследованиями, они их ещё и поднагрузили.
Это как представьте себе, идут люди, думают о том, куда идут, какой маршрут, какая цель, короче, не дурака валяют, а кто-то ставит им подножки и всячески мешает, а потом пишет об это статью, в которой показывает на всех пальцем, мол, "все эти дурачки под ноги-то не смотрят, куда они дойдут с такой внимательностью, и вообще внимательность у людей никакая, вот, мы исследовали". Ты бы хотя бы у людей спросил, "исследователь", и улицу-то выбрал не такую забитую и людей не таких занятых. И это, хотя бы подняться на ноги помогал тем, кто упал из-за тебя. Раз это ты не делашь — ты самый настоящий хулиган, а не исследователь.
Нет-нет-нет. Надо обязательно. Иначе реальные баги окажутся в боевой системе, например, моей или того парня.
А то их там нет сейчас? Бояться нужно тех лазеек, которые внедряли без уведомления. Такой внеплановый аудит поможет выявить, сколько процентов лазеек они смогут найти, даже зная где искать. Весьма полезное и важное исследование.
Они хотя бы таким образом не добавили лишней работы и так занятым людям.
Важность безопасности Линукса трудно переоценить. Я не считаю работу над безопасностью «лишней». Если разработчики Линукс так считают, это очень плохой знак.
Ты бы хотя бы у людей спросил, «исследователь», и улицу-то выбрал не такую забитую и людей не таких занятых.
Ага, и ещё показал, что и где внедрил. Нет. Программист из АНБ никого спрашивать не будет. А если разработчик ядра «слишком занят» и у него «нет времени» чтобы заниматься проверкой патчей на предмет безопасности, то ему следует снизить темп приёма патчей.
Безопасность ядра слишком важная вещь, чтобы заниматься ею по остаточному принципу.
Ну повторяю, хулиган ты тогда, а не профессор, и отношение к тебе будет как к хулигану. В приличном обществе с тобой иметь дела не станут. Я надеюсь, что именно такое и произойдёт с этим Kangjie Lu.
Этого Aditya Pakki ткнули носом в херовый коммит, и нормальный человек в таких случаях коммит отзывает. А этот не отзывает.
Важно, что эксперимент происходит на самом деле не над линуксом и его безопасностью, а над сообществом, над людьми. Университет это не просёк, за что получил порцию какашек. Линукс тут как таковой выбран в качестве "сцены" эксперимента, и это херовый выбор в случае такой постановки эксперимента.
Список коммитов для реверта предоставить надо обязательно. Пришёл, поэкспериментировал? Молодец, а теперь мусор за собой прибери. Почему это сообщество за тобой его должно вычищать? Ты и так без разрешения только что воспользовался ресурсами этого сообщества.
Видимо, либо у вас тоже несколько всё печально с этикой, как у этого "профессора", либо у меня со способностью объяснять, раз вы не понимаете, в чём собственно тут проблема.
Ещё раз, это не исследование, это хулиганство. Исследованием это станет не ранее, чем исследователи возместят сообществу тот ущерб, который они создали в процессе. Пришёл, нагадил, так и оставил и написал статью об этом — это ненормально.
Хакер солонка? Если вы пойдете в ресторан и насыпете слабительное с сахарницу — это тоже будет полезным исследованием? И проблема у ресторана будет не из-за исследователя? Я вот считаю что некоторые вещи нерентабельно решать техническими методами. Надо применять административные меры. Намеренно нагадил и это доказано — штраф. Повторилось — посадить.
Иначе варвары победят цивилизацию.
А штрафы за закладки АНБ кому выписывать?..
Как по мне, так у людей просто шаблон "открытый код — это безопасно, его же любой может прочитать!" треснул по швам. Потому что прочитать могут, но делать, этого, конечно, не хочется: "у меня времени мало!" Может быть эту проблему решать?
(Линуксом сам пользуюсь, если что)
Вопрос хороший. Думаю тем же кому выписывают штрафы за спецоперации с жервами/санкциями (никому).
Ну так исследование привлекло внимание к тому, насколько легко студент сможет протащить в важный код закладку. Это тебе не в ресторане с людьми солонки раскурочивать, там раньше застукают!
Оно привлекло бы меньше внимания, если бы было выполнено этично, с откатом кривых патчей вместе с публикацией статьи?
UPD: да, пожалуй, поменьше, потому, что никто не говорил бы в инете, мол, фу, какие мудаки.
Нет. Но теперь у тех, кто за это отвечает, будет шанс пересмотреть то, что они принимали не глядя все это время.
Или тут кто-то серьезно думает, что левые коммиты только детишки из университета присылали? Это ведь почти heartbleed наклевывается, а то и не один. Впрочем, а давайте просто попросим приколистов все откатить и забудем, как страшный сон? А то времени ведь мало...
От меня тоже UPD: да, меньше. Не припоминаю особо уязвимостей со времён вышеупомянутого, когда люди бросались перелопачивать коммиты за год. Тогда, правда, вроде никто не жаловался, что времени нет. С другой стороны и ничему не научил тот инцидент.
Список коммитов для реверта предоставить надо обязательно. Пришёл, поэкспериментировал? Молодец, а теперь мусор за собой прибери.
Я не согласен. Это не мусор.
Если разработчики даже после того как узнали, где искать, найдут, скажем, только половину лазеек, то это будет очень важным показателем.
Видимо, либо у вас тоже несколько всё печально с этикой, как у этого «профессора», либо у меня со способностью объяснять, раз вы не понимаете, в чём собственно тут проблема.
По-моему проблема в том что кто-то пытается проблемы с безопасностью замести под ковёр, прикрывшись атаками на того, кто эти проблемы выявил.
Нормальная этическая реакция за нахождение таких зияющих дыр — благодарность. Логично было бы взять Aditya Pakki руководителем в группу занимающуюся безопасностью ядра.
В любой случае, работу он теперь точно найдёт. Но хотелось бы, чтобы он продолжил заниматься ядром, раз у него так хорошо получается.
Я не понимаю, как можно считать нормальным эксперименты над безопасностью, не ставя в известность того, чья это безопасность. А как вам такое: сломать стержни работающего ядерного реактора замысловатым образом, не сказать, какие и как, и потом смотреть, найдут ли и починят ли? Нормально?
Вот сейчас осталось несколько коммитов, возможно, вносящих проблемы с безопасностью. Они попадут, скажем, в очередной релиз ядра и эти проблемы с безопасностью появятся у миллионов пользователей. Причём есть люди, которые точно знают, какие именно патчи и какие именно проблемы. Всё ещё это у вас сомнений в этичности этих людей не вызывает? Я не знаю, что и сказать, очень печально это.
На АНБ не кивайте. То, что там работают люди странноватые, мы и так знаем. Не в этом вопрос. Вопрос в том, что такие же странноватые люди работают в уважаемом университете и что это за университет такой замечательный и чему он может научить хорошему. А вы предлагаете ещё и доверить свою безопасность таким людям. Они так глядишь и кардиостимулятор выключат, для проверки, что будет, мало ли что в голову придёт ещё проверить.
Я не понимаю, как можно считать нормальным эксперименты над безопасностью, не ставя в известность того, чья это безопасность.
А я не знаю, как можно проверить безопасность, ставя в известность тех, кто за безопасность отвечает. Правильный способ проверить, на сколько правильно проводится аудит безопасности — попробовать взломать систему, без предупреждений, в неподходящий момент и в самом ответственном месте, естественно. Что они успешно и сделали.
Отмазки «я устал», «у меня нет времени» — не катят.
Вот сейчас осталось несколько коммитов, возможно, вносящих проблемы с безопасностью. Они попадут, скажем, в очередной релиз ядра и эти проблемы с безопасностью появятся у миллионов пользователей.
И тем важнее проверить, как хорошо разработчики Линукса смогут их выявить. Помимо этого они, возможно, параллельно найдут и другие лазейки. А может быть и нет. Вот и узнаем.
Причём есть люди, которые точно знают, какие именно патчи и какие именно проблемы. Всё ещё это у вас сомнений в этичности этих людей не вызывает?
Если они не будут пользоваться этими лазейками, то в чём неэтичность? Всё не просто этично, а наоборот, образец для подражания.
Да им памятник ставить надо! Объявить благодарность, попросить научить, где и как нужно закрыть лазейки, создать группу для для выработки контрмер, желательно с их участием.
Надо создать специальный фонд и поощрять таких людей специальными денежными призами.
А я не знаю, как можно проверить безопасность, ставя в известность тех, кто за безопасность отвечает.
Обязательно кто-то из руководителей организации жертвы должен быть в курсе и одобрять такое дело. Понятно, что нельзя в запросе писать "мы тут вас на вшивость проверяем, но вы не обращайте внимания. Как вам патч?". Но получить разрешение на такие эксперименты от Линуса или еще кого-то стоило бы.
Во-первых, это фундаментальный вопрос согласия. Взлом — вещь противозаконная. И только согласие жертвы отделяет пен-тест от преступления.
Во-вторых, Иначе можно просто пытаться что-то ломать и, если не прокатит, утверждать, что это был просто ресерч и пен-тест. А если прокатит — собирать профит.
Обязательно кто-то из руководителей организации жертвы должен быть в курсе и одобрять такое дело. Понятно, что нельзя в запросе писать «мы тут вас на вшивость проверяем, но вы не обращайте внимания. Как вам патч?». Но получить разрешение на такие эксперименты от Линуса или еще кого-то стоило бы.
Это нарушило бы чистоту проверки. Линус мог бы возразить против проверки и предупредить всех или какую-то группу.
Взлом — вещь противозаконная. И только согласие жертвы отделяет пен-тест от преступления.
Законы это уже другая область, там пусть юристы разбираются. С этической стороны — всё ок.
если прокатит — собирать профит.
Они же так не поступили.
Линус мог бы возразить против проверки и предупредить всех или какую-то группу.
Ваш аргумент звучит как: "не надо спрашивать разрешение, а то вдруг откажут".
Если бы Линус возразил, то пришлось бы искать другое сообщество для экспериментов.
С этической стороны — всё ок.
Это спорный вопрос. Сами разработчики, которые решили забанить весь университет — другого мнения. И вообще, эксперименты над людьми без их информированного согласия любой комитет по этике в университете сразу бы зарезал. Это конкретное исследование прошло проверку, только потому что комитет даже не стал рассматривать с аргументацией вида "Да этика к этим компьютерам не относится вообще. Никаких людей, одни биты и байты, черт с ними". Теперь будут внимательнее смотреть.
Они же так не поступили.
Это аргумент, почему так сделано в принципе. То, что в конкретном случае этим не воспользовались не отвергает эту возможность.
Ваш аргумент звучит как: «не надо спрашивать разрешение, а то вдруг откажут».
Именно!
Если бы Линус возразил, то пришлось бы искать другое сообщество для экспериментов.
Вовсе нет. Их работа очень полезна и согласия Линуса или ещё кого-либо для этого не только не требуется, но и нарушило бы чистоту эксперимента.
Единственное, что нельзя делать — публиковать сами уязвимости, до того как поставлены в известность разработчики ядра. Информацию о наличии уязвимостей — уже сомнительно. А сами уязвимости делать доступными для всех, до того как поставлены в известность разработчики — нельзя конечно, это не этично.
Это аргумент, почему так сделано в принципе.
Аргумент подразумевает наличие «взлома». Но само его наличие спорно, пока не опубликована сама уязвимость.
То есть посылать вредоносные патчи для проверки безопасности — можно и нужно. Попытка запретить и тем более преследовать за такие действия, приведёт к падению уровня аудита и уровня безопасности ядра.
Сообщить о существовании такого патча, но не сообщать, где именно находится закладка — можно (но конечно исключительно в соответствующем «security» списке рассылки ).
Публиковать уязвимость без того чтобы заранее сообщить в соответствующий список рассылки — нельзя конечно. Это уже очевидный вред и даже преступление.
Было ли последнее сделано?
Именно!
Не надо спрашивать? А давайте я к вам домой приду, поем вашу еду, посплю в вашей кровати? Без спроса, естественно. А то вдруг вы откажете.
Вовсе нет. Их работа очень полезна и согласия Линуса или ещё кого-либо для этого не только требуется, но и нарушило бы чистоту эксперимента.
Во-первых, можно провести тот же эксперимент, но сначала договорится с Линусом, чтобы точно никакой бяки в репозиторий случайно не попало. Чистота эксперимента не нарушена и хотя бы попытка соблюсти этику были бы. Во-вторых, если идеально чистый эксперимент невозможно произвести без нарушения этики экспериментирования над людьми, то, наверно, с этим надо смирится и поискать другой эксперимент? Вот нельзя получить согласие на проверку, как современные мегаполисы рушатся при ядерной бомбардировке. Это, по-вашему, значит, что и не надо спрашивать? Знание-то в результате полезное будет. Где вы проводите границу, почему взрывать ядерное оружие в центре мегаполиса нельзя, а комитить вредоносный код в стабильную ветку ядра можно? И то и другое, в общем-то, уголовное преступление.
То есть посылать вредоносные патчи для проверки безопасности — можно и нужно.
Ну вот аналогия: Чтобы вы лучше защищались от похищения — вас похищают, увозят в неизвестном направлении, но потом отпускают без требования выкупа. Вам это понравится? А ведь отличная проверка безопасности общества получается. Ну, подумаешь — продержали вас в подвале с мешком на голове несколько часов.
Так и тут. Это "тестирование" отнимает время и силы разработчиков, которые никому ничем не обязаны, денег за это не получают.
Какую пользу это исследование принесло? Показало, что ревью не идеален? Еще бы выяснили, что вода — мокрая.
Вот искать баги в репозитории и фиксить их или искать вредоносные коммиты — это другое дело было бы.
Не надо спрашивать? А давайте я к вам домой приду, поем вашу еду, посплю в вашей кровати? Без спроса, естественно. А то вдруг вы откажете.
Если от безопасности моей квартиры непосредственно зависела безопасность большинства (миллиардов) других квартир, то аналогия была бы уместна. И было бы понятно Ваше беспокойство о безопасности моей квартиры. Но такой зависимости нет.
сначала договорится с Линусом, чтобы точно никакой бяки в репозиторий случайно не попало.
Нет, это не годится, по причинам изложенным выше. Кроме того, в репозиторий оно должно было попасть, потому что репозиторий тоже периодически проверятся «тысячей глаз». Это между прочим один из важных аргументов в пользу свободного софта.
наверно, с этим надо смирится и поискать другой эксперимент
нет
Где вы проводите границу, почему взрывать ядерное оружие в центре мегаполиса нельзя, а комитить вредоносный код в стабильную ветку ядра можно?
Очевидная громадная польза и отсутствующий маловероятный вред.
Чтобы вы лучше защищались от похищения — вас похищают, увозят в неизвестном направлении, но потом отпускают без требования выкупа. Вам это понравится? А ведь отличная проверка безопасности общества получается. Ну, подумаешь — продержали вас в подвале с мешком на голове несколько часов.
Смотри объяснение выше, в примере с квартирой. Если моя безопасность напрямую влияет на безопасность миллиардов других людей, то такая проверка может быть вполне уместна.
Так и тут. Это «тестирование» отнимает время и силы разработчиков, которые никому ничем не обязаны, денег за это не получают.
Насчёт «не получают денег», это зря, некоторые разработчики вполне себе сидят на зарплатах. Но это не важно, даже если бы не сидели. Безопасность линукса слишком важна для всего человечества, чтобы заниматься ею спустя рукава. Может быть как раз пора обратить на это внимание и побольше разработчиков занимающихся безопасностью посадить на хорошую зарплату.
Безопасность линукса слишком важна для всего человечества, чтобы заниматься ею спустя рукава.
Ну так пусть и ищут баги и дыры в линуксе, а не отвлекают разработчиков, чтобы написать статью.
Ну так пусть и ищут баги и дыры в линуксе, а не отвлекают разработчиков, чтобы написать статью.
Так ведь нашли. Это дыра чудовищных размеров — 60% зловредного кода попала в ядро и не была удалена длительное время.
Если кто-то не понимает что это значит, то объясню — скорее всего линукс, к сожалению, кишит такими зловредами.
Ну так пусть и ищут баги и дыры в линуксе
Так вот и нашли: дыру между стулом и клавиатурой. Подтвердили её наличие.
Они же так не поступили.
Профит в виде исследования и статьи о нём они получили.
В том, что в обоих случаях никто специально не вносил в указанное ПО проблемы, а только выявил имеющиеся. Сообщество вокруг линукс тоже не против, чтобы в нём выявили и желательно исправили проблемы в коде.
Я полагаю, проблемы в сообществе разработчиков конечно есть, и не только эта. Но вот работать так с людьми нельзя.
Cписок не огласили. Более того, началось-то всё с того, что их ткнули носом в то, что некий коммит говно, а они вместо нормального признания косяка и отзыва коммита начали извиваться как ужи на сковороде, что мол мы не виноваты, это анализатор кода новый, и т. п.
При этом, создав людям проблемы, они ещё и получили профит в виде исследования и статьи о нём.
С людьми так нельзя. Если уж ты ставил незаметно и без спроса подножки с целью исследования, как люди могут удерживать равновесие — будь добр, нежно лови тех, кто всё-таки не удержал, чтоб не ударились. Ну или лови заслуженные какашки от тех, кто ударился, в том числе, тех, кто может и ударить в ответ.
Cписок не огласили.
А список уязвимостей опубликовали? Если огласили сами уязвимости, то даже если опубликовали патч с исправлениями, это всё равно очень плохо.
А если не опубликовали уязвимости, то и воспользоваться ими никто не может, то есть проблемы нет.
Ну, короче, в отличие от вас они осознали свою неправоту, извинились и пообещали больше так не делать:
https://cse.umn.edu/cs/open-letter-linux-community-april-24-2021
Правильный способ проверить, на сколько правильно проводится аудит безопасности — попробовать взломать систему, без предупреждений, в неподходящий момент и в самом ответственном месте, естественно.
С аудитом безопасности это имеет столько же общего, сколько "телефонный терроризм". Только ещё хуже — телефонщики настоящих бомб не оставляют.
И тем важнее проверить, как хорошо разработчики Линукса смогут их выявить. Помимо этого они, возможно, параллельно найдут и другие лазейки
Это ведь важно проверить как хорошо осуществляется эвакуация школ и больниц. Помимо этого, полицейская собака имеет возможность найти ещё какую-нибудь бомбу — вдруг, кто забыл?
Если они не будут пользоваться этими лазейками, то в чём неэтичность?
В чём неэтичность намеренно вводить уязвимость в продукт, ктторым все пользуются? Хакер и солонка?
Надо создать специальный фонд и поощрять таких людей специальными денежными призами.
Вона, как! Оказывается, мамкиных школьных минёров нужно поощрять!
С аудитом безопасности это имеет столько же общего, сколько «телефонный терроризм». Только ещё хуже — телефонщики настоящих бомб не оставляют.
Если какой-то «телефонный террорист» задался целью и реально помог своим звонком выявить серьёзные системные проблемы с безопасностью людей, то такое сравнение уместно. В таком случае польза от «телефонного террориста» безусловно есть, как и в этом случае.
Это ведь важно проверить как хорошо осуществляется эвакуация школ и больниц.
Если этим занимаются из рук вон плохо, а опасность пожара велика, и эвакуация реально поможет спасти жизни людей, то конечно это важно.
В чём неэтичность намеренно вводить уязвимость в продукт, ктторым все пользуются? Хакер и солонка?
Если бы опасность отравления соли была не надумана, а реальна (отравления случаются регулярно раз в месяц), то такая аналогия была бы уместна. И безопасностью солонок пришлось бы реально заниматься, как занимаются безопасностью ядра.
Если какой-то «телефонный террорист» задался целью и реально помог своим звонком выявить серьёзные системные проблемы с безопасностью людей, то такое сравнение уместно.
Ну, а то, что из-за эвакуации пришлось прервать операции и погибло десяток пациентов — это же сущие мелочи? "Ещё нарожают" — правда?
Если бы опасность отравления соли была не надумана, а реальна (отравления случаются регулярно раз в месяц), то такая аналогия была бы уместна.
Ээээ, вы утверждаете, что уязвимости намеренно вносятся в ядро линукса с регулярностью раз в месяц? И что это не реальные уязвимости, а "надуманые"?!? Кажется, кроме вас и этих малолетних долбоё мамкиных террористов больше никто до такой дури не додумался. У вас другая информация?
А если не опубликовали уязвимости, то и воспользоваться ими никто не может, то есть проблемы нет.
Ээээ? Я не знаю об уязвимости, значит её нет? Риали?
Ну, а то, что из-за эвакуации пришлось прервать операции и погибло десяток пациентов — это же сущие мелочи? «Ещё нарожают» — правда?
Если при пожаре регулярно гибнут сотни, то это тем более не мелочи.
Ээээ, вы утверждаете, что уязвимости намеренно вносятся в ядро линукса с регулярностью раз в месяц?
Я хочу сказать что уязвимости находят регулярно. А уж как они вносятся — хороший вопрос для нового исследования. Сколько из намеренно внесённых находится, мы теперь знаем — около 40%, меньше половины.
Ээээ? Я не знаю об уязвимости, значит её нет? Риали?
Какие-то уязвимости есть всегда и даже известны, но не всякой уязвимостью легко воспользоваться.
Ты не знаешь пароль от моей почты, поэтому ты не можешь её прочитать. Однако остаётся небольшая вероятность что ты можешь угадать пароль. Угадать возможно, но очень трудно и маловероятно. Пароли, ключи, шифрование — вот это всё основано на вероятности. Небольшая вероятность взлома путём угадывания всё равно остаётся, но 100% защиты нет. Некоторые способы шифрования и защиты вообще основаны на недоказанном предположении P!=NP.
В случае с уязвимостью кода единственный способ — регулярно искать уязвимости и закрывать их раньше, чем их найдут злонамеренные люди. Для этого должен быть хорошо поставленный процесс проверки присылаемых патчей и периодического проверки уже существующего кода.
Кроме того, я выяснил что их патчи не несли в себе сознательно внесённых уязвимостей, которые бы было возможно реально эксплуатировать.
Поэтому единственный аргумент который остаётся против них — дополнительная работа для разработчиков.
Если при пожаре регулярно гибнут сотни, то это тем более не мелочи.
Тут я перестал понимать. Если не мелочи, то какая разница сколько гибнет? Это в любом случае дополнительные жертвы. Готовы ли вы пожертвовать жизнью своего ребёнка, которого малолетние долбоё мамкины террористы-"исследователи" для развлечения отключат от аппарата жизнеобеспечения во время операции? Ведь эта эвакуация на потеху дебилам якобы спасёт миллионы (с чего бы это?)
Я хочу сказать что уязвимости находят регулярно.
А это-то здесь причём? Как из того, что уязвимости находят регулярно следует необходимость их сознательного внедрения? В моей вселенной всё ровно наоборот. Впрочем, вы программер? Попробуйте регулярно повнедрять баги в вашу разработку.
Какие-то уязвимости есть всегда и даже известны, но не всякой уязвимостью легко воспользоваться.
и поэтому их надо внедрять ещё больше?!?
Кроме того, я выяснил что их патчи не несли в себе сознательно внесённых уязвимостей, которые бы было возможно реально эксплуатировать.
Уязвимость либо есть, либо нет. Если она есть, то ею можно воспользоваться, если нельзя, то это не уязвимость. Не? Кроме того, даже если сейчас нельзя ею воспользоваться, это не значит, что способ не придумают позже. Тот же пример Spectre это показывает — поначалу все эти манипуляции со спекулятивным выполнением казались низкоуровневыми фокусами без возможности реальной эксплуатации, а потом оказалось, что это можно юзать даже на javascript'е.
оэтому единственный аргумент который остаётся против них — дополнительная работа для разработчиков.
Ну, вот вы всё же попробуйте на своей работе поставить этот эксперимент. Он же полезный! Узнаете и другие аргументы :)
Готовы ли вы пожертвовать жизнью своего ребёнка, которого мамкины террористы-"исследователи" для развлечения отключат от аппарата жизнеобеспечения во время операции?
Воу-воу, не надо демагогии. Нельзя сравнивать статистику и отдельных людей. Кто-то может быть согласен и миллиардом пожертвовать, чтобы спасти своего ребёнка — это не значит, что каждое желание следует удовлетворять.
Если не мелочи, то какая разница сколько гибнет?
Количество гибнущих и есть целевая функция, которую мы оптимизируем. Эвакуация, медицина, противопожарная безопасность, это всё про минимизацию этой функции. Вроде бы простые, доступные вещи? Странно что приходится объяснять.
Как из того, что уязвимости находят регулярно следует необходимость их сознательного внедрения?
Для проверки процесса приёма патча, вот ради этой цифры в 60%. Но я это уже говорил. По всей видимости впустую.
Ну, вот вы всё же попробуйте на своей работе поставить этот эксперимент. Он же полезный! Узнаете и другие аргументы
К сожалению, у нас на работе закрытый софт, то есть таких лазеек нет. А так было бы интересно, конечно.
К сожалению, у нас на работе закрытый софт, то есть таких лазеек нет. А так было бы интересно, конечно.
Уверены? А зависимостей в коде никаких конечно же нет? Или есть и вам можно подсунуть уязвимости через зависимости? Или выполнить код на CI в процессе установки зависимостей проекта? Или вы весь код от которого зависите аудируете и просматриваете? И зависимости зависимостей тоже? Или экономите время разработчиков и доверяете?
Уверены? А зависимостей в коде никаких конечно же нет? Или есть и вам можно подсунуть уязвимости через зависимости? Или выполнить код на CI в процессе установки зависимостей проекта? Или вы весь код от которого зависите аудируете и просматриваете? И зависимости зависимостей тоже? Или экономите время разработчиков и доверяете?
Зависимости есть (то же ядро линукс) и им приходится доверять, именно поэтому аудит патчей меня так интересует.
Но нам эти патчи не присылают.
Нет, все далеко не так просто.
Количество гибнущих и есть целевая функция, которую мы оптимизируем.
Есть тривиальная оптимизация: убить всех людей прямо сейчас, как можно скорее — пока они детей не наделали. Общее количество смертей будет сильно меньше. Эти-то все-равно умрут, но еще и потомство смертное оставят. Даже если считать только смерти от травм или болезней в рассвете сил — на большом промежутке времени накопится сильно больше чем сколько там сейчас людей живет в мире.
Но, почему-то за всерьез озвученный такой способ оптимизации можно попасть в психушку.
Потому что есть еще критерий нанесения вреда. И это очень спорный вопрос, насколько причиняемый вред оправдан полученной пользой.
Я, например, считаю, что установленный исследователями факт о 60% не стоит даже лишней минуты потраченного времени разработчиков.
Сама выборка из нескольких патчей статистически бесполезна. Факт о том, что можно пропихнуть на код ревью фигню нисколько не интереснее того, что вода — мокрая.
Есть тривиальная оптимизация: убить всех людей прямо сейчас, как можно скорее — пока они детей не наделали.
:) Забавный трюк, конечно, но я могу переформулировать и для таких зануд:
Количество cпасённых и есть целевая функция, которую мы оптимизируем.
Факт о том, что можно пропихнуть на код ревью фигню нисколько не интереснее того, что вода — мокрая.
Это неправда. Конечно, после того как это проделали, всем вдруг стало очевидно что вода мокрая. А раньше рассказывали что свободный софт безопасней по определению, потому что его каждый может проверить на наличие уязвимостей.
Количество cпасённых и есть целевая функция, которую мы оптимизируем.
Уже усложняется задача, правда? А теперь дайте определение, кто считается "спасенным"? Мы можем долго играть в эту игру, но что бы вы не написали, я всегда найду более или менее вывернутое наизнанку извращенное решение оптимизационной задачи, пока ваша простая целевая функция не превратится в целую статью. Потому что все на самом деле сильно сложнее и слабо формализуемо.
Это неправда. Конечно, после того как это проделали, всем вдруг стало очевидно что вода мокрая.
Может быть вам — да. Но мне и многим другим это было очевидно до этого.
свободный софт безопасней по определению, потому что его каждый может проверить на наличие уязвимостей.
И это не изменилось нисколько. Уязвимости, таки, нашли. Если бы софт был закрытый, и там один из сотрудников шалил, то никто бы об этом так и не узнал.
Уже усложняется задача, правда? А теперь дайте определение, кто считается «спасенным»?
Пока усложнения никакого не вижу. Спасённым, очевидно считается тот, кто не погиб при пожаре. Для чего и проводится эвакуация.
Мы можем долго играть в эту игру, но что бы вы не написали, я всегда найду более или менее вывернутое наизнанку извращенное решение оптимизационной задачи
Попробуйте конечно. Я не понимаю смысл этой игры для Вас, но готов поучаствовать в виде эксперимента.
Я не оспариваю тезис, что зачастую идею можно довести до идиотизма. Действительно это возможно. Но это не значит что не надо заниматься пожарной безопасностью и её проверкой.
Если проверка выявила слабости в защите, то она не может называться бесполезной. А она выявила!
Может быть вам — да. Но мне и многим другим это было очевидно до этого.
Я как минимум не один. Поиск в гугле по фразе «why free software is more secure» выдаёт 3.330.000.000 results
Если бы софт был закрытый, и там один из сотрудников шалил, то никто бы об этом так и не узнал.
Если софт закрытый, то им не присылают патчи.
Спасённым, очевидно считается тот, кто не погиб при пожаре.
Вводим специальные фермы, где рожают много-много детей, которые сразу же эфтанизируются (чтобы от пожара не погибнуть). Счетчик не погибших от пожара растет с бешенной скоростью. Вы тут можете возразить, что пожара-то не было, на что я вам отвечу, что фермы надо переодически сжигать, естественно, после эфтаназии. Не было бы геноцида детей на этих фермах — они бы сгорели заживо. Ну или более приземленный пример — большинство людей живут в клетках вдали от любых горючих материалов.
Я не оспариваю тезис, что зачастую идею можно довести до идиотизма.
Тут другой тезис. Целевая функция не тривиальна. Нужно не только минимизировать количество погибших в пожаре людей, но при этом обычно нельзя совершать ради этого убийства (однако поджигателя в некоторых случаях можно и застрелить полицейскому), ограничивать свободы людей и много всяких других вариантов вреда.
Если софт закрытый, то им не присылают патчи.
В чем принципиальная разница присылания патча и вношения этого патча сотрудником?
фермы надо переодически сжигать
Пожар это незапланированное мероприятие. Но по сути я ответил ниже.
Тут другой тезис. Целевая функция не тривиальна.
Она конечно нетривиальна при попытке её формализовать для оптимизации с помощью ИИ, но она абсолютно тривиальна для вменяемого человека. И Ваши примеры это ясно показывают. Так как ИИ мы не привлекаем, то не понимаю, как это может помочь в нашей дискуссии.
В чем принципиальная разница присылания патча и вношения этого патча сотрудником?
Очевидно по-моему? Патчи присылает множество абсолютно незнакомых людей (фактически анонимов) с неизвестной мотивацией, сотрудников мало и о них мы знаем почти всё.
Она конечно нетривиальна при попытке её формализовать для оптимизации с помощью ИИ, но она абсолютно тривиальна для вменяемого человека.
И тут вы за этой тривиально понятной и не формализуемой метрикой понимаете только удобное вам в текущий момент. С одной стороны как бы понятно, что убивать людей ради сокращения жертв пожаров — плохо, и тут вы согласны. С другой стороны, когда (начало этой ветки) "телефонный террорист" помимо проверки эффективности эвакуации вызывает смерти ни в чем невиновных людей, это для вас нормально.
сотрудников мало и о них мы знаем почти всё.
Ну, раз уж мы говорили о ядре линукса… что вы знаете о сотрудниках Майкрософт?
С другой стороны, когда (начало этой ветки) «телефонный террорист» помимо проверки эффективности эвакуации вызывает смерти ни в чем невиновных людей, это для вас нормально.
При этом спасает в десятки раз больше людей. Об этом Вы почему-то забыли написать.
Ну, раз уж мы говорили о ядре линукса… что вы знаете о сотрудниках Майкрософт?
В данном случае имеется в виду, что их знают другие сотрудники Майкрософт, руководство — те кто собственно и отвечают за безопасность.
Количество cпасённых и есть целевая функция, которую мы оптимизируем.Тогда давайте просто поджигать все подряд. Даже без особых усилий кто-то да спасется. Чем больше пожаров тем больше спасшихся.
Но это не значит что не надо заниматься пожарной безопасностью и её проверкой.Надо. Но вред от таких «проверок» не должен превышать потенциальный вред от реального пожара.
Вот это в «эксперименте» и не выполняется: вред очевиден, а вот пользы ноль.
Если проверка выявила слабости в защите, то она не может называться бесполезной. А она выявила!Угу. А еще шторы, возможно, гореть могут. Проверьте это в своей комнате. А что, проверка ведь не может называться бесполезной.
Если софт закрытый, то им не присылают патчи...
… с исправлениями найденных ошибок. Очевидно, вы хотели закончить мысль, но сбились.
Но вред от таких «проверок» не должен превышать потенциальный вред от реального пожара.
Вы противоречите условиям задачи. В моём сообщении было так:
при пожаре регулярно гибнут сотни
и
задался целью и реально помог своим звонком выявить серьёзные системные проблемы с безопасностью людей
А еще шторы, возможно, гореть могут.
Это общеизвестный факт. Безопасность свободного софта до недавнего времени — нет. Я уже написал в другой ветке:
Поиск в гугле по фразе «why free software is more secure» выдаёт 3.330.000.000 results
Вы противоречите условиям задачи. В моём сообщении было так:Уменьшили смертность от пожара на 0.1%, зато увеличили от проверок. Отличная логика!
при пожаре регулярно гибнут сотни
Авторы ведь не исправили существующие ошибки, а добавили свои.
Продолжая аналогию с пожаром, разбросали в разных местах огнеопасные материалы, испортили огнетушители и завалили хламом эвакуационные двери. А потом объявили тревогу.
Это общеизвестный факт. Безопасность свободного софта до недавнего времени — нетЕсли это откровение для вас, не надо считать что все остальные тоже считают что пингвин ест радугу и так далее.
Уменьшили смертность от пожара на 0.1%, зато увеличили от проверок. Отличная логика!
По условиям задачи от проверки гибнет около 0.01%, то есть мы спасаем 0.099% процентов.
По условиям задачи ущерб от проверок в сотню раз больше потенциального ущерба от пожара.
Конечно, если бы такое выяснилось, то такую проверку не надо больше проводить. Это же очевидно. поэтому в моём сообщении выше я дополнил, если проверка помогла выявить реальные проблемы и в итоге спасла больше.
То есть ущерб нанесен, а пользы нет.
Да Вы айтишники себя богами возомнили! Спуститесь на землю бренную!
Количество гибнущих и есть целевая функция, которую мы оптимизируем. Эвакуация, медицина, противопожарная безопасность, это всё про минимизацию этой функции.
Увеличение количества погибших — это точно НЕ про минимизацию в любом случае, а при наличии альтернатив, дающих не худший результат — тем более. Странно, что это приходится объяснять.
Как из того, что уязвимости находят регулярно следует необходимость их сознательного внедрения?
Для проверки процесса приёма патча, вот ради этой цифры в 60%.
Внимательно прочтите вопрос. Вы отвечаете на что-то другое. Впрочем, можете обосновать какое количество найденных уязвимостей было внесено сознательно вот этим путём помимо этих мамкиных террористов.
Для проверки процесса приёма патча, вот ради этой цифры в 60%.
Для проверки того, что можно убить несколько людей убьёте несколько людей? Ура, вы выяснили, что человеков можно убить!
К сожалению, у нас на работе закрытый софт, то есть таких лазеек нет. А так было бы интересно, конечно.
Если вы его пишите — какая разница открытый он или закрытый?
Если вы его не пишите, ну заразите сеть вирусом-троянцем.
Нормально было бы, если бы эти Qiushi Wu и Kangjie Lu вместе с публикацией статьи github.com/QiushiWu/qiushiwu.github.io/blob/main/papers/OpenSourceInsecurity.pdf (стоит кстати добавить ссылку в пост — из-за этой статьи весь шум) отослали бы Грегу точный список всех этих коммитов, желательно в виде ещё одного коммита, который всё ревертит. Рожу бы конечно он скривил и в этом случае, но совесть была бы чиста, потому как ему не пришлось бы делать теперь всю эту работу.
Исследователи говорят что их коммиты никуда не пушились.
All the bug-introducing patches stayed only in the email exchanges, without being adopted or merged into any Linux branch, which was explicitly confirmed by maintainers. Therefore, the bug-introducing patches in the email did not even become a Git commit in any Linux branch. None of the Linux users would be affected.
И тащемта опровержений этому утверждению нет. К примеру, этот мужик пишет про коммит от 6 апреля, что он мол сделан с плохими целями и они хотят чтобы статья прошла ревью, однако статья уже была принята на конференцию в декабре 2020 года.
The corresponding paper has been accepted by IEEE S&P 2021.
Т.е. в итоге, ребята сделали статью, никакие коммиты, которые делались в рамках работы со статьёй, никуда не ушли. Через несколько месяцев этот мужик обнаружил статью, прочитал, у него немножко испортилось настроение, и он начал наезжать на ребят по поводу их текущей работы, что мол она как-то связана с тематикой этой статьи. Это может быть и так, да, возможно они продолжают работу; но доказательств у него нет, есть только косвенные улики. Т.е. в текущем виде это обострение паранойи на фоне вскрывшихся фактов трёхмесячной давности.
А они этого не сделали. За что их университет забанили
Их забанили не за это, их забанили за то, что этот мужик посчитал такое поведение неэтичным, и вместо жалобы в этическую комиссию университета решил считать что эта комиссия работает плохо, т.е. кто угодно может заниматься похожими по вреду экспериментами. Вам надо по рассылкам от этого мужика походить, там всё расписано.
Вот, вы и сами нашли то сообщение Jiri Kosina, о котором я сразу подумал. Вопрос теперь, а сколько там вредоносных коммитов от этой группы, которые ещё не обнаружены? Группа говорит, что таких нет, но вот этот коммит, а также упоротая реакция Aditya Pakki на справедливое замечание, что некоторые его коммиты — говно, несколько подрывает доверие ко всей этой группе.
А то, что университет допустил эксперимент над людьми, подрывает доверие к этической комиссии университета (см. сообщение Теодора Цо как раз об этом). К тому же, из сообщения Грега Кроа-Хартмана, где он пишет, мол, "мы жалуемся в ваш университет" (слово AGAIN он написал капсом), намекает, что в коммиссию они обращались, и что-то реакции не было (пока университет не забанили).
А то, что университет допустил эксперимент над людьмиЭто не эксперимент над людьми, а «общественный» аудит процесса обеспечения безопасности ПО, которым пользуются миллионы пользователей.
Данный аудит показал, что процесс — говно.
Это не аудит. Аудит согласовывают с руководством. Это хулиганство и есть попытка извлечь личную пользу в виде статьи, а хулиганы должны быть наказаны.
И, положим, процесс говно (нет) (и покажите только сначала, где процесс "не говно", может, в университете Миннесоты, где эксперимент над людьми допустили без серьёзного анализа), а можно мне теперь линукс без багов и прочего мусора в виде остатков от ваших грязных экспериментов, пожалуйста?
никакие коммиты, которые делались в рамках работы со статьёй, никуда не ушли
Двумя сообщениями ниже (болд мой):
From: Leon Romanovsky
They introduce kernel bugs on purpose. Yesterday, I took a look on 4 accepted patches from Aditya and 3 of them added various severity security "holes".
Accepted != merged and deployed.
Процесс экспримента подразумевал дождаться приёма патча на рассылке, а потом лично мейнтейнеру сказать, чтобы эти патчи никуда не ушли, потому что там намеренно посаженный баг.
В том же обсуждении:
A lot of these have already reached the stable trees. I can send you revert patches for stable by the end of today (if your scripts have not already done it).
Еще раз, была прошлая статья несколько месяцев назад, где исследователи утверждали, что они все откатывают, сами свои же баги исправляют до мерджа.
А теперь еще один студент того же профессора засылал множество мусорных патчей.
“A lot of these” относится не к патчам с багами-бекдорами, а к патчам от группы исследователей в целом. Они не только плохие патчи, а и хорошие отправляли, которые можно и включить.
Грег откатывает патчи скопом по почтовому домену не потому, что они идут от мерзопакостных экспериментаторов и должны быть выжжены напалмом, а больше потому, что сразу нельзя сказать, какие из них нормальные, а какие всё же случайно пролезли и про них забыли — никто из исследователей не вёл исчерпывающего списка (а следовало бы). Так что в дело вступает один из принципов поддержки ядра: сомнительные патчи сначала откатываем, потом разбираемся.
Более того:
Unfortunately they obfuscated the code in their paper for some bizarre reason
and don't provide a proper list, so it's hard to know for sure though. And
there could be more patches elsewhere.
Note that the "Figure 11" patch was actually accepted and is in mainline.
However it's not actually a bug; apparently they didn't realize that.
Если так, тогда приемлемо.
Это просто два пакостника, рожи бы им
А теперь они это откатывают, но не всё. Некоторые патчи считают нормальными, хорошими и не надо их откатывать: https://lkml.org/lkml/2021/4/21/454
В общем, вместе с подрывной дейятельностью там велась и нормальная человеческая работа, и теперь предстоит разобраться, где что. Эти "исследователи" не только добавили работы сообществу, но и дискредитировали университет.
Судя по бурной дискуссии эксперимент удался на славу!
На мой взгляд, выглядит как попытка дискредитировать Open Source.
То что в конечный код пробрался злонамеренный, чужой код, говорит только о том, что разработчики доверяют на слово, а это очевидная глупость, потому что всего лишь надежда на авось.
Почту можно подделать, людей могут подкупить или угрозами заставить выслать злонамеренный код, для последующей вставки, если люди ответственные за разработку так поставили процесс, тогда очевидно, что с безопасностью в linux совсем беда. Если нормальной проверки не было, значит надо проверять вообще всё, от конца до самого начала, потому что таких вставок могло быть сделано уже тысячи, если не десятки тысяч.
Единственное, что странно, это то, что из этого университета не прислали список всех своих злонамеренных включений, а так, идея более чем здравая и правильная. Только такими экспериментами можно убедить разработчика думать в более правильном направлении.
Если такими патчами прицельно «заваливать» мейнтенера, то он, с большой вероятностью, на очередном «сломается» и начнет больше доверять, чем проверять. Имеет ли практический смысл этот простой психологический приём проверять на практике? Не уверен.
Патчи вида «fix a potential missing-check bug», «Check the return value», «replace BUG_ON with error handling code» и «fix incomplete error-handling» могут иметь двойное дно, так как на первый взгляд проверяются легко (да, действительно, не проверили возвращаемое значение, нужно добавить проверку), но в реальности могут оказаться не нужными (например, если возвращаемое значение не важно в текущем контексте или ситуация не может возникнуть в принципе). Результат принятия таких патчей — добавление не нужных проверок и, как результат, снижение производительности (на что, кстати, жалуются уже несколько лет) и увеличения размера кода ядра.
Фактически это вредительство, никакого отношения к улучшению безопасности системы не имеющее. Предполагаю, что такие патчи вносились экспериментаторами с целью повышения своего «рейтинга» (притупления бдительности) и облегчения «продвижения» своих целевых (вредоносных) патчей, но побочный эффект в виде снижения качества кода ядра от этого никуда не исчезает.
И, наконец, патчи вида «Remove redundant check», «remove unnecessary assertion», «replace BUG_ON with recovery code», «Reduce the severity of logging» требуют в первую очередь проверки с точки зрения безопасности. Говоря честно, не все (точнее — не многие) мейнтейнеры являются специалистами, квалификации которых достаточно для проверки таких патчей (исключая тривиальные случаи). С большой вероятностью, именно такие патчи и содержат «целевой» код, который требовалось внедрить.
Думаю, всем очевидно, что основная ценность представленной «научной работы» не столько в доказательстве возможности внедрения вредоносного кода в OpenSource проекты (этим давно занимаются заинтересованные организации и частные лица), сколько в дискредитации выстроенной за много лет системы разработки ядра Linux в частности и OpenSource проектов вообще (так как они часто построены по такому же принципу).
я думаю, проблема как и везде, они не могут затормозиться настолько, чтобы соответсьвовать ожидаемым стандартам
Говоря честно, не все (точнее — не многие) мейнтейнеры являются специалистами, квалификации которых достаточно для проверки таких патчей (исключая тривиальные случаи).
Разве на этом шаге мейнтейнер с недостаточной квалификацией не должен остановиться и не пускать этот патч дальше до тех пор, пока не получит либо "квалификацию", либо понятное ему и проверяемое на его уровне объяснение, либо "добро" от нескольких людей нужной квалификации, а лучше всего пока не выполнены несколько пунктов из предыдущего списка?
Я уже даже за свой крайне малый опыт работы на проекте с куда меньшей сложностью видел, как просто акцепт патчей или недостаточная их проверка приводит к багам, причём как-то раз баги появились на стороне, которая недо-патч и прислала, но окно для приёма нового патча к тому времени для них прошло, и специально для них пришлось срочно пилить патч-релиз.
Linux забанил коммиты Миннесотского университета за эксперименты с намеренными некачественными патчами