Comments 42
Меня всегда радовали заявления программистов на GO - на гитхабе для любого кейса найдется модуль а так же JSеры тащущие в проект пакеты для тривиальных операций - вроде odd и even.
В раст своя помоечка с библиотеками назревает.
Вообще инциденты за последние 2 года недвусмысленно намекают, что пора делать репозитории с валидацией библиотек.
На любую валидацию найдётся свой отбитый меинтейнер node-ipc.
Разве что поднимать репо локально и самому проверять каждую библиотеку перед добавлением\обновлением.
Ну так я и говорю про ПОВЕРСИОННУЮ валидацию. Чтобы в случае если майнтейнеру какой либо библиотеки отбило мозги(или как вариант силой заставили) - это не просочилось в хранилище отвалидированных артифактов.
Я пару раз ловил себя на мысли, когда у меня мавен собирал приложение со спрингом, что у меня волосы дыбом на голове встают от количестве пакетов с кодом, которые он тянет со сторонней помойки.
Да да, сейчас придут адепты NPM и будут доказывать, что в 2021 это прям Ъ и только так и нужно, но...
И что в нпм и что в мавене одна и таже беда. Вернее в нас пользователях. Когда кучу внешних порой больших библиотек тащат для тривиальных операций.(строки массивы и тд.)
Знаешь, я осознал всю глубину и масштабность этой проблемы после новости с пакетом в NPM, где чел добавил код, печатающий что-то на тему СВО, в либу, которая используется не в одной тысяче проектов. Причем ЕМНИП там проекты были не уровня наколеночных поделок, а глобальные.
Я тогда ужаснулся, если честно: все эти разработки используют по сути непроверенный код из помойки, где любой дурак может запихать туда что угодно.
Но, судя по поведению людей вокруг и комментариям на форумах — «это норма», «щас так принято, облака-бла-бла» и так далее.
Я ее осознал в 2014 когда пришлось плотно поработать с нодой, и орать с кода многих npm пакетов. А еще с кода коллег которые для прохода по массиву, перебору полей объекта, работы со строками, проверки четности/нечетности пользовали не то что УЖЕ есть в ноде, а россыпь внешних библиотек. И такой же ад творился в опубликованных npm, когда уже тогда очень много пакетов тянули за собой спагетти из не всегда нужных пакетов ради пары тройки тривиальных функций.
У меня всегда было понимание, что универсальная библиотека для разных нужд должна быть более менее компактная и с минимумом зависимостей.
Тогда это правда было все не такое распухшее, и мы таки валидировали то, что добавляли в проект. Но понимание что там может лежать что угодно, видя КТО и КАК это пишет - было уже тогда.
Казалось бы что Мавен с фиксацией всего навсегда давно придуман и используется. Зачем делать что-то новое?
Популярная массово используемая библиотека + хотя бы пара месяцев с момента релиза дают достаточную для любого разумного использования гарантию что там сознательно треш какой-то не внесен. Для срочных фиксов безопасности хотя бы наискосок дифф просмотреть придется. Он обычно небольшой.
Вероятность что такое кто-то найдёт и поднимет шум в популярном пакете за пару месяцев стремится к 100%. Вероятность rce допущенного по глупости выше.
Вы сильно недооцениваете человеческое любопытство и количество глаз. На практике оно прям совсем невероятно. Вы же берете на себя риск бага в библиотеке? Вот и этот возьмете. Он точно меньше.
надеются друг на друга
О, это классика :) «Вот я нашел косяк... Но чет лень, его и без меня пофиксят, пофиг!» Причем не только в программировании.
Экстраполируйте количество таких уязвимостей на количество массово используемого кода. В общем выходит довольно надежно. Я бы сказал что надежнее чем средний энтерпрайз код и средняя инфраструктура.
В мире нет ничего абсолютного. Есть управление рисками. Я не могу представить себе проект для которого использование только популярных Мавен библиотек с отставанием 2 месяца несло бы повышение риска появления уязвимостей в проекте. Для чего-то супер критичного отставание можно увеличивать до года. И ставить на них только отревьюенные обновления безопасности. Их довольно мало на таких сроках. Объем работы терпимый.
Багов вы я думаю много знаете. В том числе долго необнаруживаемых. А сколько случаев сознательного внедрения делающего что-то не то кода в популярный опенсорс вы знаете? Таких чтобы этот код не был обнаружен хотя бы за месяц. Второй месяц оставим запасом. Я ни одного не знаю, но допускаю что я что-то упустил.
Я чуть выше писал про вероятности и управление рисками.
Вы уже взяли на себя риск наличия критического бага в любой используемой вами библиотеке. Такие баги бывают и известны в природе. В том числе в старых проверенных библиотеках.
Вы так же в дополнение берете на себя риск сознательного вредительства. Случаи которого в дикой природе еще не разу не остались незаметными дольше чем предложенный мной карантинный период.
Почему вы второй риск считаете выше первого я так и не понял. Какие способы вы предлагаете для его минимизации я тоже не понял. Система оценки рисков без каких-то хотя бы относительно достоверных исходных данных и действий по уменьшению этих рисков исходя из этих данных не работает.
Почему вы опять говорите про гарантии? Вы уже доказали весь свой код?
Почему вы говорите про какое-то везение? Есть обычное управление рисками. Никакого везения не существует. Почему вы отказываетесь использовать стандартную и работающую практику?
Почему вы опять рассматриваете гипотетическую и никогда не встречавшуюся ситуацию как реальную? Почему вероятность этой ситуации вы принимаете выше эпсилон?
Я не понимаю.
Судя по описанию, BlueKeep до конца запустит только очень любознательный человек.
В GitHub обнаружили тысячи репозиториев, заражающих специалистов информационной безопасности