Но 5 звёздочек это 5 звёздочек

И хватит уже дрочить на звездочки. Как дети в песочнице, ей богу.

около 1200 уязвимостей

Да, вот это настоящее решето.

Результат эксплуатации — он упал.

по-моему - ты наркоман

Что за ерунду ты несешь, какой ещё стандартный способ уронить может быть? :D

kill -9, например. Сюрприз? OOM-киллер ещё есть. Да мало ли способов грохнуть приложение

по-моему - ты наркоман

Аргумент?

kill -9, например. Сюрприз? OOM-киллер ещё есть. Да мало ли способов грохнуть приложение

Я так и думал что ты на это намекаешь. Да, если у злоумышленника есть возможность этим воспользоваться, значит система уязвима. Не важно кто виноват, админ ли, установивший слабый пароль, или компьютер просто стоял без присмотра и не залочен. Если к компьютеру есть физический доступ посторонним людям — он уязвим.

Да, если у злоумышленника есть возможность этим воспользоваться, значит система уязвима

охренеть.

Если к компьютеру есть физический доступ посторонним людям — он уязвим.

Ты делаешь фантастические успехи в деградации - если раньше у тебя только crash был уязвимость, то теперь просто существование программы - это уже уязвимость.

который удалит файл, далее переключаемся назад на наш процесс — и бац!

Зачем так жить? Разве удаление данных работающего процесса это штатно?

ок, что на счёт недоступности подмонтированного сетевого ресурса, или выдергивания флешки (может даже не специально), или выпадение второго винчестера с системы?

Программа должна предусмотреть возможность максимально сохранить данные или сессию в другом месте, а не крашится.

Даааа, глючный Debian,ага

Писал уже, что допускаю такое. Просто обновиться всё руки не доходят.

4.2 в заголовке! такое ощущение, что у anonymous_incognito отсуствует 90% мозга, если он подтвердил такое.

Причем здесь дебиан? Для него отдельно софт пишут что ли? Смените заголовок

:) святая наивность. То что в сlosed-source не светят уязвимостями на публику еще не значить что там их меньше. А по факту - даже больше, ведь и тестировщиков больше.

:)

зачем с ним споришь? дураку ведь, как известно, хоть кол на голове теши...

Один новость написал криво, второй подтвердил, не прочитав, а третий уже которую страницу бред несёт про это.

Debian выбрали для проверки, так как это один из самых больших дистрибутивов с готовыми бинарниками. Это даёт возможность проверить кучу OpenSource софта не компиляя его самолично. В дальнейшем планируется так же проверить Debian Unstable, чтобы посмотреть динамику исправления ошибок и другие дистрибутивы, но пока этого не сделано, чтобы не плодить множество отчётов об ошибках на разных багтрекерах. Собственно по этой же причине данный отчёт выполнен разом про все 1200 ошибок, а не по отдельности. Помимо этого, сообщения обо всех найденых ошибках направлены мантейнерам пакетов в дебиане и непосредственно разработчикам софта. Для непонятливых поясню - ошибки в ванильном софте и они до сих пор не исправлены, раз есть смысл слать разработчикам багрепорты.

Можешь и дальше молиться на циферки в номере версий и кричать о том, что дебианы с редхатами слоупоки. Закрытию багов это хоть и не способствует, но может тебя как-то успокоит.

В дальнейшем планируется так же проверить Debian Unstable

Уже сделано. Дальше в рассылке говорилось, что все баги перед составлением отчета на всякий случай проверили на Unstable.

Ну ты и дебилушка, про return -1; стало быть не слышал?

при чём тут это, гениальный ты наш? Давай весь код, а то не все тут такие умные как ты.

Segfault - это вообще-то segmentation fault.

я знаю, что это не холодильник.

сел ты за чужой комп, запустил ballz, понажимал кнопочки - ballz хряпнулись. Чего ты этим добился? Проэкспулатировал уязвимость? И где собсно результат эксплуатации?

Прекрати шланговать как drBatty. Результат эксплуатации — он упал.

вообще-то это ты шлангуешь.

Пример из RL: предположим ты злоумышленник. И имеешь умение скорчить рожу, такую, что на тебя будет насрать. Да, это уязвимость, если подействует на охранника, и ему будет насрать, что ты проник на объект. Но если ты скорчишь рожу дочке боса, и этой дочке будет на тебя насрать, то вряд-ли это можно считать «уязвимостью». Скорее наоборот — ты лишишься одного из способов проникнуть на объект, трахнуть дочку, что-бы она тебя туда привела.

Что за ерунду ты несешь, какой ещё стандартный способ уронить может быть?

наверное сигнал послать какой-нибудь. (ctrl+c == SIGINT)

Да, если у злоумышленника есть возможность этим воспользоваться, значит система уязвима. Не важно кто виноват, админ ли, установивший слабый пароль, или компьютер просто стоял без присмотра и не залочен. Если к компьютеру есть физический доступ посторонним людям — он уязвим.

удобно быть шлангом?

Успокойся, это был просто сарказм

Вопрос о размере пакетной базы был задан в контексте «несколько порядков» тому, кто вероятно порядки с разами путает.

Да-да, не умею читать, путаю порядки с разами и дрочу на звёздочки. Короче быдло полное. Спасибо за лестные предположения.

Ну и что в этом необычного? Ведь стабильность дебиана заключается не в отсутствии багов, а в их предсказуемости.

Когда я вижу как ты шлангуешь,
Малыш, ты меня волнуешь.
© Мумий Тролль

Повторять опять всё в третий раз я уже не буду. Перечитывай тему, мне надоело.

Привет.

А тред всё не затихает. Как обычно — магия цифр в действии.

Цой, вообще-то.

Если к компьютеру есть физический доступ посторонним людям — он уязвим.

Это полный пестец.

Это полный пестец.

Да, это очень плохо когда компьютер доступен для посторонних лиц.

Прочитал комментарии - почему большинство в крайности кидается? Ну нет универсального «хорошо» и универсального «плохо».

В одних случаях крэш это правильное поведение программы. Пример - программа перед выполнением важных операций проверяет свою целостность (допустим md5 считает). Если целостность нарушена, то самый правильный вариант - крэш. Даже если эта программа ядерным реактором управляет. Никаких элегантных выходов.

Или в той же СУБД Oracle при исчезновении процесса lgwr весь инстанс прибивается (крэш), потому как без lgwr не обеспечить целостность транзакций.

А, вот libreoffice, например, не должен падать если редактируется файл на флешке и флешка выдергивается. Потому как другие файлы могут быть открыты, да и скорее всего куски этого с флешки, те что в памяти можно сохранить в другом месте.

Если целостность нарушена, то самый правильный вариант - крэш.

Это неправильный вариант. Падения *никогда* не должны быть «by design». Да, лучше упасть, чем попортить данные или выполнить недопустимую в данный момент операцию, но всë равно это ненормально. Если программа перед выполнением важной операции обнаружила нарушение целостности себя или данных, она должна выдать соответствующее сообщение на экран и/или в лог, после чего либо просто не выполнять эту операцию, либо вообще завершить работу, но не падать.

А как же let-it-crash philosophy?

Перечитывай тему, мне надоело.

слив засчитан.

Вот мне больше заняться нечем кроме как целыми днями отвечать на твой тупняк, при том что все ответы я здесь уже написал по два раза.

Если программа перед выполнением важной операции обнаружила нарушение целостности себя или данных, она должна выдать соответствующее сообщение на экран и/или в лог, после чего либо просто не выполнять эту операцию, либо вообще завершить работу

выдача сообщений, отмена транзакции, завершение работы и т.д. — тоже работа. И это исполнение кода тоже подвержено уязвимости.

Вот смотри: программа скачала саму себя из интернета, и видит, что скачалась НЁХ. По твоему, программа должна передать управление этой НЁХ, или ВНЕЗАПНО завершить работу? ИМХО лучше завершение, и чем скорей, тем лучше.

либо просто не выполнять эту операцию, либо вообще завершить работу, но не падать.

твой член запрограммирован по другому.

Вот мне больше заняться нечем кроме как целыми днями отвечать на твой тупняк, при том что все ответы я здесь уже написал по два раза.

ты здесь уже много раз высказал своё мнение, и я твоё мнение уже понял. Не нужно ещё раз повторять, что ты хочешь жить в идеальном мире. Т.е. в таком, когда в программах нет ошибок, оборудование работает без сбоев, а пользователь внимательно читает сообщения об ошибках, и ВСЕГДА принимает обдуманное и трезвое решение.

Спешу тебя расстроить: в программах ВСЕГДА есть ошибки, даже в твоих. Оборудование часто даёт сбой, ИЧСХ, компьютер это не пылесос, он выполняет миллиарды операций за секунду, и следовательно, ничтожная ошибка для пылесоса превратит компьютер в кирпич. Что касается пользователя, то тут совсем плохо, ибо он НИКОГДА не читает сообщения, и ВСЕГДА требует неукоснительного соблюдения взаимоисключающих §§.

Посему, в некоторых случаях, программе лучше просто рухнуть. Если она конечно выполняет ОЧЕНЬ ОТВЕТСТВЕННУЮ ЗАДАЧУ.

Вот пример: если твой офисный пакет дал сбой, то ничего страшного, если он затрёт твой важный документ, и запишет туда какую-то ерунду. Но если программа управляет ядерным реактором, то ей лучше рухнуть, что-бы управление реактором взяла на себя более примитивная автоматика, которая попросту его заглушит, сбросив туда стержни с поглотителем.

Кстати, в подтверждение тому, я могу привести тебя: если твой мозг не сможет справится с нагрузкой, он просто вырубится, и управляться ты будешь более примитивными подсистемами (спинным мозгом). Называется оно по разному: обморок, нокаут, кома, и т.д..

Посему, в некоторых случаях, программе лучше просто рухнуть. Если она конечно выполняет ОЧЕНЬ ОТВЕТСТВЕННУЮ ЗАДАЧУ.

Нет, это неправильная работа. Ошибки должны обрабатываться.

Но ты не увиливай, я вообще то жду когда ты прогонишь тест на Слаке, потому что ты заявил что у тебя Патрик якобы всё проверяет и поэтому в Слаке ошибок меньше. Ага, прочёсывает весь код программ в репах и исправляет все ошибки.

Разочаровал меня это релиз. Чуть ли не самый бажной из всех. Он также запомнится выпилом гнома2.

Посему, в некоторых случаях, программе лучше просто рухнуть. Если она конечно выполняет ОЧЕНЬ ОТВЕТСТВЕННУЮ ЗАДАЧУ.

Нет, это неправильная работа. Ошибки должны обрабатываться.

ну хватит жить в идеальном мире, признай, что твоё «должны» не всегда выполняется IRL. Да, «должны», но не всегда это возможно. Тут как с боксёром: да, он ДОЛЖЕН драться, но если он пропустил удар в висок, и его мозг просто НЕ МОЖЕТ работать, то единственное, что ему остаётся — тупо рухнуть на пол без сознания.

Но ты не увиливай, я вообще то жду когда ты прогонишь тест на Слаке, потому что ты заявил что у тебя Патрик якобы всё проверяет и поэтому в Слаке ошибок меньше.

в слаке ошибок меньше потому, что пакетная база меньше. У меня например всего 1271 пакет, это full install и ещё пара десятков левых программ. Даже если процент как в дебе, то ошибок всё равно будет в 20 раз меньше. Но процент тоже меньше, ибо Патрег всякую ерунду в слаку не встраивает(в отличие от команды деба).

И да, прогонять тест — тоже работа. Это исследование. Кто мне за это заплатит? Авторы тестилки раскручивают свою тестилку, а мне это зачем?

Мы все умрем!?

ну хватит жить в идеальном мире, признай, что твоё «должны» не всегда выполняется IRL. Да, «должны», но не всегда это возможно.

Поэтому в ответственных местах используют не Линуксы, а всякие узкоспециализированные системы реального времени. Никому и в голову не придет поставить на марсоход Линукс.

И да, прогонять тест — тоже работа. Это исследование. Кто мне за это заплатит? Авторы тестилки раскручивают свою тестилку, а мне это зачем?

Защитить честь Патрика же, которую ты же и опозорил.

А как же let-it-crash philosophy?

Гугл говорит, что этот принцип пошёл из Erlang и рассчитан на то, что упавший процесс будет автоматически перезапущен без серьёзных последствий для всей системы в целом. Конечно, эту идею можно реализовать и на других языках (пример — почтовый сервер Postfix, в соответствии с Unix-way разбитый на кучу [относительно] независимых программок, падение [почти] любой из которых приведёт, в худшем случае, к потере одного письма, но не повлияет на работоспособность всего сервера), но следовать ей везде подряд не стоит.

В общем, тут как и везде: «можно» != «нужно», суперуниверсального метода обработки ошибок нет.

выдача сообщений, отмена транзакции, завершение работы и т.д. — тоже работа. И это исполнение кода тоже подвержено уязвимости.

Если программа может попортить данные или ещё чего подобное сотворить даже при выдаче сообщения, то это говно, а не программа.

Вот смотри: программа скачала саму себя из интернета, и видит, что скачалась НЁХ. По твоему, программа должна передать управление этой НЁХ, или ВНЕЗАПНО завершить работу? ИМХО лучше завершение, и чем скорей, тем лучше.

Да, завершение здесь лучше, чем запуск непойми-чего. А ещё лучше выдать на экран и/или в лог сообщение «скачалась хрень какая-то, не буду ничего запускать» и дальше действовать по обстоятельствам (если должно было скачаться обновление, то и фиг с ним, пусть установленная версия ещё какое-то время поработает; если это какой-то важный компонент, то завершить работу).

Я тут всё пытаюсь намекнуть на то, что не всякое экстренное завершение работы программы является крэшем. Если, например, при неудачной попытке выделить кусок памяти программа вместо сегфолта сообщит «память кончилась, закрываюсь», аккуратно всё за собой подчистит (временные файлы и т.п.) и завершит работу, то это вполне можно будет назвать аварийным завершением работы, но никак не крэшем.

твой член запрограммирован по другому

Кто о чём, а drBatty про МПХ. Впрочем, сексуальная озабоченность нынче в моде.

выдача сообщений, отмена транзакции, завершение работы и т.д. — тоже работа. И это исполнение кода тоже подвержено уязвимости.

Если программа может попортить данные или ещё чего подобное сотворить даже при выдаче сообщения, то это говно, а не программа.

выбирайся из своего идеального мира в реальный. Программа _сама_ ничего не пишет, а только через многоуровневые прослойки. И если хоть на одном уровне случился сбой, то исправить его у программы просто нет никакой возможности. Если close(2) выдала EIO, то у тебя тупо НЕТ другой close(2). Смирись. Произошло СТРАШНОЕ. Не, можно конечно игнорировать(как многие быдлокодеры и делают). Но лучше будет сделать креш, хотя-бы abort(2)

Да, завершение здесь лучше, чем запуск непойми-чего. А ещё лучше выдать на экран и/или в лог сообщение «скачалась хрень какая-то, не буду ничего запускать»

лучше. Вот только выдавать это сообщение должна не сама программа, а та хрень, которая её запустила. А сама программа должна крешится, если она «понимает», что её и запускать-то нельзя в данных условиях. Т.е. я говорю об ошибке верхнего уровня.

Я тут всё пытаюсь намекнуть на то, что не всякое экстренное завершение работы программы является крэшем. Если, например, при неудачной попытке выделить кусок памяти программа вместо сегфолта сообщит «память кончилась, закрываюсь», аккуратно всё за собой подчистит (временные файлы и т.п.) и завершит работу, то это вполне можно будет назвать аварийным завершением работы, но никак не крэшем.

Хороший пример. Вот только я тебе напомню тот факт, что с т.з. любой моей программы у меня сейчас ровно 18446744073709551616 байта свободно. Виртуальная память же! Но на самом деле, это конечно не так. Свободно у меня всего 1937Мб. Но и это число программа использовать НЕ может. Причина проста:

1. программа выделяет 1500Мб и занимает из них 700Мб

2. моя жена включает фконтакт и её гуглохром жрёт ещё 700Мб

3. программа жрёт ещё 700Мб, в полной уверенности, что они есть. ВНЕЗАПНО их УЖЕ нет!

Ну и что делать программе, кроме как не рухнуть? Не, я понимаю, так быть «не должно», но откуда программе знать про мою жену и её фконтакт?

твой член запрограммирован по другому

Кто о чём, а drBatty про МПХ. Впрочем, сексуальная озабоченность нынче в моде.

твой мозг, да и вообще любая система, кроме самых примитивных, тоже работает именно так: в случае невозможности выполнения задачи система отрубается, как раз для того, что-бы управление перехватили более примитивные системы. На какие-то более сложные модели поведения обычно просто нет времени и/или сил. Именно потому, в твоём мозгу нет таблички «уронить МПХ, да/нет?».

Но лучше будет сделать креш, хотя-бы abort(2)

Во-первых, abort(3).

Во-вторых, у нас, видимо, разные представления о том, что считать крэшем/падением, а что нет.

Вот только выдавать это сообщение должна не сама программа, а та хрень, которая её запустила.

В твоём примере программа сама себя и скачивала, и проверяла. А это значит, что и решение о возможности запуска скачанного файла принимает эта же программа => сообщение ей и выдавать.

Причина проста:
1. программа выделяет 1500Мб и занимает из них 700Мб
2. моя жена включает фконтакт и её гуглохром жрёт ещё 700Мб
3. программа жрёт ещё 700Мб, в полной уверенности, что они есть. ВНЕЗАПНО их УЖЕ нет!
Ну и что делать программе, кроме как не рухнуть?

Ну, тут да, программа грохнется.

Я не отрицаю, что есть немало случаев, когда у программы в принципе нет возможности более-менее нормально отреагировать на возникшую ошибку и предотвратить падение. Но, IMHO, при наличии такой возможности лучше ей всё-таки пользоваться, даже если эта реакция сводится к возврату системе занятых ресурсов и завершению работы.

Гномопроблемы.

Во-первых, abort(3).

угу. очепятался. ☹

Во-вторых, у нас, видимо, разные представления о том, что считать крэшем/падением, а что нет.

да, я считаю крешем падение программы по собственной инициативе, а ты только по внешней.

В твоём примере программа сама себя и скачивала, и проверяла. А это значит, что и решение о возможности запуска скачанного файла принимает эта же программа => сообщение ей и выдавать.

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

Я не отрицаю, что есть немало случаев, когда у программы в принципе нет возможности более-менее нормально отреагировать на возникшую ошибку и предотвратить падение. Но, IMHO, при наличии такой возможности лучше ей всё-таки пользоваться, даже если эта реакция сводится к возврату системе занятых ресурсов и завершению работы.

это конечно правильно, и с этим я не буду спорить. Однако, «завершить работу» это я и называю «падением». Разница в том, что программа просто падает, и что все ресурсы освобождаются лишь потому, что программа перестаёт существовать как сущность. Т.е. все её ресурсы освобождаются не самой программой, а операционной системой(или другой программой), которая видит, что программы нет, а её ресурс занят. При этом, если программа скажем открыла файл, она не пытается туда что-то записать, или что-то другое исправить, как при обычном выходе. Ну как ядро, которое, ежели что не так, то просто встаёт раком и мигает лампочками.

Что здесь имеется ввиду под исключениями?

тысячи необработанных исключений в бинарных пакетах

Что здесь имеется ввиду под исключениями?

Исключения в языках программирования - это зло. Как и любое зло, под строгим контролем его можно использовать для добра. Вот только массовость под строгий контроль не запихнешь. Поэтому код с исключениями или начинает потреблять слишком много ресурсов разработчиков для его контроля, или становиться падучим нечто.

да, но если она себя неправильно скачала, значит и принимать решения она не способна

Так ведь если программа сама себя откуда-то скачала, значит она уже работает, т.к. незапущенная программа не может ничего скачать. И если НЁХ вдруг поняло, что оно — НЁХ, то «поздно пить Боржоми», к этому моменту оно могло что угодно натворить.

Исключения в языках программирования - это зло. Как и любое зло, под строгим контролем его можно использовать для добра. Вот только массовость под строгий контроль не запихнешь. Поэтому код с исключениями или начинает потреблять слишком много ресурсов разработчиков для его контроля, или становиться падучим нечто.

ППКС.

Так ведь если программа сама себя откуда-то скачала, значит она уже работает, т.к. незапущенная программа не может ничего скачать. И если НЁХ вдруг поняло, что оно — НЁХ, то «поздно пить Боржоми», к этому моменту оно могло что угодно натворить.

угу. И потому, единственное, что оно может сделать полезного — тихо сдохнуть. Этим оно принесёт пользу всему своему окружению.

Почитал я про этот Mayhem поподробнее. Интересные вещи пишут:

«Например, база данных багов Ubuntu в настоящее время состоит из более 900 000 открытых багов. ...Быстрее всего был сгенерирован эксплойт для утилиты конфигурации беспроводной сети под Linux ifconfig (1.90 сек), а дольше всего - эксплойт под Windows-программу Dizzy (около 4-х часов)».

Там в таблице уязвимостей под Linux основная ошибка - переполнение стека.