Здравствуйте, vayerx, Вы писали:

V>Здравствуйте, DOOM, Вы писали:

DOO>>Покажи мне хоть одно ТЗ, определяющее функционал АС с точностью до последнего входного сигнала и реакции на него.
V>АС в данном контексте — аналоговая схема, автоматизированная система, атомная станция, etc?


V>тз бывают формальными, тз бывают педанитичными. в околоисследовательских задачах тз могут вообще не содержать конкретики. это все понятно. тем не менее, если перед вами лежит тз на разработку нового браузера и в нем (тз) нет раздела про безопасность, включающего защиту от атак, это странно. думаю, любой квалифицированный разработчик не увидев такого пункта, поинтересовался бы причиной его отсутсвия — то ли заказчик забыл, то ли рассчитывет на услугу "все включенно", то ли ему на это вдруг наплевать и он платить за это не будет.
Каким бы ни было ТЗ оно не может описать весь входной язык, все состояния автомата и функцию перехода. Это просто нереально.


DOO>>Честное определение бага было бы что-то вроде — недетерминированность конечного автомата, соответсвующего АС (это более менее понятно, хотя и не совсем верно). Т.е. если программа при получении определенных входных данных или сигнала или еще чего-то попадает в неопределенное разработчиком состояние, то это баг. Даже, если в результате ничего страшного не происходит.

V>недетерминированность конечного автомата — это, безусловно, ошибка.
Замечательно.

V>но если в тз явно указанно, что лигитимным входом считается, например, число в некотором диапазоне в строковой форме, а программе на вход подали кусок исполнямого кода, то это можно рассматривать как выход за определение конечного автомата.
Нет-нет-нет. Еще раз — так нечестно. Входной язык в данном случае это именно любой набор сигналов, которые возможно передать в систему. ТЗ тут не при чем абсолютно.

V>безусловно, я соглашусь, что квалифицированно написанная программа должна, вероятно (если вдруг обратное не обуславливается спецификой задачи), должна проверять входные данные и если уж не каким-либо образом сообщать об ошибке, то уж по крайней мере не нарушать целостности своих данных и кода и не пытаться выполнить входные данные как код. тем не менее, как бы варварски это не звучало, в общем случае некорректная работа программы при некорректных входных данных для некоторого подмножества ПО, имхо, может быть отнесена к нецелевому использованию этого ПО.
А почему ты все сводишь только к входным данным, причем только к тем, которые может ввести пользователь системы? У примеру, я видел уязвимость в web приложении, которая заключалась в том, что в таблицу БД складывалось значение HTTP заголовка User-Agent безо всякой предварительной фильтрации.
А если речь вообще идет о каком-нибудь race condition (это тоже прокол в построении автомата)?

V>разумеется, наличие верификации данных — это не бинарная характеристика ПО
ишь как излагает шельма (с)

V> если, к примеру, математический пакет падает при попытке вычислить в действительной системе корень от отрицательного числа, то это по меньшей мере "некрасиво", но если этот пакет падает, если ему подсунуть вместо аргумента для корня вместо числа в строковой форме поток бинарных данных, то это "значительно менее некрасиво" %)
Абсолютно одинаково. Если, допустим, речь идет о системе АСУ ТП, которой в результате сбоя в сети пришли искаженные данные от датчика и она помера от
этого? Тут даже злого умысла не надо... Тот же clipboard приводит к тому, что приложение потенциально должно быть готово получить из него все, что угодно.