В Ghostscript, наборе инструментов для обработки, преобразования и генерации документов в форматах PostScript и PDF, выявлена уязвимость (CVE-2023-28879), которую можно использовать для организации выполнения произвольного кода при открытии специально оформленных документов в формате PostScript. Уязвимость устранена в обновлениях Ghostscript 10.01.1 и GhostPDL 10.01.1. Проследить за появлением исправлений в дистрибутивах можно на следующих страницах: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch, NetBSD, FreeBSD...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58965
А куда бы вы встроили уязвимость, чтобы получить максимальный эфеект?
В IME
В поле для комментариев.
Чтобы по ключевым словам и выражениям сразу нафик с пляжа.
Очевидно же. В CPU.
(Meltdown не даст соврать)
> (Meltdown не даст соврать)ME тоже :)
Перейдут на арм.
> Перейдут на арм.Получится PSP.
EFI
> Ghostscript вызывается в процессе создания миниатюр на рабочем столеЭто если пользоваться гуйными ФМ. В туйных (nnn, ranger, xplr) такой проблемы нет. Вообще, рекомендую туй, один хрен из консоли не вылазим.
Чё ты там забыл, в той консоли? В гуйне намного удобнее организовывать данные, оперировать ими, можно смазать скриптами опять же.
Интеграция приложений в GUI гораздо сложнее, чем у текстовых. Поэтому в GUI меньше возможностей. Или гораздо труднее сделать нужное.
Например?
В терминале софт отдаёт текст, а BusyBox, CoreUtils и т.д. хорошо умеют в тексте найти нужное.Получается API: отдаёшь текстом команду, получаешь текстом ответ, ответ легко разобрать автоматически и в ответ отдать скриптом др. команду. Автоматизация-интеграция.
В GUI это требует совсем другого уровня трудоёмкости и развития, плюс нужно дописывать чужой софт. Вместо использования готового.
>ответ легко разобрать автоматически и в ответ отдать скриптом др. команду1. Гуй нужен для людей, а не для роботов. В топку ваш парсинг портянок портянками.
2. Для роботов куда удобнее парсить и формировать xml или json. Опять таки, в топку ваши невменяемые текстовые портянки с парсингом ради парсинга.
Если код писать не дано или не научили, то - да. Роботов писать - это писать код.А речь про другое: про интеграцию разных приложений одно решение собственных задач. GUI тогда гораздо сложнее.
Текст разобрать утилитами и отдать дальше по коду куда проще, чем дописывать нужное в GUI приложения. Из-за чего и стало так много комстроки. Т.к. удобнее и проще по итогу.
ГУЙ нужен для взаимодействия с ЧЕЛОВЕКОМ, а не для интеграции приложений.Для интеграции совсем другие технологии есть, которые успешно применяют десятки лет. RPC например банальный, простой как палка, добавляемый куда угодно.
Более того, наличие ГУЯ НЕ ОТМЕНЯЕТ наличие консольного вывода, который можно парсить как вы любите.
У гуя проблема в том что автоматизировать в нем действия крайне сложно и неудобно.Простой пример: в консольном ffmpeg я вызываю ffprobe, разбираю его вывод и для конкретных типов камер и ориентации камеры (по акселерометру) меняю параметры кодирования видео, такие вот себе "активные профайлы с мутацией". А теперь удачи этот номер в чем-то гуйном провернуть. Хоть с RPC хоть без, заодно можете засечь сколько времени на имплементацию уйдет.
Как угодно но на баше + связке консольных утилит в пайп это проще всего реализуется, за считанные минуты. И вот уже скрипт вкаылвает, варьируя параметры 150 мувикам нащелканым на разные камеры, перегоняя их в формат который вон тот старинный плеер понимает. "Вкалывают роботы".
Ты не прав, есть куча решений для автоматизации гуя, в том числе и для линукса. И автоматизировать гуй намного проще, если уж на то пошло, для этого не надо знать ни шелл, ничего.Про надёжность решения с ffprobe я наверное промолчу, а то фанаты этой поделки опять обидятся.
Пример есть? Git, статья - посмотреть на код. Какую книгу читать?Не GUI автоматизировать. А получать НЕ существовавшее ранее решение, без изменения и без дописывания чужого GUI приложения.
Сделать нужное из комплекта текстовых утилит гораздо проще, чем извлекать инфу из GUI и отдавать в др. GUI.
https://www.google.com/search?client=firefox-b-d&q=gui+autom...Порядок действий примерно такой.
Шаг1. Берёшь качественное профессиональное ПО. Что, оно не имеет средств автоматизации и пакетной обработки? Ты уверен, что оно профессиональное? Ну ладно.
Шаг2. Включаешь запись действий в любимой программе автоматизации. Ищешь окно, оправляешь в него все необходимые команды для каждой из программ, участвующих в процессе.
Шаг3. Добавляешь передачу всех необходимых данных в любом объёме и выполняешь для них записанные действия из предыдущего этапа. Получаешь содержимое и информацию об окнах для проверки содержимого, передачи между программами, или просто для вывода красивой информации о процессе работы. Разбавляешь простейшей логикой и сравнениями, для выбора поведения.Весь процесс занимает пару минут в худшем случае.
Текстовые утилиты? Не смеши, в основном это всё куча низкосортного ПО с миллионом ограничений, требующая высокого уровня компетенции от пользователя, и гуйня -- это профессиональные инструменты, доступные каждому.
Я целиком за использование баша и гну, и делал с ними такие вещи, о которых ты даже не мечтал, но не надо наговаривать на гуй. Для каждой задачи есть свои подходящие инструменты, и набор костылей и портянок это практически всегда весьма компромиссный вариант, объективно говоря, рандомный питон сделает всё куда лучше, надёжнее, и безопаснее шелла и типичных шелл-утилит.
Другое дело, что опенсорс, и, в частности, опенсорс гуйня, обычно низкого уровня, с никакущим юзабилити, чаще всего его можно только выкинуть и закопать. Тут действительно, порой имеет смысл взять _референсные_ реализации ПО, которые по совпадению часто имеют консольный интерфейс. Ну, скажем, ffmpeg днище именно в плане получения информации о файлах. Если нужны теги, стоит взять полноценное ПО для получения тегов. Если необходима информация о файле, имеет смысл использовать утилиту, качественно работающую конкретно с этим форматом файлов.
Найти качественное гуёвое приложение куда проще, чем обходить проблемы и ограничения консольного ПО, опять же.
1. Нет у гуя никакой проблемы автоматизации, ниже вам объяснили.
2. Еще раз, для аутистов, гуй НЕ ОТМЕНЯЕТ консольного вывода и функционала направленного на автоматизацию.Еще раз, еще, ты блин прочитай что тебе пишут. ГУЙ, НУЖЕН, ДЛЯ, ВЗАИМОДЕЙСТВИЯ, С, ЛЮДЬМИ.
> 1. Нет у гуя никакой проблемы автоматизации, ниже вам объяснили.Кроме того что там в РАЗЫ больше возни. И не делается "здесь и сейчас", однострочником, за 15 секунд, после чего комп в автоматическом режиме решает проблему которая вручную потребовала бы полдня клацаний. Автоматизация для гуев бывает но по сравнению с вон тем - она ужасна. Я это делал поэтому имел возможность сравнить.
> 2. Еще раз, для аутистов, гуй НЕ ОТМЕНЯЕТ консольного вывода и функционала
> направленного на автоматизацию.В какой нибудь винде допустим деление крайне жесткое. Вы либо консольная программа, либо гуйная. Нет, в теории гуйная программа может аллоцировать консоль, а консольная создавать окна. Но они все равно довольно фундаментально отличаются. Консольной принудительно создают окно консоли, и отказаться от этого малореально. У гуйной окна консоли изначально нет и чтобы что-то делать с консолью ее надо сперва создать и это сильно отдельные приключения. Можно сказать что проблемы индейцев шерифа не интересуют, но в портабельных программах - увы и ах, придется это безобразие учитывать. Иначе это не будет портабельной программой.
> Еще раз, еще, ты блин прочитай что тебе пишут. ГУЙ, НУЖЕН, ДЛЯ,
> ВЗАИМОДЕЙСТВИЯ, С, ЛЮДЬМИ.Люди разные бывают. И то что хорошо чайнику и нубу не обязательно хорошо и эффективно для продвинутого спеца. Хомяк не парится 200 раз мышкой перетащить. Спец вкатит oneliner который это сделает за 20 секунд а не 2 часа пыхтения. И эффективность взаимодействия с компьютером будет очень разной.
> 1. Гуй нужен для людей, а не для роботов. В топку ваш
> парсинг портянок портянками.А таки этот гражданин ничего не понял в мощи юниксвэя... зря, так то очень мощный концепт, позволяющий БЫСТРО автоматизировать рутину. В лучшем случае однострочником по месту.
> 2. Для роботов куда удобнее парсить и формировать xml или json. Опять
> таки, в топку ваши невменяемые текстовые портянки с парсингом ради парсинга.Ну да, XML и JSON вменяемые. Осталось найти софт готовый в результате получить на вход произвольно скроенную XML или JSON без всяких забавных спецэффектов. Парсинг пайплайна как текста может выйти даже надежнее - в силу примитивности и значительно более скромного количества допущений. Это правда совсем не значит что шеллом безопасно парсить недоверяемые данные, но это и вон тех касается. Еще хуже пожалуй.
> А таки этот гражданин ничего не понял в мощи юниксвэя... зря, такНет никакой мощи юниксвея это миф. Юниксвей - оправдание технологической ущербности.
> то очень мощный концепт, позволяющий БЫСТРО автоматизировать рутину. В лучшем случае
> однострочником по месту.Видел я ваши однострочники портянок на тысячи строк.
> Нет никакой мощи юниксвея это миф. Юниксвей - оправдание технологической ущербности.Вот те раз, а я этой мощью пользуюсь во всю и для меня это был повод с винды на линух уйти. Там это все намного лучше работает. Винда автоматизации поддается крайне туго, а заодно это вылезает и на всяких смежных вещах типа ремотного управления, серверов и автоматизации.
> Видел я ваши однострочники портянок на тысячи строк.
Это как? Однострочник по определению то что в 1 строку влезло. Если больше, это уже утрачивает звание однострочника.
Ну или вон например, я на баше накидал тупенький но эффективный классификатор. Смотри, у юзера умер винч и ФС. Там не было бэкапа на пару лет фоточек и видео, так что они были позарез нужны назад. Ну как умер, стандартно оттуда уже ничего не читалось, бэдсекторы в куче мест, файлуха угрохана попытками починок просто в хлам. Но снять образ спецтулами - реально. А потом photorec вполне себе находит ... примерно 400 000 фоточек и видиков. И как среди них нужные, спрашивается, найти?! Ну я взял да запустил ffprobe на это все и в башскрипте искал вполне конкретный тег даты, с конкретными годами. Накодить его заняло минут 5. Через еще 5 минут вджоба скрипт культурно разложил мувики и фоточки за нужные годы и даже переименовал файлы в адекватные имена. При том это - как пример конкретной разовой задачи где довольно большой объем лопатинга данных был шустро спихан на комп, который за 5 минут расклассифицировал файло на интересное и не очень среди 400К файлов и даже вирнул файлам утраченые имена (файлуха же померла, вместе с именами).
А вот как бы такой финт в гуе смотрелся, черт его знает. Даже если на энную задачу найдется программа, на соседнюю чуть поменяется критерий уже нет. Я сменю в скрипте критерий да пущу его еще раз. И он по соввсем иному критерию выцепит, переименует или что там. А в гуе это все как делать? И да, это тоже взаимодействие человека с машиной. Просто продвинутое, с прицелом на совсем другие уровни эффективности взаимодействия чем у виндового мышевозилы.
> Парсинг пайплайна как текста может выйти даже надежнее - в силу примитивности и значительно более скромного количества допущений.Пайп ортогонален json'у. Никто не мешает читать из пайпа json и парсить его. Ах, увы, bash не умеет, надо внешние утилиты подключать. Юниксвей сакс.
> Пайп ортогонален json'у. Никто не мешает читать из пайпа json и парсить
> его. Ах, увы, bash не умеет, надо внешние утилиты подключать.JSON вообще крайне мало кто может спарсить корректно в его сложном виле
> Юниксвей сакс.
А мне нормалек. И в гробу я ваш json видал, парщиво что для человека, что для машины. Хотя XML по этому критерию так то еще хуже будет. Да, вы представляете, на уровне машины JSON парсить ничем таким не хорошо. А XML так вообще крындец, если со ВСЕМИ спеками. Типа XSLT какого-нибудь (кто про него вообще помнит, но так можно было и формально если кто его не умеет, спеки не полностью реализованы, лол).
И кстати XSLT был явно изобретен Капитаном НеОчевидностью. Потому что нормальному человеку врубиться в то как это работает вообще без поллитры не реально.
А так все просто, не нравится не пользуйтесь. Посмотрим кто кого по эффективности.
Намного, несравнимо проще. Пишешь какие хочешь desktop файлы и они довольно гибкие, расширяешь функциональность DE совершенно бесплатно. Отличия в логике скриптов минимальны, вместо echo в консоль пишешь отправить уведомление в DE при необходимости. Многий софт уже изначально интегрируется в DE. Нужно совсем минимум опыта, чтобы делать универсальные интеграции для ПО, которое будет работать и из консоли и из гуя. Я использую для форматированного вывода информации xterm с консольным браузером и веб-страница позволяет показать информацию намного доходчивее, чем неформатированный выхлоп в эмулятор терминала. А вот TUI расширять это боль ещё та.
Врёшь. А потому скушно. Уведомления ломаются и скрипты долго не живут. Шины меняют...Неопытный ты.
P.S. Покажи репо с твоим кодом скриптов для GUI...
А если жить в бункере на дне Марианской впадины будет ещё безопаснее.
> А если жить в бункере на дне Марианской впадины будет ещё безопаснее.Этого гражданина в безопасники не брать, о том какое давленеи на глубине 11 километров он явно не в курсе был. Или чрезмерно уверен в своих скиллах в сопромате.
Бункеры просто надо нормальные строить и не будет там никакого давления.
> Бункеры просто надо нормальные строить и не будет там никакого давления.Ага. Держащие 1100 килограмм на квадратный сантиметр. Чувак, это больше ТОННЫ на каждый квадратный сантиметр. Сие несколько превышает то с чем готова столкнуться стандартная инженерия бункеров и инженерных систем. Проще базу на Марсе отстроить чем это.
Я и говорю в хорошем бункере и от апокалипсиса укрываться приятно. А Марс это фейк Маска зачем туда лететь.
> Я и говорю в хорошем бункере и от апокалипсиса укрываться приятно.Для этого его сперва построить надо. И при прочих равных, то что люди могут строить структуры в космосе - уже пруфнуто, целым рядом космических станций. То что люди могут строить на глубине 11 километров - прецедентов вроде не было. Это более сложная задача.
> А Марс это фейк Маска зачем туда лететь.
Если мне дать анлимно ресурсов, я предпочту на марсе базу строить, посчитав более реализуемым проектом. Просто потому что строительство в условиях вон того давления это сильно отдельный квест. Более сложный чем строительство в космосе и на поверхности марса. В космосе и на марсе оборудованию и материалам не надо переживать перепад с 1 до 1100 атмосфер, чего доброго еще и несколько раз. Да еще в соленой воде, что крайне плохо для электрики, любая трещинка изоляции ведет к факапу. На марсе электрику не замкнет из-за мизерной трещинки в изоляции. А даже если вдруг - можно попытаться починить. Куда менее рисково чем то же самое но в соленой водичке от и до. И даже какой-нибудь цемент будет относительно нормально работать, а если повезет то удастся на месте делать что-то такое, по технологиям не сильно далеким от существующих земных.
А вот оборудование которое может работать в условиях 1 <-> 1100 атмосфер это такая очень отдельаня штука. Малейшая ошибка в дизайне - и мало что удержит дельту в 1100 атмосфер. Значит при доставке оборудование будет испорчено.
А что не так с давлением? Как известно, подведение кислорода и отведение углекислого газа можно реализовать циркуляцией в лёгких специальной жидкости. Жидкости несжимаемые (на дне Марианской впадины вода сжата всего на пару процентов), значит, особых проблем с циркуляцией не будет. Да, дышать -водой- спецжидкостью тяжело в силу её высокой плотности, чреватой разрывом лёгких, и слабости соответствующих мышц, но это можно решить насосами. Остальное же тело человека ничем не отличается от рыбы в плане сжимаемости, даже комбинезон не нужен (на самом деле нужен, вместо жировой одежды морских теплокровных, но это не от давления, а чтоб не переохладиться)...
Сразу вспомнился фантастический фильм Abyss, на таком принципе там оборудование для сверхглубоководных исследований разработали. (Фонарь лопнул от давления, а человечина всё опускалась на дно :) )
> А что не так с давлением?Всего 1100 атмосфер примерно. Покруче чем жить в трубопроводе высокого давления. Скорее, в гидравлическом прессе.
> Как известно, подведение кислорода и отведение углекислого газа можно реализовать
> циркуляцией в лёгких специальной жидкости. Жидкости несжимаемые (на дне Марианской
> впадины вода сжата всего на пару процентов),Вы на поверхности под давлением 1 атмосферу. И стало быть кроме вон того издевательства вам надо будет пережить еще и просто transient в 1100 атмосфер чтобы уравнять давление в абсолютно всех закоулках вашего тела. В паре с переходом на дыхание жидкостью в какой-то момент в середине этого пути это уже звучит довольно безопасно, что может пойти не так?!
> значит, особых проблем с циркуляцией не будет. Да, дышать -водой- спецжидкостью
> тяжело в силу её высокой плотности, чреватой разрывом лёгких, и слабости
> соответствующих мышц, но это можно решить насосами.Насосы vs безопасно подразумевают что у вас есть чем их питать автономно. Вечные батарейки у вас уже есть? На глубине 11 000 метров с электричеством если что "не очень", подводные кабели на такие глубины не кладут, а генерить в таких условиях по практически всем технологиям... я лучше подпишусь энергоснабжение на Марсе нарулить, это проще.
> Остальное же тело человека ничем не отличается от рыбы в плане сжимаемости,
> даже комбинезон не нужен (на самом деле нужен, вместо жировой одежды морских
> теплокровных, но это не от давления, а чтоб не переохладиться)...При том чтобы не переохладиться этому ихтиандру еще и обогрев понадобится. И там темно как у <афтоамериканца> в <боту не нравятся эти слова>. Значит без электричества вообще ловить нечего. А электричество да в соленой водичке тоже так то безопасно смотрится. Как вы вообще обслуживать залитые соленой водой инженерные системы вознамерились? А без них вы сколько протянете?
По-моему экскурсия на Марс сильно безопаснее. Там по крайней мере условия более человеческие и энергоснабжение нарулить проще и вас не зашибет электричеством при малейшей трещинке в изоляции.
Ты забыл про космическую радиацию.
> Ты забыл про космическую радиацию.Она может быть не настолько страшным фактором как ее малюют и есть хоть какие-то варианты что с этим делать. При этом для конструкционнных работ можно в целом более-менее реюзнуть относительно похожие на земные технологии. А вот строить что-то на 11 километровой глубине... там почти все технологии и оборудование придется с ноля переделывать под эту специфику.
Вы же не построите оборудование сразу на глубине 11 км? Значит появляется требование что это должно переживать транзиент с 1 атмосферы до 1100. Любая полость, трубочка с воздухом или что там - и это порвет и сплющит при спуске на глубину. А всего пара оторваных трубочек или проводков может сделать здоровую машину полностью бесполезной. И вы останетесь без оборудования. Сушествующее оборудование в принципе не создано чтобы переживать такие вещи. Это значительно более злые требования чем допустим в космосе, где самое плохое что может случиться это дельта в одну атмосферу, это разница от земной атмосферы до вакуума. В 1100 раз меньше напрягов для материлов. Мелочи какие.
Поэтому про безопасность на дне марианской впадины кмк тот анонимус чуток погорячился. Во всяком случае я бы посмотрел на безопасное строительство и оперирование такого объекта...
Ой, а вот встроенная в человека система авто-очистки лёгких нифига не рассчитана на жидкость вместо воздуха. Здравствуй, пневмония.
Ты ещё шнур питания предложи вытащить из системного блока.
Давайте ко мне того комментатора, который орал что в стандарте не может быть уязвимостей пусть он отчитывается как так получается что на самом деле бывает.
У тебя лапки? - тут баг в реализации, а не стандарте.
Вот только не надо эту чушь писать когда все сразу взяли и реализовали как в стандарте написано.
Кто все? Там список из одного пункта - Гхостскрипт.
Так никого больше и нет. А символы обрабатываются строго по страндарту. Потому что просто кто-то забыл сделать правильный стандарт.
> когда все сразу взяли и реализовали как в стандарте написано.Ты приведешь ссылку на соответствующий параграф в стандарте, или как обычно?
То что стандарт не описал порядок обработки байтов это недоработка стандарта, а специально это сделано или случайно? Из двух зол выбирают что специально. Можешь убедиться в этом почитав стандарт.
Напомню, что в новости говориться о выходе за пределы буфера. Ты утверждаешь, что это "уязвимость на уровне стандарта" и "в стандарте написано".Ну так не будь пустозвоном, и приведи цитату из стандарта, где написано вылазить за пределы буфера.
> Например, Ghostscript вызывается в процессе создания миниатюр на рабочем столеХрень évince-чего-то-там ещё и жрала память как не в себя. Отключил, запретил обновлять. Клоуны.
в LTS-версиях Ubuntu, нет сырых обнов, там и по сей день апдейты несут только
ghostscript 9.55.0а дыры в свежих версиях ghostscript 10.x.x, в этом и смысл. Привет любителям роллинг-релизов и прочего Arch.
А есть вообще дистрибутивы без этого добра, кроме генту?
А разве есть что то кроме генту?! Кто эти люди сидящие не на генту?!
Люди с личной жизнью.
Ох уж эти единоличники.
В дебиане, установленного через netinstall.iso, c установкой пакетов с --no-install-recommends этого ghostscript нет...
apt-cache policy libgs9
Ахаха, лучшие погромисты опять запутались в вычислении размера+ if (pw->limit - q < 2) {
+ p--;
+ break;
+ }Мегафикс радует как всегда.
Тебе напомнить кто знаки "меньше" и "больше" путает?
Да, напомните, пожалуйста.
> Мегафикс радует как всегда.Хороший пример как не надо писать код. При том не только на си но и вообще.
А что не так???
Выглядит подпоркой.А именно: в коде была нелогичность, отклонение от цели - ошибка. Вместо исправления ошибки написанием кода, чтобы не было ненужного результата совсем, вставлен код реагирующий на ненужное. При этом ненужное всё равно оставлено. Так выглядит.
Впрочем, так делали давно. См. у Стивена Леви, Хакеры, герои компьютерной революции - программа, исправляющая ошибки в программе. Но это не самый высокий класс.
в новости говорится о "символах" и о "байтах". Конечно, если все символы однобайтовые, то может и сойдёт. Но как там обрабатываются тексты в какой-нибудь кодировке UTF-8, где размер одного символа плавает от 1 до 4 байт? Может, конечно, такое кодируют во что-то типа Base-64 и там реально всё только однобайтовое.
MBCS пытались стандартизировать ещё в 90ых. И даже дефайны какие-то придумали. Но проверять вот это вот всё - реально лень. Я тоже пишу код под ANSI или средствами платформы, которым всё равно на кодировку. Но вообще - строки это всегда боль.
Офигенная закладка!
Изначальный код был добавлен 2015-07-20. После этого было пару коммитов со сменой дат и всё))
Целых семь лет с оценкой 10 из 10! Да еще единой реализацией практически во всех линуксах.
И с готовым прототип эксплоита. А самое главное - фиг докажешь что не закладка.
Прям мечта майора Джона))
> Офигенная закладка!
> фиг докажешь что не закладка.Ясно, понятно...
> Офигенная закладка!А ты не допускаешь, что это просто сишники обделались в миллиардпервый раз?
sed 's/сишники/people/g'Обычная тема, зачем нужна автоматизация - снижение % брака.
Ты ж понимаешь что и то, и другое нефальсифицируемо.
Могли сишники обделаться как обычно, а могли замаскировать злой умысел под это.
И после всяких призм и тд простой бритовой не обойдешься.А могли обделаться как обычно, но кто нужно уже годами используют.
Тоже не докажешь и не опровергнешь.Вот если бы такие ошибки в си были бы редкостью... но не будем мечтать о невозможном.
Обделаться не может только тот, кто ничего не делает.
Учитывая количество софта на сях в сравнении со всяким хипстерьём - ну, вы поняли.
> Обделаться не может только тот, кто ничего не делает.Или тот, который использует недоязык и не делает выводов, из года в год наступая на те же грабли.
Это те, кто уже прошли путь от рубей до хруста?
> Учитывая количество софта на сяхОсталось понять, где связь с количеством софта на сях и конкретно этим багом.
Сишники с рождения, как вы выражаетесь, "обделанные" - даже в стандартной библиотеке не смогли сами с собой договориться, нужен \0 в конце строки или нет.
strncpy vs strncat
Не видишь логики в strncpy?
Сочувствую.
-> на гошечку
> СочувствуюА ты видишь логику в том, что strncpy при определенных условиях не добавляет ноль? Расскажи, было бы интересно почитать.
> А ты видишь логику в том, что strncpy при определенных условиях не
> добавляет ноль? Расскажи, было бы интересно почитать.Ладно, так и быть.
Есть у тебя "Black cat went up the alley".
Тебе надо "cat" на "dog" заменить, имея поинтер.
Как считаешь, если strncpy будет всегда \0 добавлять - получится?
В таком случае ты бы пользовался memcpy().
Немножко семантически криво получится, не так ли?
Да нет, это как раз прямо выразит твои намерения.
Теперь второй пример. У тебя есть "I am a f****ng rUST programmer"
Нам бы надо заменить "programmer" на "fanatic", но следов от него в виде "er" - не оставлять.
Как считаешь, справится strncpy с задачей?
> Как считаешь, справится strncpy с задачей?Может справится, а может и нет - в зависимости от того, как ты напишешь вызов. Приведи пример кода.
Неправильный ответ.
Правильный ответ - справится. И даже нулями забьёт лишнее, как и договаривались.
Это правильный ответ. Ты можешь ошибиться с вызовом strncpy так же, как и сотни тысяч людей до тебя. Поэтому приведи пример вызова для этой задачи - вот тогда и посмотрим.
А теперь объясняю логику.strncpy реально работает с терминатором (и переменной длиной) _только_ в src.
dst при этом является "сырым буфером", и \0 в src для strncpy - всего лишь символ, указывающий, что с src пора завязывать.
То, что ты объяснил - это не логика, а нелепо спроектированное поведение, с которым запросто можно выстрелить себе в ногу и получить ровно то, о чем говорится в новости.Даже man рекомендует использовать вместо него нестандартный strlcpy.
Для тебя - нелепо, мне - норм. И выстрелить себе в ногу там не так просто, если вовремя написания мозг включать, конечно же.
- во время -
Основные выстрелы в ногу встречаются как раз не там.
Основные выстрелы в ногу встречаются там, где забыли проверку длин этих самых буферов или в ней накосячили.
С увеличением числа излишне высокоуровневых лепил, которые забывают, что машине фиолетово, сколько ты там куда запишешь - ты сам должен думать об этом, число таких выстрелов будет неизбежно расти.
> С увеличением числа излишне высокоуровневых лепил"Высокоуровневые лепилы" в принципе таких нелепых ошибок не допускают, потому что пользуются адекватными интсрументами.
> инТСРУментами.Так и запишем, не допускают ошибок.
Так и запишем, не допускают ошибок. Адекватными, простите, чем - и что вы с ними делаете?
посочуствуй ещё, чувствительный наш.
в strncpy логику нашли, давай искать в strncat
А с strncat-то что у тебя?
Вот уж действительно, показательный пример.
Человек, который сам не может банально прочитать доку и увидеть разницу в поведении двух функций (причём на которую было указано изначально) советует другим "идти в гошечку".
Слепая любовь, что тут ещё сказать.
Хосспаде, родной, тебя смущает разница в поведении вызовов? RTFM.
И в том, и в другом поведении есть своя логика.
Но любителям зачёсывать и круглое и треугольное под квадратное - да, мимо.
> И в том, и в другом поведении есть своя логика.
> Но любителям зачёсывать и круглое и треугольное под квадратное - да, мимо.Да, я люблю, когда функции именуются правильно, чтобы название отражало суть, а не так вот "наот====сь".
Люби, кто тебе мешает.
Просто не лезь туда, где тебе не понятно.
strncat используется для объединения двух строк переменной длины с терминатором, он выполняет предварительный поиск терминатора в dst, чтобы понять, куда добавлять. И src и dst трактуются как терминированные строки, поэтому и на выходе - терминированная строка.
Всё это написано в учебнике. Только пишут ли там про то, что ты сам должен просчитать пространство для результирующей строки?
И в процессе этого рассчёта получаешь значение, которое делает конкретно *cat функцию избыточной.
Ну а если делать strncat наобум - то всё это заканчивается выходом за пределы буфера.Если выделяешь новый буфер, нужно два strlen, и потом можно сделать просто два memcpy. strncat не нужен.
Если дописываешь в первую строку, надо делать strlen, чтобы определить сколько вообще места осталось.
И опять-таки можно использовать strncpy на буфер+длину из первого вызова - снова strncat не нужен.В общем, по всем фронтам лишняя функция. Ну а если использовать её наобум - получится очередной gets.
Либо тупо заводить буфер размером максимальная длина строки*количество складываемых строк.
> И в процессе этого рассчёта получаешь значение, которое делает конкретно *cat функцию
> избыточной.Расчёта.
Кроме того, буферы могут быть фиксированной длины - если допускается обрезка результата. Тогда ничего считать не надо. Либо длина заранее известна. И тогда тоже ничего считать не надо.
Но да, высокоуровневые япшечки от тебя всё это скрывают, поэтому ты даже не предполагаешь наличия таких вариантов.
> strncat используется для объединения двух строк переменной длины с терминатором, он выполняет
> предварительный поиск терминатора в dst, чтобы понять, куда добавлять. И src
> и dst трактуются как терминированные строки, поэтому и на выходе -
> терминированная строка.А у strncpy трактуются как-то по-другому?
Внезапно да. RTFM, не вижу смысла в слепоглухонемом споре.
> Внезапно да. RTFM, не вижу смысла в слепоглухонемом споре.Вот уж действительно, спорить о C с человеком, который чуть что сбегает в PHP...
Если мне нужен свервысокий уровень - я бегу в PHP.
Если мне нужно очень быстро и с памятью - я беру C или плюсы.
Если нужна серебряная пуля - я тащу в PHP тот самый модуль на сях.
(к счастью, пых изначально делался заматеревшими гошниками, и притащить туда то, что тебе нужно на подложке - вопрос пары часов)
Тьфу блин, гошниками, сишниками.
Пытаться делать ВСЁ на одной моднявке (привет гошечка), даже то, для чего она не приспособлена - ну такое.
Ну так не делай. Только это очень странно, не пользоваться и при этом нахваливать, а тем, кто пользуется заявлять что это "не их".
Ага, тот самый мануал, который советует использовать strlcpy именно из-за упоротого поведения strncpy. Но опеннетным экспертам не страшно - они-то все понимают, на асме строками ворочали...
В каком стандарте у нас есть strlcpy?
Без BSD_SOURCE везде соберётся?
Што нащёт визуал студии?
Всю эту сишную логику можно понять только после того, как ты на асме занимался строковыми операциями.
Если глубже высокоуровневых примитивов мышление не заглядывало, да - логику увидеть бывает сложновато.
Какой-то стокгольмский синдром по отношнию к недотехнологиям. Смешно, как у некоторых сишников подгорает от того, что кто-то может просто сложить две строки плюсиком - не роняя память, не ошибаясь с размером буфера, не вылазя за его пределы.
Ты с трудом понимаешь, что такое "буфер", отсюда и вот это вот недоразумение.
Чтобы две строки "плюсиком" сложить в разных этих вот всяких тебе придётся целую аллокацию нового буфера насиловать. Когда у тебя набуизнесс-логика, которая может полчаса ворочаться при сложении трёх томов войны и мира - да, дело одно. А когда у тебя системная подложка, которая вынуждена работать быстро, иначе ты вместо полчаса три часа получишь - дело другое.
А чтобы сложить в сях "не плюсиком", аллокацию типа не надо делать?
> А чтобы сложить в сях "не плюсиком", аллокацию типа не надо делать?У каждого сишника есть свой набор нормальных функций работы со строками)
В конечном счёте приходишь к структу в котором лежит размер буфера, текущая длина и сама строка... может и что-то ещё по вкусу.
Потому что если если не держать это в структе придётся держать где-то отдельно.
А если это всё не делать, получится очередной gets
Если у тебя буфер целевой строки превышает по размеру обе-двое - зачем?
А буфер целевой строки аллоцировать не надо? Речь о сложении, а не о добавлении к существующей.Но даже если говорить о сложении: ты же в курсе, что во всех нормальных языках строковый буфер действительно аллоцируется размером чуть больше, чем необходимо - как раз для описываемой тобой ситуации. Плюс еще есть оптимизация коротких строк.
А в сишечных str*() - шишь. Считай размер ручками, аллоцируй/удаляй ручками, дергай strlen на каждый чих (производительность, да) - и смотри не обделайся. Абстракции для дураков ведь. А сишечка лучше мерзкого Раста, ага.
Вобщем, эта дискуссия вполне закономерно превратилась в цирк.
Если мне из всех строк нужна только сложенная и размер dst позволяет - зачем мне третий буфер? Мне заняться нечем?Ну и да, ся - оно такое. Дёргай много чего сам, как тебе нужно, а не как за тебя очередная хипстота решила. Цирк - это когда жаваскриптеры в си лезут.
На входе мне пришли допустим 6 строк, ага. Длины уже известны.
Мне их надо в одну сложить частями. На каждое сложение отдельную аллокацию делать? Смешные.
(ключевые заголовки SIP разбираем, ага)
Дадад, эту логику могут понять только избранные.
Нельзя просто сказать - не додумали, ошиблись?
Гордость не позволяет? Или просто понты от глупости?
strncat, кстати, вообще в целом бесполезная функция - прежде чем её вызывать, надо знать, сколько у тебя уже есть строки в буфере, чтобы посчитать, сколько можно дописать - а если ты эту длину знаешь, смысл какой-то cat делать если можно просто эту длину к указателю добавить.
И что касается ассемблера, на RISC архитектурах (где регистров до жопы и нет проблем выделить один под счётчик) сишные строки теряют все свои преимущества перед паскаль-стайл.Вообще вся stdlib всратая, даже сраный popen чтоб был без шелл прокладки и с нормальной передачей аргументов приходится копировать хрен знает откуда и фиксить чтобы оно нормально работало.
> Нельзя просто сказать - не додумали, ошиблись?Нельзя. Потому что никто не ошибался, просто ты отказываешься понимать смысл работы.
> Вообще вся stdlib всратаяВот с этого и надо было начинать. C - не твоё :D
Делай как я - выбирай дуализм. Для высокоуровневого - PHP, он как раз всё это обвязывает и скрывает много тонкостей. А вот критичные и системные участки - на C.
(естественно именно в похапэ тебя никто силком не тащит, щито угодно. мой выбор основан на схожести кода, не требуется какой-либо зубодробительный синтаксис очередной однодневки изучать. да, с названиями там такая же жесть, как и в сях)
Ну так надо что-то регулярно портить и героически исправлять. Иначе скажут проект мёртв и грохнут репу.
Это ж кто же мог подумать что с си бывают экранировнные символы и они занимают целых два симовола!
Наверное нужно быть синьйором с 30+летним опытом написание на си чтобы знать этот ньюанс!
но-но! не приуменьшай их способности: зато они знают 14 вариантов инициализации!
и 5 способов каста к void* для самой быстрой порчи памяти!
Это с++ники знают. С си все более уныло.
погодите а UTF8, UTF16 отменили? там же изначально по несколько байт на символ
Скорее что: применили слишком недавно...
Ну как бы clang предупреждает о них. А кто пользуется gcc - тот сам себе злобный буратино.
Шланг явно что-то знал.
Но гнутый ни в чём не виноват.
> Ну как бы clang предупреждает о них. А кто пользуется gcc -
> тот сам себе злобный буратино.Современные gcc и clang выдают примерно одинаковые предупреждения, не надо сказок. Проблема с сями в том что есть ряд случаев когда статический анализ не поймает некоторые вещи.
ghostscript - это традиционный уязвимостейдром. Его не починить, только выкинуть. Благо, что есть pdfbox без сишных дыреней. Чтобы не выкидывать весь софт, зависящий шт GhostScript, нужно сделать совместимое API, но чтобы под капотом был или pdfbox, или что-нибудь на расте, или pdf.js, или проприетарный Foxit.
Всё что ты назвал ещё хуже.
>— Чем же хуже?
>— Чем GhostScript.Ясно.
> или проприетарный FoxitСкажешь тоже! Там багов ещё больше, если целенаправленно покопаться, поскольку разрабатывают его китайцы, если кто не знал. https://en.wikipedia.org/wiki/Foxit_Software
Обработчиков PDF вообще не существует идеальных, слишком уж сложна реализация всех фич. Но чем популярнее решение, тем пристальнее в нём будут искать и исправлять баги. Так что, Ghostscript ещё очень неплох, если сравнивать с альтернативами.
>поскольку разрабатывают его китайцы, если кто не знал. https://en.wikipedia.org/wiki/Foxit_SoftwareКитайцы-не китайцы, но это лучшая реализация PDF из известных, даже гугл у них лицензирует для своего хрома. При этом компания зародилась и поднялась тогда, когда вставлять бэкдоры было позорным. Я подозреваю, что эта компания срать себе в карму не будет. Уязвимости в фоксите обычно в JS-API. Отключи JS и спи спокойно.
P.S. в mupdf JS вообще неотключаем.
> P.S. в mupdf JS вообще неотключаем.Ну-ну
% pkg options mupdf
mupdf - DOCS: on
mupdf - JS: off
mupdf - SCROLL: on
Ага безопасность закрыть глаза и не видеть опасности. Удалить антивирус и говорить что у тебя нет вирусов. Использовать проприетарный продукт который невозможно проверить и говорить как же там все безопасно просто смешно.
Существует. Адобовский. Идеальнее не бывает, потому что это собственно разработчики формата :D
> ********** вызывается в процессе создания миниатюр на рабочем столе, при фоновой индексации данных и при преобразовании изображений. Для успешной атаки во многих случаях достаточно просто загрузить файл с эксплоитом или просмотреть каталог с ним в Nautilus.Это относится ко всем графическим либам.
А разрабам десктопов сколько не говори так не делать, а они все равно иконки рисуют на основе содержимого.
О безопасности в этом месте не думает ги один десктоп.
C in CVE stands for C language!
Можно ли отключить Ghostscript в Nautilus?
"Уязвимости присвоен максимальный уровень опасности (10 из 10)"Red Hat:
Priority: medium
Severity: medium
:)
Вероятность ошибки растёт со сложностью системы. Сложность PS просто зашкаливает.
Ничего, сейчас всё на хрусте перепишут. Поддерживать будет 0.1% от спецификации, при этом жрать в 10 раз больше памяти и работать в 10 раз медленнее, но зато безопасТно.