Комментарии 169
На что рассчитывает автор? Наивно думать, что все немедленно остановят эту гонку за новыми фичами и просроченными делайнами. Да, есть риск. Но если его попытаться нейтрализовать, проверяя весь открытый софт, то просто ничего не успеешь.
Автор просто задумывается — во что выльется текущая тенденция положения дел. И резонно указывает, что тезис «открытый код = безопасный код» уже несколько не тот, что подразумевалось раньше. И что будет дальше не очень понятно, ведь прогресс не остановишь. Да, притормозить его было бы может и неплохо. Не остановить, а просто снизить темпы. Но мне сложно представить как это сделать в современных рыночных условиях.
Если честно, то запуск на компьютере открытого и закрытого ПО сегодня почти ни чем с точки зрения безопасности не отличается… проверить запускаемый открытый код у большинства пользователей нет ни какой возможности… все проверки в реальности ложатся только на антивирусное ПО, которое, к сожалению, панацеей не является… поэтому ситуация описанная в начале статьи более чем возможна в любой момент с любой открытой программой… да, потом вредоносный код обнаружат, но и в закрытом ПО его потом обнаружат, только не поздно ли?
А вот вывод в конце статьи хорошо бы поддержать, авторам надо платить, тогда они будут поддерживать свое ПО в актуальном и работоспособном состоянии… но ведь многие ищут открытое ПО как раз для того, что бы за него не платить… короче, проблема стара как мир, коммунизм это идеальный строй, если где-то набрать 100% настоящих коммунистов… а ложка дёгтя, как известно, испортит бочку мёда…
А вот вывод в конце статьи хорошо бы поддержать, авторам надо платить, тогда они будут поддерживать свое ПО в актуальном и работоспособном состоянии… но ведь многие ищут открытое ПО как раз для того, что бы за него не платить… короче, проблема стара как мир, коммунизм это идеальный строй, если где-то набрать 100% настоящих коммунистов… а ложка дёгтя, как известно, испортит бочку мёда…
авторам надо платить, тогда они будут поддерживать свое ПО в актуальном и работоспособном состоянии…
Это не работает в масштабе всей экосистемы. Авторам платного софта выгодно поддерживать «особенность» своего софта, чтоб повышать цену перехода (чтоб поменьше народа уходило, проще говоря). См. софт небольшой частной конторы под названием Microsoft.
То есть вот буквально: если всем будут платить за поддержку и актуальность — у всех появится соблазн к окукливанию, прямо пропорционально объему выплат.
Окуклиться не даст лицензия, т.к. систему можно забрать у одного платного мейнтейнера и отдать другому.
Um, нет. У вас не та семантика: систему может кто-нибудь забрать у платного мейнтейнера. Тут нет никакой божественной руки, которая бы забирала у окукливающихся и отдавала бы хорошим.
При этом забрать-то он может, а вот получить он с этого ничего на первое время не получит (а получит только тогда, когда достаточно вырастет в популярности, чтоб быть заметным). При этом у любого нового мейнтейнера при сравнимой популярности с прошлым — соблазн на окукливание будет всё точно такой же.
При этом забрать-то он может, а вот получить он с этого ничего на первое время не получит (а получит только тогда, когда достаточно вырастет в популярности, чтоб быть заметным). При этом у любого нового мейнтейнера при сравнимой популярности с прошлым — соблазн на окукливание будет всё точно такой же.
Если объёмы выплат приличные, то передать проект другому мейнтейнеру сможет тот, кто платит, если его что-то перестало устраивать.
А если речь про случай, когда есть конкретные «заказывающие музыку» — то это и сейчас так работает.
Не всегда. В случае с Microsoft сменить мейнтейнера нельзя.
А в случае с открытым софтом редко платят. И тут высказано мнение, что платить было бы неплохо. Другое дело, непонятно, как кооперироваться заказчикам. Если каждый будет платить своим мейнтейнерам, будет дорого.
А в случае с открытым софтом редко платят. И тут высказано мнение, что платить было бы неплохо. Другое дело, непонятно, как кооперироваться заказчикам. Если каждый будет платить своим мейнтейнерам, будет дорого.
НЛО прилетело и опубликовало эту надпись здесь
В этом проекте есть какая-то специфика?
В общем случае, нужно сделать форк и назначить работника на зарплату, который будет проверять патчи из апстрима и мержить в этот форк, ну и своё что-то дописывать, возможно. Таким образом, для конкретного заказчика, этот работник станет мейнтейнером.
В общем случае, нужно сделать форк и назначить работника на зарплату, который будет проверять патчи из апстрима и мержить в этот форк, ну и своё что-то дописывать, возможно. Таким образом, для конкретного заказчика, этот работник станет мейнтейнером.
НЛО прилетело и опубликовало эту надпись здесь
Даже хуже. FOSS идёт AS IS, тогда как у мелокомягких есть лицензия в которой чёрной по белому (или зелёным по чёрному, зависит от) написаны права и обязанности сторон, причём обязанностей у мелкомягких не мало. А для корпоративных клиентов с поддержкой обязаности значительно вырастают.
Собственно, сейчас в стане свободного софта происходят не очень приятные вещи. Пока он был где-то там, уделом тру гиков всё было хорошо, но… Гик культура стала модной, интерес к свободному ПО возрос катастрофически и саморегулирующее общество поползо в анархию. Этого следовало ожидать, но никто не ожидал.
Очень грустно это наблюдать, просто очень. История с leftpad это лишь вишенка на торте на острие айсберга, проблема настолько глубокая, что исправить что-то будет очень тяжело. Какие-то проекты, конечно, встанут под крыло Microsoft, Google, Mozilla, Canonical, но на всех не хватит и чёрт его знает, что будет дальше. Надеюсь лишь, что интерес к гик культуре поутихнет, схлопнется и все отстанут от опен сорса. Хочу, чтобы снова линуксом пользовались от силы 1% пользователей!
Собственно, сейчас в стане свободного софта происходят не очень приятные вещи. Пока он был где-то там, уделом тру гиков всё было хорошо, но… Гик культура стала модной, интерес к свободному ПО возрос катастрофически и саморегулирующее общество поползо в анархию. Этого следовало ожидать, но никто не ожидал.
Очень грустно это наблюдать, просто очень. История с leftpad это лишь вишенка на торте на острие айсберга, проблема настолько глубокая, что исправить что-то будет очень тяжело. Какие-то проекты, конечно, встанут под крыло Microsoft, Google, Mozilla, Canonical, но на всех не хватит и чёрт его знает, что будет дальше. Надеюсь лишь, что интерес к гик культуре поутихнет, схлопнется и все отстанут от опен сорса. Хочу, чтобы снова линуксом пользовались от силы 1% пользователей!
В случае рэдхат замена мантейнера, условно, миллиард. В случае майкрософта — условно сто миллиардов. Для обычного пользователя и то и другое — невозможная сумма, а значит и разницы нет. Для страны, например, или транснациональной корпорации — это как раз принципиальная разница.
С кибернетисом аналогично. Есть потенциальная возможность заменить, некоторые заказчики могут это потянуть при необходимости.
На практике я сам делал форк десктопного приложения размером проекта в 120.000 строк. За несколько месяцев разобрался. Мержил фичи из основной ветки и успешно добавлял много чего нового своего. Даже какое-то сообщество юзеров появилось с беклогом на 100500 новых хотелок. Потом надоело и я забил.
В некотором смысле, это произошло с OpenOffice=>LibreOffice, WebKit=>Blink, Owncloud=>Nextcloud, MooseFS=>Lizardfs, Oracle ZFS=>OpenZFS и т.д. Более мелкие проекты нередко форкаются, и затем бывает даже форк выживает, а оригинальный проект чахнет, или сосуществуют параллельно.
Да, в случае с линуксами например — можно, и в России и в Китае — делали. Гослинуксы всякие со спецификой.
Или более другой пример — PostgreSQL и Postgresql Professional — товарищи с удовольствием подпишут и договор на сопровождение и доработки будут под вас делать (или объяснять как использовать то что уже есть правильно), и версию с сертификатом ФСТЭК продадут и версию которая умеет 'чуть больше' чем текущая Open- source версия. И они не одни такие.
Или более другой пример — PostgreSQL и Postgresql Professional — товарищи с удовольствием подпишут и договор на сопровождение и доработки будут под вас делать (или объяснять как использовать то что уже есть правильно), и версию с сертификатом ФСТЭК продадут и версию которая умеет 'чуть больше' чем текущая Open- source версия. И они не одни такие.
банально, но программисты хотят кушать… многие из открытых и свободных программ вышли бы на более высокий уровень, если бы делались и поддерживались не в редкие свободные часы, а в нормальное оплачиваемое рабочее время…
А помните Алан Кей делал STEPS? Средой в 20000 строк кода. Операционная система, текстовый редактор, браузер, всё-всё в сумме в 20000 строк кода.
Пусть и невозможно вписаться в столько жёсткие ограничения с реализацией всего желаемого, всё равно кажется, что возможно основательно снизить сложность нашего софта.
Пусть и невозможно вписаться в столько жёсткие ограничения с реализацией всего желаемого, всё равно кажется, что возможно основательно снизить сложность нашего софта.
Один из вариантов — реализовать общий набор библиотек на все случаи жизни и реализовать его на всех языках. Это позволит упростить тестирование, позволит более-менее точно автоматически определять что делает программа, ускорит вникание в программный код. Все программы, которые не пользуются таким набором библиотек, помечать как небезопасные. Наверно, другого пути и нет. Пора отойти от программирования как искусства к программированию как ремесло.
Перенос проблемы с больной головы на здоровую редко решают проблему в корне.
Нельзя не отметить, что нет особой разницы между программой, использующей стандартные либы и программой использующей сторонние библиотеки, использующие стандартные либы. Вы все равно запускаете на машине пользователя код, которому пользователь не может доверять.
Впрочем, стандартизация библиотек идет полным ходом, что обусловленно нормальным эволюционным процессом. Думаю, еще лет двадцать и стандартный набор будет.
Впрочем, стандартизация библиотек идет полным ходом, что обусловленно нормальным эволюционным процессом. Думаю, еще лет двадцать и стандартный набор будет.
Берите выше — давайте напишем общий набор программ на все случаи жизни. Хорошо их отладим, документируем, и программисты больше не будут нужны никогда!
Кто помешает один раз дёрнуть библиотеку для галочки (а то и не дергать, если проверка будет просто по наличию в зависимостях), а дальше использовать что-то своё?
Это только в дополнение к предыдущим комментариям.
А кто мешает запускать автоматическую проверку при каждом изменении? Если это стандартные библиотеки, то проверка быстрая и объективная.
Стандартные библиотеки — это ассемблер высокого уровня. Антивирусные компании давно научились делать выводы о наличии вирусов по коду, даже их наработок десятилетней-двадцатилетней давности может хватить, даже не учитывая нынешнего развития в области ИИ.
Стандартные библиотеки — это ассемблер высокого уровня. Антивирусные компании давно научились делать выводы о наличии вирусов по коду, даже их наработок десятилетней-двадцатилетней давности может хватить, даже не учитывая нынешнего развития в области ИИ.
Проверку на что? На то, что программа использует минимальный набор каких-то библиотек?
Проверку на то, что программа делает только то что заявлено в её профиле.
Мешает отсутствие возможности такой универсальной проверки. Можете погуглить "Проблема останова".
Эта задача уже решена практически. Это эвристический метод поиска вирусов. Начали его использовать лет 20 назад. И препятствие к реализации — именно разнообразие апи и системных вызовов. Если их стандартизировать, проблема упрощается.
Нет, не решена. Поиск вирусов на 95% идёт по сигнатурам. Это абсолютно другое и никак не мешает создать вирус, который не ловится (до следующего обновления сигнатур).
И это хорошо. Поиск по сигнатурам энергетически менее затратный. Нашли вирус по сигнатуре — не надо тратится на более развёрнутый анализ. Кроме сигнатур у антивирусов есть ещё и белые списки заранее проверенных программ, на которые они не тратят свои ресурсы а через анализ проходят только редкие программы сигнатуры которых неизвестны или программы из белого списка у которых не сходится контрольная сумма, просрочена подпись и т.д.
НЛО прилетело и опубликовало эту надпись здесь
Для антивируса — хорошо. Но для проверки, что "программа делает только то что заявлено в её профиле", бесполезно. Вы никак не узнаете, что в программе есть какая-то ещё функциональность. В общем виде я имею ввиду, через универсальный проверяльщик. Банально — представьте, калькулятор, который всё делает правильно, но при умножении 5*5 добавляет единицу. Как это можно выяснить, кроме набора тестов специально для этой программы? Каким должен быть этот универсальный проверяльщик? Разве что ИИ с навыками программиста, тогда появляется шанс.
Оно везде хорошо. Для проверки используется развернутый анализ, который рассчитан на общие случаи и может найти какие-то неизвестные опасные решения но для него существует проблема: ресурсоёмкость. Поэтому сокращают работу за счет сравнения сигнатур которые более топорные и узко заточенные но позволят выявлять ранее определённые проблемы с меньшими затратами ресурса, а если не найдёт ничего — уже может быть применён обычный тяжелый анализ. Особенно спасают «белые списки» для которых заносится заведомо безопасные решения и будучи самыми массовыми на них будет тратится минимум ресурсов, а тяжелая артиллерия пойдёт только на ранее неизвестные решения.
но для него существует проблема: ресурсоёмкость.
Вы это так утверждаете, как будто это вообще возможно. Чуть больше ресурсов и вирусы будут ловиться. Это даже для вирусов неправда, а уж в общем случае, для поиска уязвимостей и "левых" функций в программе — даже в теории невозможно.
Но вы можете попробовать подтвердить ссылками возможность, если хотите, с удовольствием ознакомлюсь.
Нет, как раз в теории доказать что программа выполняет некое деструктивное действие(заранее заданный критерий) можно, но это сопряжено с полным перебором вариантов стремящемся к бесконечности. Существующие алгоритмы просто где-то срезают углы, где-то ещё что-то сокращают но по прежнему эвристика связана с большой нагрузкой. И чем больше доступно ресурсов тем выше вероятность что мы поймаем неизвестного ранее трояна. Но ведь никому не хочется сидеть часами и годами ждать когда эвристика переберёт все возможные варианты с конкретным файлом. Поэтому ограничивают работу эвристического алгоритма какими-то разумными рамками получая некоторую вероятность обнаружения. И по прежнему в этой области всё печально, но ресурсы всеравно тратятся. И если есть способ не использовать эвристику там где можно обойтись более очевидными и надёжными методами(белый список, черный список сигнатур и т.д.) это надо делать. Ведь в ином случае придется тратить ресурсы на работу эвристики там где по сигнатуре можно почти мгновенно сказать что да, это знакомый нам вредонос или деструктивный участок кода.
Вот когда эвристика будет отрабатывать быстрее чем поиск по сигнатурным базам тогда уже можно будет пересматривать методы.
Хуже, кстати, дела обстоят с тем когда вредоносный функционал для своего дела использует вполне легальные инструменты — те же самые системные утилиты. Приложение ничего не отправляет в сеть, но оно может запустить экземпляр браузера, который сделает всё для него. И ведь доступ браузеру в интернет же не запретишь… Или скажете надо будет вести ещё и списки приложений которые может запустить библиотека или о боги использовать OLE, отправить сообщение уже открытому окну браузера… ой методов ещё с миллион найдётся.
Это кстати чем-то похоже на обучение компьютера игре в шахматы. В теории, пока он ничего не знает ему доступен только полный перебор всех вариантов ходов — а это можно делать до конца вселенной.
Вот когда эвристика будет отрабатывать быстрее чем поиск по сигнатурным базам тогда уже можно будет пересматривать методы.
Хуже, кстати, дела обстоят с тем когда вредоносный функционал для своего дела использует вполне легальные инструменты — те же самые системные утилиты. Приложение ничего не отправляет в сеть, но оно может запустить экземпляр браузера, который сделает всё для него. И ведь доступ браузеру в интернет же не запретишь… Или скажете надо будет вести ещё и списки приложений которые может запустить библиотека или о боги использовать OLE, отправить сообщение уже открытому окну браузера… ой методов ещё с миллион найдётся.
Это кстати чем-то похоже на обучение компьютера игре в шахматы. В теории, пока он ничего не знает ему доступен только полный перебор всех вариантов ходов — а это можно делать до конца вселенной.
как раз в теории доказать что программа выполняет некое деструктивное действие(заранее заданный критерий)
Если заранее заданный критерий, например, "уходит в бесконечный цикл", то как раз именно в теории нельзя. Проблема останова. В смысле теорема есть, которая говорит, что это невозможно.
Если вы считаете, что для других критериев это возможно, то следует это доказать. Иначе по умолчанию считаем, что как минимум не для всех. Наверняка найдутся ещё критерии, для которых это невозможно будет сделать.
Эвристики повышает шансы, я с вами согласен. Но изначальный разговор был не о шансах, а о надёжной системе, проверяющей другой код. Если же наша задача просто снизить шансы проблем и уязвимостей, то это возможно, да.
Если заранее заданный критерий, например, «уходит в бесконечный цикл», то как раз именно в теории нельзя. Проблема останова. В смысле теорема есть, которая говорит, что это невозможно.Если строго, то на машине с конечным объёмом памяти эта задача для математики тривиальна (т.к. рассматриваем конечный автомат). Нерешаемой проблемы останова нет, если рассматривать алгоритм и конкретный компьютер, например, с оговоркой «не более 2TB RAM».
Вы можете дать более строгое доказательство? Я, конечно, могу просто проверить вам на слово, но не хотелось бы.
Пока опираюсь на имеющееся доказательство.
Совершенно не очевидно, что если у нас алгоритм с конечной памятью, то возможен анализатор с конечной памятью. Конечный автомат тут не помощник — бесконечный цикл не обязан жрать много памяти.
Проблема остановки неразрешима для машины Тьюринга — т.е. машины с бесконечной памятью.
Для машины с конечной памяитью можно (теоретически) выписать все возможные состояния памяти и разрешённые переходы между ними. Получаем ориентированный граф, в котором легко можно обнаружить тупики (остановку) или циклы (зависания).
Поскольку проблема остановки сформулирована так, что при вычислениях машина работает с известным входом (новые данные не поступают), мы знаем начальное состояние и граф переходов. Граф конечный, переходы детерминированы. Значит, за конечное число шагов либо придём к останову, либо зайдем в цикл, который будет из-за своей детерминированности повторяться вечно.
Для машины с конечной памяитью можно (теоретически) выписать все возможные состояния памяти и разрешённые переходы между ними. Получаем ориентированный граф, в котором легко можно обнаружить тупики (остановку) или циклы (зависания).
Поскольку проблема остановки сформулирована так, что при вычислениях машина работает с известным входом (новые данные не поступают), мы знаем начальное состояние и граф переходов. Граф конечный, переходы детерминированы. Значит, за конечное число шагов либо придём к останову, либо зайдем в цикл, который будет из-за своей детерминированности повторяться вечно.
Хорошо, а как узнать-то, дойдем ли мы за конечное число шагов до цикла или до конца? Если для прохождения этих шагов потребуется потребуется время вселенной? Может с математической точки зрения оно конечно, но практическая реализация невозможна.
Кстати, я придумал пример. Ханойская башня. Как узнать, не зациклится ли алгоритм? Ну то есть очевидно, что нет, но как мог бы выглядеть универсальный алгоритм, который это определит?
Может с математической точки зрения оно конечно, но практическая реализация невозможна.Тем не менее, для математики это не есть неразрешимая задача, если вопрос только в ресурсах.
Кстати, я придумал пример. Ханойская башня. Как узнать, не зациклится ли алгоритм?Если рассматривать машину с конечной памятью, у нас будет 3 массива конечного размера (для 3 столбиков) + массив вспомогательных данных (все переменные программы, текущая выполняемая строка, стек конечного размера и т.п.).
Нужно выполнять алгоритм, запоминая перед каждым шагом содержимое всех массивов. Либо алгоритм завершится, когда перекладывание будет завершено, либо он придёт в состояние, которое мы уже ранее фиксировали, значит зациклился. Т.к. кол-во возможных конфигураций чисел в массивах конечно (числа тоже ограниченной длины, например, int), то и не получится генерировать бесконечную последовательность новых конфигураций.
Я, честно говоря, не подразумевал математику, когда имел ввиду "в теории". Я подразумевал теоретический алгоритм, способный выполниться на существующих компьютерах (до того, как они рассыпятся в прах)
В таком раскладе с вами соглашусь. Наличие бесконечного времени решает проблему, потому что перебор состояний действительно конечен.
За описание способа спасибо.
Проверку на то, что программа делает только то что заявлено в её профиле.А как сделать проверку, что программа правильно делает то, что заявлено? Достаточно удалить одну строчку, которая обрабатывает какой-нибудь граничный случай, и в программе появляется уязвимость. И никакая эвристика ничего не найдёт, если только не была запрограммирована специально на эту ситуацию. То есть, анализатор должен знать предметную область.
Что может быть? Отправка сетевых запросов, чтение с диска — такого плана заявления?
Ну да. Правда, Вы перечислили только низкоуровневые операции, я же писал о высокоуровневых. Доступ к реестру, выполнение HTTP запросов, системные вызовы, запуск вычислительных подзадач. Например, типовому приложению доступ к сети вообще не нужен, нужен доступ к конкретной базе данных или внешним сервисам типа фейсбука. Если есть любой вызов сетевой библиотеки — значит приложение взломано.
В виндовс это так не сработает, приложению может и не нужен доступ к сети а вот подключенной библиотеке — нужен, и одна из таких библиотек системных — это работа с файлами, и нужна ей сеть только для того чтобы иметь возможность работать с сетевыми дисками и сетевым окружением. Всё точка — любому приложению уже потенциально нужна сеть…
Вот библиотека и будет иметь доступ к сети, а в исходных текстах приложения не будет вызова процедур доступа к сети. В этом и вся идея.
Это дырявая идея, т.к. приложения, манипулируя библиотекой, сможет без проблем справить все свои грязные делишки её кодом. Просто немного надо под другим углом посмотреть. Надо перезаписать файл? Настраиваем доверенную библиотеку логирования на вывод в нужный файл, отключаем печать префиксов/заголовков (чтобы в файл ничего лишнего не попало), и пишем всё что нужно в какой нужно файл.
Это не дырявая идея, а обычный мандатный доступ.
Разграничение будет работать только со специально написанными библиотеками, которые не доверяют приложению и полностью перепроверяют все параметры, сверяя их с текущими разрешениями (может ли это приложение писать в этот файл? а в другой файл? библиотека-то может). Всё это даст немалые накладные расходы и сильно усложнит библиотеки.
Тогда это должна быть не библиотека а сервис. Иначе… ничто не остановит приложение от прямой записи в данные библиотеки, она под полным контролем приложения.
Нет, анализ делается исключительно исходных кодов, не во время выполнения. То есть, например, принимая новую версию кода, GitHub запускает проверку и помечает эту версию как безопасную. Делается это один раз.
Для системы библиотека это часть приложения, и она не сможет отличить вызов функции АПИ сделан от приложения или библиотеки. Сверять функциональность на уровне исходных кодов? Это бред… и не для всех программ есть исходные коды, не все бинарники собраны из тех исходников которые вы видите, многие программы обфусцированы, это же какой нужен мощный анализатор чтобы это всё «пробить»?
Ведь можно сделать куда проще(что и сделано!) — цифровая подпись и доверие производителю. ЦП можно отозвать, если и будут инценденты — они будут носить единичных характер. Всё, тупая ЦП решает проблемы вмешательства в код приложения, а репутация производителя и его ответственность — проблему встраивания зловреда на этапе сборки/проектирования. И не нужны какие-то сложные анализаторы учитывающие всё-на-свете но всеравно остающиеся дырявыми.
Ведь можно сделать куда проще(что и сделано!) — цифровая подпись и доверие производителю. ЦП можно отозвать, если и будут инценденты — они будут носить единичных характер. Всё, тупая ЦП решает проблемы вмешательства в код приложения, а репутация производителя и его ответственность — проблему встраивания зловреда на этапе сборки/проектирования. И не нужны какие-то сложные анализаторы учитывающие всё-на-свете но всеравно остающиеся дырявыми.
В ДАННОЙ статье идёт речь о программах с исходным кодом, а не о коне в вакууме. Бред — это расширять в дискуссии заявленную тему.
Увы, и даже это не работает на уровне исходного кода так как хотелось бы. Одна возможность вызывать процедуры неявно ставит крест на таких проверках. Непосредственного вызова процедуры может и не быть, просто код изменит адрес указателя на нужную процедуру и осуществит вызов по указателю. Эти ситуации анализатору будет очень трудно отслеживать, особенно если подстановка адреса будет зависеть от двух и даже трёх контекстов.
В общем да, и более того — если код будет вычислять имя процедуры в языках где это возможно, например в Perl. Варианты — отказаться от таких языков или писать без самомодифицирующегося кода. Об опасности кода, который создаёт сам себя, пишется с самого начала эпохи программирования.
Это сразу ставит крест на всех нативных языках (не запускающихся в виртуальных машинах). А для виртуальных машин проблема просто сдвигается на другой уровень: пишем на VM интерпретатор, и интерпретируемый код меняет себя как данные. Или надо банить всё, что хоть отдалённо напоминает интерпретатор?
Банить надо приложения, которые пытаются получить возможность делать то что не должны. Например получив пароль из мозиллы, прочитав sqlite файл какой-нибудь, приложение не должно иметь возможности передать его по сети. Или иметь доступ к сети, но не иметь доступа к файловым операциям. Такие ограничения покроют очень большой класс приложений и библиотек. Та же библиотека очередей, о которой идёт речь, не должна была иметь доступа к функциям чтения файлов.
(Доступ к данным можно ограничить разными способами, но кроме ограничения области, в которой можно открывать файлы, особо ничего не придумать. В линуксе этим занимается например firejail. Поэтому если открыть приложению доступ к файлам, надо либо обеспечить невозможность передать информацию на сторону — что сложно, либо ограничить область доступности.)
(Доступ к данным можно ограничить разными способами, но кроме ограничения области, в которой можно открывать файлы, особо ничего не придумать. В линуксе этим занимается например firejail. Поэтому если открыть приложению доступ к файлам, надо либо обеспечить невозможность передать информацию на сторону — что сложно, либо ограничить область доступности.)
НЛО прилетело и опубликовало эту надпись здесь
Утилита синхронизации типа rsync — куда лучший пример. Её прямая задача прочитать файлы с диска, причём практически с любого каталога и отправить по сети на произвольный хост.
Про крэшрепорт пример неудачный — это само по себе опасное действие.
Приложения, которые одновременно и по сети и по файловой системе принято класть в firejail/chroot или ограничивать как-то иначе. Вообще приложениям доступ к файловой системе не нужен вообще либо нужен очень ограниченный доступ в пределах разрешённой зоны. То же с библиотеками.
Никто и не обещал что всё будет просто.
Приложения, которые одновременно и по сети и по файловой системе принято класть в firejail/chroot или ограничивать как-то иначе. Вообще приложениям доступ к файловой системе не нужен вообще либо нужен очень ограниченный доступ в пределах разрешённой зоны. То же с библиотеками.
Никто и не обещал что всё будет просто.
Такая вещь как сетевая папка ломает всю малину. Приложение которое может открыть файл неявно использует и доступ к сети. Но вроде бы этот момент как-то решён встроенным фаерволом — можно разрешить программе трафик в локальную сеть, но запретить интернет.
Банить надо приложения, которые пытаются получить возможность делать то что не должныИ это опять неформализуемый критерий, что возвращает нас к ручной проверке всех исходников.
Доступ к данным можно ограничить разными способами. В линуксе этим занимается например firejailМожно, но это другой класс решений, нежели проверка библиотек, с которыми линкуется наш проект.
Всё верно. Но менеджер очередей, который вдруг начал воровать пароли, контроль вызовов библиотечных функций отследит — потому что он вообще не должен читать ничего с диска.
Контроль в рантайме или контроль при компиляции? При компиляции программа включает 100500 ненужных зависимостей. Тут, например, упоминали, что компилятор тянет mshtml.dll — ключевой компонент от Internet Explorer. Это не запретить, не погружаясь глубоко во все исходники.
Это вы описываете работающую фичу или ваши пожелания?
Пожелания. Начинаются они тут
А вам все пытаются объяснить, что это невозможно. Как проверка кода невозможна без полноценного ИИ, так и нельзя заранее создать библиотеки на все случаи жизни.
А я вам всё пытаюсь объяснить что возможно и без ИИ и уже есть и работает. А вы всё как в танке. И даже если привлекать искусственный интеллект — почему нет? ИИ это вообще громкий термин, то что сейчас называют ИИ интеллектом не является, но в определённых областях работает.
Насчёт библиотек — возможно, это вообще неизбежный процесс. Вы думаете, поддержка софта в нынешнем виде это вообще нормально? Когда приходится раз в несколько лет менять методики программирования и изучать новые технологии. Унификация происходит постепенно.
И хорошо бы увидеть ваше решение проблемы.
Насчёт библиотек — возможно, это вообще неизбежный процесс. Вы думаете, поддержка софта в нынешнем виде это вообще нормально? Когда приходится раз в несколько лет менять методики программирования и изучать новые технологии. Унификация происходит постепенно.
И хорошо бы увидеть ваше решение проблемы.
я вам всё пытаюсь объяснить что возможно и без ИИ и уже есть и работает. А вы всё как в танкеТак покажите пальцем, где это работает.
Вы думаете, поддержка софта в нынешнем виде это вообще нормально? Когда приходится раз в несколько лет менять методики программирования и изучать новые технологииНормально, потому что меняются ожидания юзеров от информационных систем. Раньше им нормально было с перфокартами работать, потом с текстовыми консолями, затем с графическими приложениями, сейчас уже хотят, чтобы через всё работало через браузер, завтра захотят VR. Как тут обойтись однажды сделанными библиотеками?
И даже если привлекать искусственный интеллект — почему нет? ИИ это вообще громкий термин, то что сейчас называют ИИ интеллектом не является, но в определённых областях работает.Именно, что для этой задачи нужен полноценный, сильный ИИ, а не то, что сейчас им называют. А такого нет ни у кого.
И хорошо бы увидеть ваше решение проблемы.Решение проблемы — экономическое. Хотите надёжность — платите за аудит всего кода, как за атомный авианосец. Хотите за 3 копейки — примите риски, что все ваши данные могут рухнуть (делайте бекапы).
Боюсь, что это будет сложно назвать рабочим решением. Оно наверняка имеет массу ограничений по области применения чтобы гарантировать надёжную защиту. А то получится как всегда — железная титановая дверь, супернавороченный невзламываемый замок и ключ от него под ковриком… ну а что, вдруг потеряю его если носить с собой буду.
К сожалению, класс подобных проблем может быть решён только в частных случаях. Те же виртуальные методы в языках, возможность на лету переназначить процедуру-обработчик и вся схема проверки летит к чертям.
К сожалению, класс подобных проблем может быть решён только в частных случаях. Те же виртуальные методы в языках, возможность на лету переназначить процедуру-обработчик и вся схема проверки летит к чертям.
Если применить в промышленном масштабе — то будет работать.
Если для доступа к файлам есть набор апи, то никакие виртуальные методы не пройдут мимо этого апи. Либо оно используется, либо нет. Это не замок, это набор свойств, что-то вроде списка затребованных интерфейсов.
Одна из реализаций: приложение или функция (часть библиотеки) перед выполнением требует адреса методов для доступа к сети, дискам, памяти и т.д. Не имея доступа к методам, оно просто не сможет получить такой доступ. Соответственно можно сравнивать списки запрошенных методов и список методов, которые приложение зарегистрировало для себя. Это даже не потребует анализа исходных кодов, это защитит от генерации кода на лету, это просто реализовать.
Другая реализация: приложение вызывает только функции в явном виде. Статический анализ эти функции отслеживает и сравнивает со списком разрешённых. Тот же эффект — несовпадение списков означает что приложение делает не то что надо.
Действительно, все проблемы это не решит, но решит очень многие. Решит проблемы всех библиотек, которым не нужен файловый доступ и не нужна сеть — процентов 99 библиотек наверно будет. Остальные надо как-то иначе проверять.
Если для доступа к файлам есть набор апи, то никакие виртуальные методы не пройдут мимо этого апи. Либо оно используется, либо нет. Это не замок, это набор свойств, что-то вроде списка затребованных интерфейсов.
Одна из реализаций: приложение или функция (часть библиотеки) перед выполнением требует адреса методов для доступа к сети, дискам, памяти и т.д. Не имея доступа к методам, оно просто не сможет получить такой доступ. Соответственно можно сравнивать списки запрошенных методов и список методов, которые приложение зарегистрировало для себя. Это даже не потребует анализа исходных кодов, это защитит от генерации кода на лету, это просто реализовать.
Другая реализация: приложение вызывает только функции в явном виде. Статический анализ эти функции отслеживает и сравнивает со списком разрешённых. Тот же эффект — несовпадение списков означает что приложение делает не то что надо.
Действительно, все проблемы это не решит, но решит очень многие. Решит проблемы всех библиотек, которым не нужен файловый доступ и не нужна сеть — процентов 99 библиотек наверно будет. Остальные надо как-то иначе проверять.
Я же и говорю что применимо это только к частным случаям. А достаточно одной дырки чтобы разрушить всё здание.
Очередная утопия.
Очередная утопия.
Если покрытие 99% — то это не такая и дырка. Сейчас ведь любой nodejs или руби / питон проект тащит с гита или охожих складов кучу либ, и именно через них не первый раз встраивают бэкдоры. Минимальными усилиями можно с этим более-менее бороться. Это возможно даже сейчас, автоматически анализируя внесённые исправления в какую-нибудь эталонную версию. А введя общую систему библиотечных вызовов высокого уровня будет совсем просто. Какими то жертвами, конечно, типа запрета лазить в системные функции.
Если покрытие 99% — то это не такая и дыркаНет, все злодеи будут целенаправленно целить в незакрытый 1%.
Это как с антивирусами — какой смысл писать вирус, если он определяется и ловится эвристикой. Имея под рукой антивирус, автор вируса допиливает свой вирус до тех пор, пока антивирус не перестал срабатывать.
перед выполнением требует адреса методов для доступа к сети
Вот это, кстати, интересная идея.
Навскидку проблема в утечке адресов. Когда приложение узнает адрес, куда стучаться, косвенным методом. Ну и ничто не мешает приложению запросить права для полезных операций, а заодно сделать вредную.
уже есть и работает. А вы всё как в танке
Если я вам скажу, что вечный двигатель уже есть и работает — вы мне поверите на слово? Вряд ли. Вот и вам на слово не верят, что есть универсальный анализатор подобного рода.
Все библиотеки как апи и политика разрешений, как вы описали ниже — намного более рабочий вариант, чем анализатор (хотя вы, вероятно, не видите разницы), но он сильно замедлит выполнение (потому что есть ли у приложения право вызвать Х — нужно проверять). Это было бы хорошим направлением, если б у нас был запас по вычислительной мощности ещё пару порядков, но это вряд ли. Закон мура загнулся.
НЛО прилетело и опубликовало эту надпись здесь
Есть какие-то разумные допущения, которыми надо пользоваться. Если мы не доверяем компилятору, то почему мы доверяем процессору или монитору? Отсутствие в исходниках обращения к ресурсу, если это можно проверять, потребует от компилятора чудесного поведения чтобы этот доступ появился. Речь не о уязвимостях, а о использовании сторонней библиотеки, контролировать которую мы не можем. Тут не поможет даже виртуальная машина — приложение, работающее с кошельком, и взломанная библиотека работают в одном пространстве. Единственный вариант кроме ручной проверки изменений — это какая-то автоматизация.
Не понятен даже предмет автоматизации. Вот есть у меня библиотека — ООП обёртка над процедурными файловыми операциями. Над любыми файлами, если процесс имеет права администратора. Что в ней проверять? Что она работает только с файлами? Но в Линуксе всё файл.
Значит ваша ООП библиотека имеет признак «может работать с файлами» и появление в ней файловых операций не вызовет проблем. У библиотеки «event-queue» или «regexp» такого признака не будет, поэтому как только в её исходниках появляются файловые операции, это служит признаком наличия закладок. Файлы, сеть и вообще ресурсы кроме процессора и памяти нужны очень ограниченному числу библиотек.
В линуксе можно выполнить сетевое взаимодействие (отправить данные в сеть), записав в специальный файл /dev/udp.
При чём тут /dev/udp и линукс ??? Я пишу о том что всё взаимодействие должно быть через библиотеки, вы пишете что можно обойти. Да, сейчас можно. Я предлагаю сделать чтобы было нельзя.
давайте на простой аналогии: «Вам говорят, что в решете воду не носят и показывают на примере — как она легко вытекает.
А вы предлагаете сделать такое решето, чтобы было нельзя воде вытекать.»
так понятно?
А вы предлагаете сделать такое решето, чтобы было нельзя воде вытекать.»
так понятно?
При чём тут /dev/udp и линуксВы пишете, что у библиотеке, которая работает с файлами, не должно быть доступа в сеть. Я отвечаю, что это нереально проверить, т.к. через файлы можно стучаться в сеть.
Я предлагаю сделать чтобы было нельзя.Техническое решение заключается в чём? Пока это декларация на уровне анекдота «зайчики, станьте ёжиками».
Техническое решение тривиально для программиста и недоступно для обычного пользователя клавиатуры.
Техническое решение очевидно — убрать из линукса возможность стучаться в сеть через файлы. Это как бы очевидно и технически реализуемо.
P.S. про практический смысл и сколько всего сломается, я не говорю. Но технически это не магия в стиле ёжиков.
В современных ОС вроде как обычно прямое взаимодействие с железом обычным процессам запрещено, всё через ОС, через её библиотеки.И даже через её библиотеки не всё разрешено. Чем не устраивает?
Не надо разрешать всем стучаться именно в сеть. Стук должен быть более адресным. Если библиотеке нужен HTTP протокол, то разрешён именно он. Подавляющее количество библиотек вообще не требует доступа к сети. Из остальных большинство требует доступа не просто к сети, а к например апи соцсетей. То есть это возможность контролировать более детально что за сеть требуется приложению. Прямой доступ к сети такой контроль затрудняет и делает его возможным во время выполнения, и то не всегда. Доступ же через предлагаемый апи (стандартные библиотечные вызовы) позволит делать анализ на уровне исходных текстов. Это потребует стандартизации и со стороны соцсетей конечно, но она и так рано или поздно появится. То есть в профайле библиотеки будет написано «может обращаться к апи соцсети», это можно проверять на сервере хранения библиотеки (на гитхабе), и пользователь — тот кто подключает библиотеку к своему проекту — может дополнительно ввести ограничение «может обращаться к апи аутентификации соцсети фейсбук» и проверять соответствие исходных кодов библиотеки этому требованию уже при компиляции проекта. В идеале, сама по себе стандартизация библиотечных функций уменьшит количество подключаемых приложений и сузит поле деятельности для ручной проверки изменений в исходниках. Те же очереди не писал только ленивый.
Насколько вероятно запретить /dev/usb: Я не специалист в написании мобильных приложений, но нестабильная связь должна сама по себе накладывать ограничения на использование прямого доступа к /dev/usb, так что запрет доступа к нему не так уж маловероятен (ну или необычность его использования на практике). С развитием спутникового интернета даже сам протокол tcp будет использоваться меньше, понадобится какая-то прослойка для компенсации задержек и увеличения скорости передачи и надёжности, так что внедрение каких-то сетевых посредников так же невредно.
Насколько вероятно запретить /dev/usb: Я не специалист в написании мобильных приложений, но нестабильная связь должна сама по себе накладывать ограничения на использование прямого доступа к /dev/usb, так что запрет доступа к нему не так уж маловероятен (ну или необычность его использования на практике). С развитием спутникового интернета даже сам протокол tcp будет использоваться меньше, понадобится какая-то прослойка для компенсации задержек и увеличения скорости передачи и надёжности, так что внедрение каких-то сетевых посредников так же невредно.
Это что-то вроде обычной щеколды в качестве замка на металлическую дверь — скорей защита от дурака. Положительный вердикт «библиотека безопасна» ничего вообще значить не будет. Это будет только означать что в библиотеке отсутствуют топорные бэкдоры или кто-то не добавил функцию по недосмотру.
Каким образом кто-то добавит функцию по недосмотру?
копи-паст, не посмотрел не вычистил от лишнего осталась зависимость с сетевой библиотекой и т.п.
Дело в том, что предлагаемый способ как раз такие случаи хорошо отследит как попытку внедрения бэкдора.
Вообще использование стандартных библиотек открывает некоторые дополнительные возможности во автоматическому тестированию во время выполнения программы — хотя бы подстановкой отладочных версий библиотек.
Вообще использование стандартных библиотек открывает некоторые дополнительные возможности во автоматическому тестированию во время выполнения программы — хотя бы подстановкой отладочных версий библиотек.
Доверие — это не boolean, это float.
И как же вы гуглодроидом пользуетесь, когда там каждое приложение, начиная от обычного блокнота (утрирую, но видел сходное по функциональности приложение, то есть то, где это было бы совсем не в тему… не помню уже название, но требовало покупок в маркете), требует всех разрешений, от рыться в списке контактов до покупок в маркете.
Последнее время у меня ни одно приложение не требует прав при установке. Требуют в процессе работы. Надеюсь, это фича, а не баг ).
вспомнил, кстати, что за приложение требовало прав «покупок в маркете». Это было приложение «запись разговоров». Вот скажите, нагоа записывалке разговоров доступ к покупкам в маркете? сразу же ваши разговоры в ЦРУ продавать? )
по ходу аналогично. скорее всего, фича новых андроидов — приложения типа устанавливают, а потом говорят «работать не буду, если не разрешишь все-все-все». Второй способ шантажа более действеннный, меньше вероятность отказа на этом этапе.
Надеюсь, это фича, а не баг )
по ходу аналогично. скорее всего, фича новых андроидов — приложения типа устанавливают, а потом говорят «работать не буду, если не разрешишь все-все-все». Второй способ шантажа более действеннный, меньше вероятность отказа на этом этапе.
Плагины дополнительные покупать. Например плагин синхронизации записанных разговоров с облаком(своим, чужим), плагин шумоподавления или подавления эха и т.д. Сейчас это модно — давать бесплатно ограниченый функционал, а полный за дополнительную плату в т.ч. ежемесячную.
И да, запрос разрешений на лету — это фича новых андроидов, с 6-го или 7-го андроида такое ВОЗМОЖНО. Причем можно установить 3 состояния: запретить всегда, спрашивать, разрешить всегда.
И да, запрос разрешений на лету — это фича новых андроидов, с 6-го или 7-го андроида такое ВОЗМОЖНО. Причем можно установить 3 состояния: запретить всегда, спрашивать, разрешить всегда.
А первопричина проблем — отказ от Unix way в пользу яйцекладущих шерстемолочных свиней…
Надоели, значит, безошибочные, используемые десятилетиями утилиты? Ну-ну.
Надоели, значит, безошибочные, используемые десятилетиями утилиты? Ну-ну.
Надоели, значит, безошибочные, используемые десятилетиями утилиты? Ну-ну.
Хех.
github.com начал уведомлять о том, что те или иные пакеты скомпрометированы, npm audit показывает те имеющиеся проблемы. поэтому проверяй и все будет ок. второй момент, что как узнавать, что в новой версии пакета есть зловред? как раз при переходе с версии на версию необходимо немного посматривать код и в случае каких-то даже подозрений и непонятностей — сообщать сообществу для совместной проверки. возможно, мы в будущем будем платить фондам и компаниям за проверку на безопасность пакетов.
Раньше разница между открытым и закрытым кодом была качественной.
А нынче открытый код во многом настолько обфусцировался (тоннами зависимостей, кривым стилем и т.д.), что зачастую дизассемблер после его компиляции оказывается лаконичнее и понятнее, чем многочисленные "слои" исходников.
Вот ещё один мысленный эксперимент: может ли новый (но опытный) разработчик за 2 недели (80 часов) понять 80% кодовой базы, за которую он будет отвечать?
Если нет, то этот человек перегружен работой с первого дня, поскольку он по определению не сможет передать свои обязанности в течение стандартного для США периода времени. Если он уходит, вы никак не сможете подготовить замену в положенный срок. Как следствие, плавный переход невозможен, а некоторые знания о предметной области неизбежно будут потеряны.
Не очень корректный эксперимент: понимать кодовую базу с нуля без посторонней помощи и понимать кодовую базу с помощью того, кто длительное время за неё отвечал, а то и сам писал почти всю — две большие разницы даже в случае прекрасной документации. Собственно для этого и даётся эти две недели прежде всего, как по мне — для передачи дел прежде всего.
Я много раз писал. Но еще раз напишу. Приходит эпоха оптимизации ПО. Оптимизации скорости, размера, понятности и т.д.
Все чаще будем читать подобные статьи.
Все чаще будем читать подобные статьиДля прихода эпохи нужно, чтобы не статьи появлялись, а сервисы массово появлялись такие, что не жрут по 300 МБ в браузере. И софт, помещающийся на дискетку.
разве что оптимизации обывательского мышления — особенно когда лозунгами и кликбейтными заголовками бросаться («аааа! все пропало!»).
то, что в зависимых либах бывают новые баги, и что их нужно своевременно обновлять и потом не забывать проверять после обновления — это древнее знание в индустрии (например). Странно даже что джаваскриптеры так долго не спотыкались о них.
(предположу — потому что раньше они новый код писали быстрее, чем старый устаревал, но техдолг их таки догнал ...)
то, что в зависимых либах бывают новые баги, и что их нужно своевременно обновлять и потом не забывать проверять после обновления — это древнее знание в индустрии (например). Странно даже что джаваскриптеры так долго не спотыкались о них.
(предположу — потому что раньше они новый код писали быстрее, чем старый устаревал, но техдолг их таки догнал ...)
Думаю чтобы как-то решить проблему использования стороннего кода, нужна поддержка изоляции выполнения этого стороннего кода на уровне языка, операционной системы и может быть процессора. Что-то вроде вызова сторонней функции в контейнере. Допустим что мне нужна какая-то простая функция из сторонней библиотеки, непосредственно принимающая на вход массив данных и возвращающая массив данных. Так вот я бы хотел, запуская ее, быть уверен, что она не получит доступа к другим данным моей программы, не получит доступ к данным других программ, не будет иметь доступ ни к чему в моей файловой системе, и не сможет сделать сетевых вызовов.
Может кто-нибудь знает язык где возможно провернуть такое? Возможно ли это с текущими архитектурами ОС и процессоров?
Может кто-нибудь знает язык где возможно провернуть такое? Возможно ли это с текущими архитектурами ОС и процессоров?
Да, легко.
Оформляйте свою функцию отдельным процессом, режьте ему доступ на уровне системы, взаимодействуйте любым IPC, от разделяемой памяти и сокетов до REST API.
Заодно модульность повысите и подумаете не раз, так ли нужен вам очередной «leftpad» в зависимостях и с такими бубнами, или можно обойтись приватнымвелосипедом доверенным решением.
Оформляйте свою функцию отдельным процессом, режьте ему доступ на уровне системы, взаимодействуйте любым IPC, от разделяемой памяти и сокетов до REST API.
Заодно модульность повысите и подумаете не раз, так ли нужен вам очередной «leftpad» в зависимостях и с такими бубнами, или можно обойтись приватным
Большую часть проблем можно решить типизацией, что бы модуль не мог ни чего сделать, что не прописано в интерфейсе.
На каком языке программирования это возможно?
Практически любой хорошо типизированный, возможно, с урезанной стандартной библиотекой. JVM и .NET это более-менее сразу могут. Elm и Purescript, если обойтись без js-зависимостей тоже вролне изолируют модуль.
.NET сразу из коробки может запретить использовать System.IO?
Да, такая возможность предусматривается. How to: Run Partially Trusted Code in a Sandbox
Но типизация тут ни при чем. К тому же, ЕМНИП, эту песочницу уже несколько раз ломали.
Я с .NET не работал, но вроде там был аналог JVMного менеджера безопасности.
По крайней мере байткод не очень сложно проверить на отсутствие вызовов опасных библиотек и использование рефлекшена.
По крайней мере байткод не очень сложно проверить на отсутствие вызовов опасных библиотек и использование рефлекшена.
Проверить можно, но придётся отсечь все готовые библиотеки и новые принимать с большим трудом (выйдет не проще, чем всё отсматривать вручную).
Потому как в большом проекте найдётся пара мест, где пишется в файлы, например, для логирования. Доверять библиотекам-логерам тоже нельзя, потому что их можно переконфигурировать на запись в какой-то важный файл (например, в соседний, уже проверенный файл исходника записать небезопасный код), а не только во временную папку.
Потому как в большом проекте найдётся пара мест, где пишется в файлы, например, для логирования. Доверять библиотекам-логерам тоже нельзя, потому что их можно переконфигурировать на запись в какой-то важный файл (например, в соседний, уже проверенный файл исходника записать небезопасный код), а не только во временную папку.
Сторонним библиотекам ни к чему давать возможность преконфигурировать логгер.
Берём любую развитую библиотеку логирования (я рассматриваю log4net). И, внезапно, там несколько способом конфигурации: атрибутами, через app/web.config, и кодом, с полным доступом ко всем фичам.
Я к тому, что с таким подходом придётся выкинуть все библиотеки и начинать принимать только специальным образом написанные, «доверенные». Что есть нереалистично. Может, тогда заодно формальную верификацию потребуем, раз уж всё равно всё с нуля.
Я к тому, что с таким подходом придётся выкинуть все библиотеки и начинать принимать только специальным образом написанные, «доверенные». Что есть нереалистично. Может, тогда заодно формальную верификацию потребуем, раз уж всё равно всё с нуля.
«придётся выкинуть все библиотеки и начинать принимать только специальным образом написанные» — именно так и придётся делать. Для уницикации есть простая объективная причина. Сейчас приходится поддерживать программные системы, написанные 20 лет назад (примерно начало эпохи современных компьютеров). Через 20 лет это будут уже сорокалетние системы. За 20 лет сменилось несколько популярных способов логирования и туча библиотек, не говоря о языках и технологиях, и проблема только усугубляется со временем. Либо надо постоянно переписывать софт, либо, написав один раз, иметь возможность пользоваться им очень долго. Посмотрите как меняется ситуация в web-программировании. Ещё лет 10 назад активно писали сайты на самопальных движках. Сейчас приходят к мысли что пора переписать на вордпресс (условно) и не тратиться на поддержку.
А способов логирования, утрируя, всего два — в файл и в эластиксёрч, почему бы и не стандартизировать. (Конфиги Log4* кстати простой программист и не осваивает до конца даже на тривиальном уровне, как я недавно обнаружил в одном форуме — сложноват он для масс, хотя и казался удобным — слишком много умеет). Логирование — отличный образец для унификации.
А способов логирования, утрируя, всего два — в файл и в эластиксёрч, почему бы и не стандартизировать. (Конфиги Log4* кстати простой программист и не осваивает до конца даже на тривиальном уровне, как я недавно обнаружил в одном форуме — сложноват он для масс, хотя и казался удобным — слишком много умеет). Логирование — отличный образец для унификации.
К какому интерфейсу унифицировать логирование? К самому простому нельзя — кому-то не хватит функциональности. К самому сложному нельзя — найдутся те, кто не осилит. В итоге всем не угодить.
Log4* угодил же, после знакомства с ним особых причин использовать что-то другое нет смысла. Документацию нормальную написать осталось (последний вопрос на который я по нему ответил — как вывести в два файла. Вроде тривиально, но вызвал затруднение, значит есть проблема) и упростить тривиальные случаи применения.
Программирование потихоньку переходит в корпоративный сегмент, где вопросы решаются просто — сколько стоит создание и поддержка. А стоит унификация всяко дешевле поддержки зоопарков.
Программирование потихоньку переходит в корпоративный сегмент, где вопросы решаются просто — сколько стоит создание и поддержка. А стоит унификация всяко дешевле поддержки зоопарков.
Несколько месяцев назад читал комментарии о выборе логгера под .NET
Местные гуру убеждённо утверждают, что log4net — прошлый век, и вообще надо использовать мета-логеры (которые принимают на себя поток и могут раздавать его в другие логгеры, в тот же log4net), например, serilog. Под впечатлением я даже один свой проект начал на serilog. Ну так, ничего особенного, логгер как логгер.
Так что, как бы вам ни хотелось, всегда будет толпа программистов, которым ваша унификация библиотек побоку.
Местные гуру убеждённо утверждают, что log4net — прошлый век, и вообще надо использовать мета-логеры (которые принимают на себя поток и могут раздавать его в другие логгеры, в тот же log4net), например, serilog. Под впечатлением я даже один свой проект начал на serilog. Ну так, ничего особенного, логгер как логгер.
Так что, как бы вам ни хотелось, всегда будет толпа программистов, которым ваша унификация библиотек побоку.
Вы не понимаете моё предложение. Я не предлагаю решением вариант, который все смогут принять или нет. Мой вариант решения многих проблем — поставить программистов перед фактом.
Относительно вашего мегалоггера. От того что он мега, не меняется ничего. Он будет принимать тот же набор данных что и любой другой, интерфейс одинаковый. Реализация может быть любой. Главное чтобы программист мог решить задачу логирования и при этом возможность вести логи не требовала предоставления например к директории /var/logs или сети в целом.
Относительно вашего мегалоггера. От того что он мега, не меняется ничего. Он будет принимать тот же набор данных что и любой другой, интерфейс одинаковый. Реализация может быть любой. Главное чтобы программист мог решить задачу логирования и при этом возможность вести логи не требовала предоставления например к директории /var/logs или сети в целом.
Перед каким фактом? Уголовная ответственность за использование в своём коде неодобренной вами библиотекой или за распространение таких библиотек?
Мой вариант решения многих проблем — поставить программистов перед фактомАвтор этой статьи поставил всех программистов перед фактом: «всё плохо». Какие проблемы этим решены?
Автор озвучил проблему, которая волновала давно всех — как можно брать бинарник/тексты и просто запускать без проверки. То что это сумасшествие — понятно как оказалось мало кому. Ну его статью может увидят руководители и начнут разработчиков трясти как они могли пойти на подобное. Одна из проблем — безответственность программистов — таким образом если не решена, то будет контролироваться.
Поттеринг поставил всех перед фактом — или пользуйтесь, или скатывайтесь в позицию маргинала-человеконенавистника. И все вменяемые это воняли правильно. Нужен второй Поттеринг, чтобы навести порядок в опенсурсе. Его будут ненавидеть, писать всякие гневные посты про то что вот нам хочется логировать именно так а не иначе — когда найдётся такой с каменной посылалкой всех в попу и поддержкой от бизнеса, всё получится.
Поттеринг поставил всех перед фактом — или пользуйтесь, или скатывайтесь в позицию маргинала-человеконенавистника. И все вменяемые это воняли правильно. Нужен второй Поттеринг, чтобы навести порядок в опенсурсе. Его будут ненавидеть, писать всякие гневные посты про то что вот нам хочется логировать именно так а не иначе — когда найдётся такой с каменной посылалкой всех в попу и поддержкой от бизнеса, всё получится.
статью может увидят руководители и начнут разработчиков трясти как они могли пойти на подобное. Одна из проблем — безответственность программистов — таким образом если не решена, то будет контролироваться.Я на это ой как сильно надеюсь. Так и предвкушаю этот разговор: хотите хорошо? — дайте денег. По 100500 руб. за каждую фичу, чтобы не юзать непроверенный опен-сорс, а писать самому. Нет денег? — тогда что вы предлагаете?
А очень просто. Запретят использования тех языков и технологий, которые допускают подобное. Все же понимают, что сегодня безобидный майнер вставили или из кошелька три цента украли, а завтра украдут вообще всё и фирма и её клиенты разорятся. Ну не все — программисты этого не понимают, а начальники просто не в курсе. И перейдут на другие технологии. То есть на платный софт с поддержкой. От Микрософт например, зарёкшись иметь дело с опенсурсом в принципе, раз опенсорс так гадит. Деньги да, какие-то потребуется вложить в любом случае и быстро процесс не пойдёт.
А очень просто. Запретят использования тех языков и технологий, которые допускают подобное.В рамках фирмы — буду очень рад. Ведь это такое счастье не сидеть кодить тупую бухгалтерию или очередной интерфейс по тупому ТЗ, а собственноручно создавать сложные системные библиотеки, ходить самому по всем граблям (куда уж без этого). Если фирма настолько богата, как Microsoft, почему нет )))
Кто запретит и кому? И чем де-факто закрытый опенсорс код хуже закрытого и де-факто, и де-юре кода майкрософта?
интерфейс одинаковый. Реализация может быть любойАбсолютно нет. Функциональность разная. Разные политики блокировки файлов, разные возможности (например, может писать логгер ID процесса или потока в префикс, или не может), разные абстракции (те же самые appenders и loggers в log4*).
Если думаете, что ничего принципиального нового всё равно нет, то вот оно — Structured Logging. Там ещё работать и работать до полного понимания требований и унификации.
Хм… даже для Delphi его адаптировали.
В .Net можно выполнить код во временно созданном домене, для которого можно настроить ограниченные права. Штатными средствами домены не могут получить доступ к данным друг друга (взаимодействие организовано почти как между процессами). Правда, с этой целью я ими не пользовался, могу в чём-то ошибаться. Но для безопасного подключения плагинов это используется, насколько мне известно.
Любая просьба «прекратите писать новые фичи» напоминает просьбу фермера «не стройте новых заводов». Ответ — «нет».
А вот что делать? Если бы можно было сказать простой ответ… Их нет. Есть робкие попытки поправить core инфраструктуру (например, недавно libsvg перешёл на версию, переписанную на расте, и это big fucking deal, потому что от неё зависят 100500 приложений, так что во многих приложениях, наверное, работа с svg станет чуть лучше и чуть надёжнее), но у нас огромные пласты легаси-кода, которые шуршат даже в shiny new версиях софта.
Систему ПО невозможно контролировать целиком, надо доверять. Компиляторы и ОС, на которых эти компиляторы работают, среды исполнения и сборки, ОС на которой софт работает…
Просто верьте. И да, читать Документацию (aka исходный текст) иногда нужно и полезно. Есть робкая надежда, что читающих достаточно много.
Вторая важная вещь — мы можем это всё увидеть, то есть хотя бы аудит проводить легко и без всяких мрачных NDA.
А вот что делать? Если бы можно было сказать простой ответ… Их нет. Есть робкие попытки поправить core инфраструктуру (например, недавно libsvg перешёл на версию, переписанную на расте, и это big fucking deal, потому что от неё зависят 100500 приложений, так что во многих приложениях, наверное, работа с svg станет чуть лучше и чуть надёжнее), но у нас огромные пласты легаси-кода, которые шуршат даже в shiny new версиях софта.
Систему ПО невозможно контролировать целиком, надо доверять. Компиляторы и ОС, на которых эти компиляторы работают, среды исполнения и сборки, ОС на которой софт работает…
Просто верьте. И да, читать Документацию (aka исходный текст) иногда нужно и полезно. Есть робкая надежда, что читающих достаточно много.
Вторая важная вещь — мы можем это всё увидеть, то есть хотя бы аудит проводить легко и без всяких мрачных NDA.
В идеале, пакеты должны быть изолированы и не иметь возможности залезть в потроха других пакетов иначе как через публичный интерфейс и явно переданные объекты.
Понятно, почему Elm предпочитает принимать написанные целиком на нем пакеты, а не биндинги к js.
Понятно, почему Elm предпочитает принимать написанные целиком на нем пакеты, а не биндинги к js.
В идеале, пакеты должны быть изолированы и не иметь возможности залезть в потроха других пакетов иначе как через публичный интерфейс и явно переданные объекты.увы, эти идеалы разбиваются о банальный: «какая потом будет скорость итогового приложения ?»…
Elm быстрее реакта. А в нем без js-модулей далеко из песочницы не вылезешь.
как считаете — он спасет от rowhammer'a?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Де-факто закрытые исходники: аргументы в пользу понятного софта