GTK2-NG: форк библиотеки GTK2

Топология типа сигнала. Когда сервер посылает сообщение нескольким клиентам.

Вроде всегда лучше к каждому отдельно подключиться.

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

Логика та же, что для программ в браузере

Т.е. каждой программе, в такой логике, предлагается писать свой собственый html/DOM/CSS парсер (для этого предварительно стандартизировав эти самые html/DOM/CSS).

А если последние 5 строк теперь в другом порядке?

Смысл в том, что мы ВИДИМ и ЗНАЕМ, что это строки. X послал описанную структуру, Y - гарантировано получил эту-же самую структуру (ну или ошибку). И никого из них не парит, каким образом это произошло, хоть в конверте почтовым голубем от руки переписано.

лол, да в этой теме прямо внезапный прорыв бездарей, которые пытаются скрыть за бессмысленными терминами свою неспособность писать нормальный софт.

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

Особенно порадовал чудик с sd-dbus. Эта во-первых библиотека с адски сильно связанным говнокодом (как в общем и весь сустемд), во-вторых дыбас на сишке - само по себе нонсенс. Оно изначально создавалось, чтобы не парсить всякие бинарные протоколы на шелле, начнем с того что.

Тогда вот: https://github.com/haiwen/libsearpc

man searpc-codegen

Ну что за детский сад то опять. :)

Почти всегда полнофункциональный RPC с произвольными функциями не требуется.

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

А какой-нибудь libmysqlclient на RPC D-Bus я с ужасом представляю.

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

В таком случае, тебе надо иметь и хранить где-то внутри себя список, а кто эти «отдельные».

Так это список соединений. Он всё равно где-то есть. А что-то разослать всем надо только если в программе есть что-то типа подписки на события.

Т.е. каждой программе, в такой логике, предлагается писать свой собственый html/DOM/CSS парсер

Нет. Использовать Gtk напрямую. И для обмена простыми данными без иерархии использовать простые строки, а не JSON или XML.

Смысл в том, что мы ВИДИМ и ЗНАЕМ, что это строки. X послал описанную структуру, Y - гарантировано получил эту-же самую структуру (ну или ошибку). И никого из них не парит, каким образом это произошло, хоть в конверте почтовым голубем от руки переписано.

А так мы видим и знаем, что это какая-то строка с данными. Как именно их трактовать определяется уровнем выше (также, как правила разбора дат, например).

И использование браузера d-bus ограничивает программу форматами d-bus. Как через d-bus описать тип printf? Или хотя бы как сделать команду, которая первым аргументом принимает число и если оно 0, тогда второй аргумент строка, а если 1, то ещё два аргумента int128?

Да вас никто и не заставляет им пользоваться.

Тут в комментариях были призывы всё стандартизировать и унифицировать. Так что заставляют, хоть и мягко.

Так-то да, кто-то пишет RPС на D-Bus, кто-то интерфейс на Электроне, кто-то вместо библиотеки делает контейнер Docker… Если мне нужно это приложение и ресурсов на компьютере достаточно, то всё равно буду использовать. Если есть выбор, не буду.

Так это список соединений. Он всё равно где-то есть.

Т.е. мне опять сношаться самому.

И для обмена простыми данными без иерархии использовать простые строки

Дальше ping-pong чатика с этим начнутся проблемы. Какой-никакой, а протокол сериализации/маршаллинга данных придумать придётся.

Как через d-bus описать тип printf? Или хотя бы как сделать команду, которая первым аргументом принимает число и если оно 0, тогда второй аргумент строка, а если 1, то ещё два аргумента int128?

Не распарсил, что такое тип printf, но вообще тип VARIANT никто не отменял.

Тут в комментариях были призывы всё стандартизировать и унифицировать.

Смотря что, и для чего. Подход дбас хорош для общесистемной шины с кучей демонов, так как позволяет делать аудит. Но если вы пишете какую-то фитюльку, так сиарпц вполне хватит: там и так есть «стандартизированный» джисон, а аудит или сложный роутинг вам не нужны. Главное, что гонять рав строки через сокет - такое предлагаете только вы. А зачем? сиарпц достаточно легковесный.

кто-то вместо библиотеки делает контейнер Docker…

Для изоляции, видимо.

https://wiki.inkscape.org/wiki/Release_notes/1.4

These Release Notes are only a draft.

Find the finalized release notes at https://inkscape.org/doc/release_notes/1.4/Inkscape_1.4.html

Т.е. мне опять сношаться самому.

Попроси ИИ, он за тебя программу напишет.

Не распарсил, что такое тип printf, но вообще тип VARIANT никто не отменял.

Когда значение первого аргумента определяет типы следующих.

Плюсую. Я, когда курил этот ваш OpenGL, думал, что это треш и угар. Однако всё познаётся в сравнении. Пришла пора курнуть Вулкан. Это кошмар, господа.

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

Это вообще что такое (d-bus audit не яндексится)?

Главное, что гонять рав строки через сокет - такое предлагаете только вы. А зачем? сиарпц достаточно легковесный.

Если что-то можно использовать, а можно не использовать, то зачем использовать? Если команды достаточно просты, чтобы их прочитать через scanf, зачем сиарпц?

сиарпц достаточно легковесный.

Он не работает без глиб и гобъект, а это несколько мегабайтов.

Для изоляции, видимо.

Скорее для фиксации зависимостей, чтобы не зависеть от библиотеки, установленной пакетным менеджером. А потом выходит обновление безопасности, а в докерах остаётся дырявая версия.

Это вообще что такое (d-bus audit не яндексится)?

Ну вот, например, здесь: https://dbus.freedesktop.org/doc/dbus-daemon.1.html можно глянуть, как это с аппармором стыкуется. А именно:

The AppArmor confinement context is stored when applications
connect to the bus. The confinement context consists of a label
and a confinement mode. When a security decision is required, the
daemon uses the confinement context to query the AppArmor policy
to determine if the action should be allowed or denied and if the
action should be audited.

И далее по тексту.

Можно просто политики енфорсить, при чём, на уровне интерфейсов и методов, а не на уровне транспорта. И в этом вся фишка: аудит может глядеть на более верхние уровни. Он их понимает, благодаря общей спеке.

Если команды достаточно просты, чтобы их прочитать через scanf, зачем сиарпц?

А что значит, просты? Ну сейчас 2 команды, а завтра - 22. Сейчас вы инт из обеих возвращаете, а завтра вам потребуется возврат сложных структур. До чего ваши сканфы разрастутся? А главное, зачем? Если решения и так уже есть.

Он не работает без глиб и гобъект, а это несколько мегабайтов.

Увы. Легковесность, конечно, я не в мегабайтах измеряю, а в накладных расходах на производительность. Но тем не менее, да, вот такие зависиомсти. Ещё джансон тянет для джейсона.

Можно просто политики енфорсить, при чём, на уровне интерфейсов и методов, а не на уровне транспорта. И в этом вся фишка: аудит может глядеть на более верхние уровни. Он их понимает, благодаря общей спеке.

С файлами в /var/run то же самое можно. Если нужны разные права на интерфейсы/методы, они просто делаются через разные файлы.

А что значит, просты? Ну сейчас 2 команды, а завтра - 22. Сейчас вы инт из обеих возвращаете, а завтра вам потребуется возврат сложных структур.

Вы на даче всегда дом строите на плитном фундаменте? Ведь сейчас 2 этажа, а завтра - 22.

Если вдруг приложение настолько изменится, то можно и дописать API на более сложное. Зачем заранее?

До чего ваши сканфы разрастутся? А главное, зачем? Если решения и так уже есть.

Поэтому надо сразу взять готовое решение, разросшееся на несколько мегабайт. Логично.

К слову, как в d-bus сделать команду, которая первым аргументом принимает число и если оно 0, тогда второй аргумент строка, а если 1, то ещё два аргумента с типом int128?

На строках тривиально: читаем первый байт, если 0 читаем байты пока не встретится 0 (это строка), если 1, читаем два блока по 16 байт (это два числа).

Если нужны разные права на интерфейсы/методы, они просто делаются через разные файлы.

Как, в такой схеме, обеспечить аудит параметров? Например, к вам пришёл запрос, в котором тип «строка», а значение 1. Если такой запрос не отфильтровать, сервис крашнется, или будет взломан.

Если вдруг приложение настолько изменится, то можно и дописать API на более сложное.

При чём здесь АПИ? Вам маршаллеры писать придётся постоянно.

Поэтому надо сразу взять готовое решение, разросшееся на несколько мегабайт.

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

К слову, как в d-bus сделать команду, которая первым аргументом принимает число и если оно 0, тогда второй аргумент строка, а если 1, то ещё два аргумента с типом int128?

В смысле, команду? Можно передавать варианты, но число параметров фиксировано, насколько мне известно. При этом, аудировать варианты тоже сложнее, так что лучше этого просто не делать.

На строках тривиально: читаем первый байт, если 0 читаем байты пока не встретится 0 (это строка), если 1, читаем два блока по 16 байт (это два числа).

А потом вам строку так сформируют, что ваш парсер обратится куда-то «не туда», с соотв результатом. Вы будете тратить на развитие парсера больше усилий, чем на кодинг функционала.

Вы на даче всегда дом строите на плитном фундаменте? Ведь сейчас 2 этажа, а завтра - 22.

Давайте начнём с вопроса по-проще: а зачем вам вообще рпц? Вы всё время указываете на то, что у вас какая-то мелкая фитюлина, без требований к масштабированию и безопасности.

Так, может, вам просто рпц в ней не нужен? Может, она и в 1м процессе отлично работает?

Как, в такой схеме, обеспечить аудит параметров? Например, к вам пришёл запрос, в котором тип «строка», а значение 1. Если такой запрос не отфильтровать, сервис крашнется, или будет взломан.

А apparmor от этого защищает? Как?

В случае файлов технически нельзя ничего передать кроме строки. Твоё 1 будет или символ с номером 1 или строка с значением «1». Программа на основании значения будет реагировать.

При чём здесь АПИ? Вам маршаллеры писать придётся постоянно.

Почему постоянно? Один раз при появлении иерархических данных.

Ну возьмите санрпц глибсовый.

А смысл? Он нужен для общения по сети. Для локальной программы portmap не нужен, наличие сокета через ls видно. Описание формата через XDR нужно, если клиент планирует генерировать клиент на своём языке. Если API более-менее сложное, логичнее просто libmyprogclient сделать. Заодно изменение бинарного формата (при переходе вдруг от start 1 2 к {"command": "start", "number": 1, "row": 2}) будет прозрачным.

В смысле, команду?

То, что в DBus методом называется.

При этом, аудировать варианты тоже сложнее, так что лучше этого просто не делать.

Ну вот. Мало того, что надо несколько мегабайтов зависимостей добавить, так оно ещё и работает только в тривиальных случаях.

А потом вам строку так сформируют, что ваш парсер обратится куда-то «не туда», с соотв результатом.

Куда?

Парсер детерминированный. Если ошибочные данные (нет 0 в строке после 0 или нет 16 байт после 1), они будут отброшены.

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

Шутите? В самом худшем случае, при котором D-Bus ещё работает, туда прикручивается парсер JSON. Если парсер требуется ещё более сложный (например, пользователь может писать скрипты на bash в качестве команд), то d-bus уже вообще никак не поможет.

Давайте начнём с вопроса по-проще: а зачем вам вообще рпц? Вы всё время указываете на то, что у вас какая-то мелкая фитюлина, без требований к масштабированию и безопасности.

Наоборот же. С требованиями по адекватной работе в chroot и с возможностью работы через файл в каталоге пользователя (с индивидуальными настройками для каждого пользователя).

Так, может, вам просто рпц в ней не нужен? Может, она и в 1м процессе отлично работает?

Нужен канал, через который пользователь или другие программы могут отправлять команды и получать информацию. Может рпц не нужен. Это всё про стандартизировать и унифицировать, то есть канал обязательно на дбас.

А apparmor от этого защищает? Как?

Что за хрень, при чём тут аппармор? От этого защищает dbus-daemon. Аппармор не являлся в том примере аудитором, он свои контексты лепил к сообщению, чтобы аудитор посмотрел.

Почему постоянно? Один раз при появлении иерархических данных.

Либо иерархические данные появляются всего 1 раз, либо они всегда одинаковые? Ну, может у вас и так…

Для локальной программы portmap не нужен

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

Мало того, что надо несколько мегабайтов зависимостей добавить, так оно ещё и работает только в тривиальных случаях.

Если у вас всё, что не варарг - то тривиальный случай, ну окей. А так-то вообще люди не тащат подобное дерьмо в RPC.

В самом худшем случае, при котором D-Bus ещё работает, туда прикручивается парсер JSON. Если парсер требуется ещё более сложный (например, пользователь может писать скрипты на bash в качестве команд), то d-bus уже вообще никак не поможет.

Чего у вас за мешанина в голове? В джисон делается сериализация, хоть скриптов, хоть чего угодно. Парсер джисона проверит валидность джисона, а аудитор шины проверит валидность всех передаваемых параметров. Это совершенно независимые проверки на разных уровнях.

К слову, как в d-bus сделать команду, которая первым аргументом принимает число и если оно 0, тогда второй аргумент строка, а если 1, то ещё два аргумента с типом int128?

На самом деле, никакой проблемы тут нет. Передаёте 4 аргумента. Просто иногда будет пустая строка, а иногда - нулевые инты. Делов то!

Порт GTK 1.3 на Windows 11

Что за хрень, при чём тут аппармор? От этого защищает dbus-daemon

То есть парсер. Который в общем случае не обязательно запихивать в отдельный демон.

Либо иерархические данные появляются всего 1 раз, либо они всегда одинаковые? Ну, может у вас и так…

В смысле? Пока их нет, используем scanf. Как появились, используем JSON. Если появились связанные данные, используем интерпретатор. Но переход однократен и не зависит от количества команд, предоставляемых через API.

Если у вас всё, что не варарг - то тривиальный случай, ну окей.

Ладно, как хотя бы аргумент int128 описать?

А так-то вообще люди не тащат подобное дерьмо в RPC.

https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_com_query.html

а аудитор шины проверит валидность всех передаваемых параметров

В аудитор шины можно запихнуть условия на допустимые значения чисел и строк? Или только отличие строки от числа проверит?

Передаёте 4 аргумента. Просто иногда будет пустая строка, а иногда - нулевые инты. Делов то!

И проверять всё равно вручную. И вместо 33 байтов получать в два раза больше.

То есть парсер. Который в общем случае не обязательно запихивать в отдельный демон.

Есть такая штука - шаред библиотека. Её можно одновременно хоть в 100 процессов закинуть, и накладные расходы практически не возрастут. А в демоне делать проверки всё таки лучше, так как это - отдельный контур безопасности, написанный, типа, экспертами безопасности, которым мы доверяем. :) Ну так принято, не я придумал.

В смысле? Пока их нет, используем scanf. Как появились, используем JSON.

Ну хорошо, если вы так кодите - это ваш выбор. Сначала делаете на коленке, потом уже - как все люди. Это уже вопрос личных предпочтений.

Ладно, как хотя бы аргумент int128 описать?

Видимо, как 2 параметра, или как массив. Но ваш вопрос понятен: в стандартный аудитор это не затащить. Если вам надо аудировать всякие нестандартные вещи, придётся писать политику для полкита.

В аудитор шины можно запихнуть условия на допустимые значения чисел и строк? Или только отличие строки от числа проверит?

Можно задействовать полкит. Но это изврат и тормоза. Думаю, сложную логику проще пока проверять самому. То, что вы хотите - сделано в КасперскийОС. Там политики на RPC могут проверять абсолютно всё, что угодно, и с любой кастомной логикой. Там целый мета-язык для этого создан.

И проверять всё равно вручную. И вместо 33 байтов получать в два раза больше.

Ну, как бы, да. :) дбас пока в КасперскийБАС не переделали.

Есть такая штука - шаред библиотека.

Я про неё же.

написанный, типа, экспертами безопасности, которым мы доверяем

Так какая разница, запихивать в отдельный демон, написанную, типа, экспертами безопасности, которым мы доверяем, библиотеку или просто запускать её функции.

А в демоне делать проверки всё таки лучше

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

Сначала делаете на коленке, потом уже - как все люди.

Не на коленке, а с минимумом зависмостей для данного результат. Есть такие принципы: YAGNI и KISS. В UNIX активно применялись, в линуксе в последние годы, похоже, считают их устаревшими.

Но ваш вопрос понятен: в стандартный аудитор это не затащить. Если вам надо аудировать всякие нестандартные вещи, придётся писать политику для полкита.

Э… А обычная программа имеет право добавлять туда политики?

Ну, как бы, да. :) дбас пока в КасперскийБАС не переделали.

Тот подход более логичен. А с дбас применение автоматически урезает возможные сообщения, если не брать с дбас просто строку или массив байтов и не парсить отдельно, но тогда его смысл вообще теряется. И возможные проверки строго ограничены.

Так какая разница, запихивать в отдельный демон, написанную, типа, экспертами безопасности, которым мы доверяем, библиотеку или просто запускать её функции.

Гигантская. Мало ли какие в вашем процессе мемори коррупшены происходят, или как криво вы эту библиотеку вызываете? В вашем процессе она как раз не даст повышения безопасности.

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

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

Если бы вы сделали у каждого свой демон парсинга, то, кроме увеличения накладных расходов, ничего бы не получили: если в либе есть уязвимость, то весь зоопарк будет одинаково уязвим. Так что лучше уж 1. Но отдельно от вашего глючного кода… Либо НЕ отдельно - тогда сиарпц.

Есть такие принципы: YAGNI и KISS. В UNIX активно применялись, в линуксе в последние годы, похоже, считают их устаревшими.

Просто их определение эволюционировало в стороне от вас. И сейчас, если ваш код прост и понятен, но, в качестве платы за простоту, тянет кучу библиотек - это всё ещё (теперь) считается KISS. А какой-то парсер на сканфах рукописный - давно уже не KISS, даже если вы сэкономили на зависимостях.

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

Э… А обычная программа имеет право добавлять туда политики?

Программа не пишет политики. Это фундаментальный принцип, насколько мне известно. Иначе, дырявая программа такого бы себе понаписала…

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

Вот только не надо варарги приводить как пример некоего вселенского урезания. Он, во первых, никому не нужен в RPC, а во вторых, в большинстве случаев решается добавлением аргументов (пускай иногда пустых), либо, что куда лучше - просто добавлением функций. Гораздо лучше, когда у вас отдельные функции отвечают за фиксированный сет аргументов - никто в рпц не станет небезопасный варарг затаскивать. Что вам мешает проверить ваш флаг ещё на клиенте, и вызвать 1 из 2 функций, и не городить людям геморрой на пустом месте?

И возможные проверки строго ограничены.

Ну, это просто виток эволюции такой. Доделают. Главное - идти в этом направлении, а не говорить «ой, мне не дали варарг - я всех пошлю и накидаю сканфов». Так прогресс не продвинуть. :)

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

Чем вам cjson и searpc более нормальны, чем glibc? Если речь про неправильное использование scanf, так в Си что угодно можно не так использовать, даже клиентскую библиотеку d-bus.

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

Уязвимость почти всегда требует определённого сочетания параметров. Например, в scanf есть уязвимость, если его использовать с параметром %s. Если в программе этот параметр не используется, то уязвимости нет. Но если будет общий демон, работающий через передачу ему форматной строки scanf, то одного приложения с форматной строкой с %s хватит для полного контроля демона (и передаче всем приложениям чего угодно).

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

Если «в качестве платы за простоту, тянет кучу библиотек», то надо проаудировать все эти библиотеки. Ладно, принимается как аргумент в пользу d-bus (часть системы линукс, значит если уязвимость есть, то всё поломают безотносительно твоей программы), но не searpc.

Это фундаментальный принцип, насколько мне известно. Иначе, дырявая программа такого бы себе понаписала

То есть всё равно все нормальные проверки делать внутри программы. Значит толку от этих примитивных дополнительных проверок нет.

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

Я же пример привёл. https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_com_query.html Как этот метод описать на D-Bus?

либо, что куда лучше - просто добавлением функций

На каждую возможную комбинацию аргументов com_query по функции? Для 5 аргументов будет порядка 10 тысяч функций. D-Bus не помрёт?

Доделают. Главное - идти в этом направлении

Можно. Но зачем?

Так прогресс не продвинуть

Так если прогибаться под то, что есть, то точно не продвинуть. Вот кто-нибудь достаточно упоротый решит для «стандартизовать и унифицировать» перенести RPC Mysql на D-Bus, так прогресс и продвинет.

Чем вам cjson и searpc более нормальны

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

Но если будет общий демон, работающий через передачу ему форматной строки scanf

По тому этого и не будет никогда.

то надо проаудировать все эти библиотеки.

Но не вам, а их авторам.

То есть всё равно все нормальные проверки делать внутри программы. Значит толку от этих примитивных дополнительных проверок нет.

Почему нет? Вам провалидировали запрос относительно пермишнов аппармор. Вам провалидировали на соответствие типов и значений. Тонкую валидацию параметров - пока не завезли, но и то, что есть - уже не мало.

Я же пример привёл.

А зачем? Сколько лет вашему примеру? Мало ли что до нас из глубокой древности дойти могло, может где и динозавр до сих пор обитает. :)

На каждую возможную комбинацию аргументов com_query по функции?

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

Можно. Но зачем?

Я же уже привёл пример Касперского. Вы сказали, норм. А теперь опять «зачем»? Что за метания?

Вот кто-нибудь достаточно упоротый решит для «стандартизовать и унифицировать» перенести RPC Mysql на D-Bus, так прогресс и продвинет.

Это будет последнее, что он продвинет. В 1ю очередь, он получит порцию отборного мата от Поттеринга, и заниматься ерундой сразу перестанет.

Но не вам, а их авторам.

Тому, кто будет использовать мою программу. Или мне, если вдруг ответственность за безопасность лежит на мне. Или авторы дбас уже согласны платить за ущерб от дыр в их поделке?

Тонкую валидацию параметров - пока не завезли, но и то, что есть - уже не мало.

Если валидацию всё равно делать, то добавить ещё одну строку на проверку типа - ни о чём.

А зачем? Сколько лет вашему примеру? Мало ли что до нас из глубокой древности дойти могло, может где и динозавр до сих пор обитает. :)

Так я и пишу, что если разработчик не смотрит на прокрустово ложе дбас, а разрабатывает исходя из требований программы, то в дбас оно почти наверняка не влезет. И получается наоборот «дбас не умеет 128-битные числа, ладно, не будем реализовывать возможность их получать».

А почему у вас динамически расширяются требования? Начиналось с флага, который выбирает между 2 вариантами. Это элементарно реализовывается.

Изначально был printf, но парировался «это никому по RPC не надо». Я привёл пример массово используемого RPC с аналогичным типом метода.

А не лучше ли сосредоточиться на той задаче, которую нужно решить лично вам?

Прямо сейчас? Ну вот у меня пример из сообщалки. Сейчас формат такой:

(отправить-сообщение {тип-получателя} {код-получателя} {содержимое})
тип-получателя = пользователь | группа
код-получателя = {положительное-целое}
содержимое = ({элемент-содержимого}*)
элемент-содержимого = "{строка}" | (изображение {положительное-целое}) | (цитата {положительное-целое}) | (цитата {положительное-целое} {содержимое})

Я мог бы отправлять его через d-bus?

Я же уже привёл пример Касперского. Вы сказали, норм. А теперь опять «зачем»? Что за метания?

Так надо тогда Касперского использовать, а не прогибаться под дбас.

Это будет последнее, что он продвинет. В 1ю очередь, он получит порцию отборного мата от Поттеринга, и заниматься ерундой сразу перестанет.

Тогда что вы хотели сказать утверждением «Так прогресс не продвинуть»? Его тогда никак не продвинуть.

Или авторы дбас уже согласны платить за ущерб от дыр в их поделке?

Если вы - корпоративный клиент редхат, то безусловно.

Если валидацию всё равно делать, то добавить ещё одну строку на проверку типа - ни о чём.

Те, кто будет деплоить ваше «решение», не будут доверять вашей проверке. Что делать лично вам на локалхосте - решать вам и только вам, а когда речь о продвижении в прод - требования другие.

то в дбас оно почти наверняка не влезет.

А обязано? Может, кому-то и сиарпц хватит, или другого рпц-движка.

Я привёл пример массово используемого RPC с аналогичным типом метода.

Это не новый проект. Можно весь мир наизнанку вывернуть, если приводить примеры из легаси, которые до сих пор актуальны, и утверждать, что это - светлое будущее. А на самом деле, это просто геморрой, который приходится поддерживать десятилетиями.

Я мог бы отправлять его через d-bus?

Конечно. Всякий мусор, типа «а может картинка на 2 гига, а может и 1 строка» там ходит по отдельному каналу для мусорных данных, а не по управляющим каналам.

Так надо тогда Касперского использовать, а не прогибаться под дбас.

Так я всего лишь показал, что дбас примерно в этом направлении и копает. Так если вам Касперский нравится, то и помогите дбасу двигаться в ЭТУ сторону, а не в обратную. А Каспер, я думаю, опоздал. Представь он своё решение раньше лет на 20 - была бы бомба.

Те, кто будет деплоить ваше «решение», не будут доверять вашей проверке. Что делать лично вам на локалхосте - решать вам и только вам, а когда речь о продвижении в прод - требования другие.

Так почти любые данные всё равно надо проверять. Мало где можно передать произвольное число или произвольную строку. Если проверку надо выносить наружу, нужны внешние правила и тот, кто их будет писать или проверять.

Более того, кто будет доверять тому, что я правильно написал тип для dbus?

А обязано? Может, кому-то и сиарпц хватит, или другого рпц-движка.

Может. Но тоже вряд ли. Потому что если пишешь по логике программы, то ограничения рпц-движков не учитываешь. А они все очень сильно ограниченнные.

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

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

Конечно. Всякий мусор, типа «а может картинка на 2 гига, а может и 1 строка» там ходит по отдельному каналу для мусорных данных, а не по управляющим каналам.

И его надо отдельно парсить. Так смысл от дбаса? Также можно парсить обычный сокет и не иметь лишней головной боли.

Так если вам Касперский нравится, то и помогите дбасу двигаться в ЭТУ сторону, а не в обратную

Логичнее забить на дбас и использовать Касперский. Вы же выше писали про ожидаемую. реакцию Поттеринга на прогресс.

Если проверку надо выносить наружу, нужны внешние правила и тот, кто их будет писать или проверять.

По-моему, это именно то, что я вам и пытаюсь донести. Да, нужны - всё так и есть.

Более того, кто будет доверять тому, что я правильно написал тип для dbus?

Никто - демон, по этому, кривой запрос и не пропустит, где тип не соответствует значению.

А они все очень сильно ограниченнные.

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

Примеры из легаси просто спроектированы без ограничений модных форматов.

Все модные форматы, или даже «ограничения» - нацелены на безопасность. И я пока не видел каких-то запредельных ограничений, под которые ну никак нельзя подстроиться. А вот ленивых программеров, пытающихся проталкивать своё старьё, вместо того, чтобы его обновить - хоть отбавляй. Если вам нормальную ЗП платят, то сидите и переделывайте столько, сколько потребуется. ЗП капает, вы ничего не теряете! А будете ныть или на Поттеринга пенять - потеряете время, и, возможно, место работы.

И его надо отдельно парсить. Так смысл от дбаса?

А что НЕ надо отдельно парсить? Даже если все аргументы функции уже проаудированы, вам всё равно, в реализации, надо их «парсить», чтобы выполнить соответствующую им логику.

Речь идёт исключительно о секьюрити-парсинге. Логический парсинг никуда не девается, дбас за вас весь метод не исполнит.

Логичнее забить на дбас и использовать Касперский. Вы же выше писали про ожидаемую. реакцию Поттеринга на прогресс.

На прогресс в сторону вараргов, или в сторону гибких, программируемых политик, как у Каспера? Или для вас это примерно 1 и то же, типа как cjson vs searpc?

Никто - демон, по этому, кривой запрос и не пропустит, где тип не соответствует значению.

Так я могу написать в типе d-bus, строку, прочитать значение строки и трактовать полученный указатель как число (ошибка такого же уровня, как ошибиться в ручной проверке типа).

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

Варарги нужны часто. Понятно, что для D-Bus заменим двумя массивами (один с типами, второй с значениями произвольного типа). Но это костыль. Для значений типа NULL придётся отдельный параметр делать. И всё это вручную проверять и собирать.

Ещё структур нормальных нет. Даже дерево не передать, потому что структуру, содержащую аналогичную не передать.

В общем, шаг вправо, шаг влево и клиенту надо давать готовую клиентскую библиотеку, так как вручную он может написать криво.

Все модные форматы, или даже «ограничения» - нацелены на безопасность. И я пока не видел каких-то запредельных ограничений, под которые ну никак нельзя подстроиться.

Как безопасность улучшается от запрета зависимых типов и рекурсивных структур?

Если вам нормальную ЗП платят, то сидите и переделывайте столько, сколько потребуется. ЗП капает, вы ничего не теряете! А будете ныть или на Поттеринга пенять - потеряете время, и, возможно, место работы.

Мне зарплату платят за 1С, у которого идеальный RPC.

&НаКлиенте
Процедура ОтправляемЗапросНаСервер()
  Данные = Новый Структура("Поле1, Поле2, Поле3");
  Данные.Поле1 = Новый Массив;
  Данные.Поле1.Добавить("Строка");
  Данные.Поле1.Добавить(42);
  Данные.Поле2 = ТекущаяДата();
  Данные.Поле3 = Новый ДиаграммаГанта();
  ОбработатьНаСервере(Данные);
  ВывестиДиаграмму(Данные.Поле3);
  Сообщить(Данные.Поле1[2]); // время с сервера
КонецПроцедуры

&НаСервере
Процедура ОбработатьНаСервере(Данные)
  ЗаполнитьДиаграммуПоДаннымБД(Данные.Поле3);
  Данные.Поле1.Добавить(ТекущаяДата()); // время на сервере
КонецПроцедуры

Я просто жалею тех, кто вынужден страдать с d-bus.

На прогресс в сторону вараргов, или в сторону гибких, программируемых политик, как у Каспера? Или для вас это примерно 1 и то же, типа как cjson vs searpc?

Так одно из другого следует.

Я просто жалею тех, кто вынужден страдать с d-bus.

себя бы пожалел...

Я просто не понимаю, что мешает в 21 веке сделать нормальный RPC, если уж он нужен единый универсальный. Ладно, про 1С они не знают. Так даже микрософтовский COM 30-летней давности позволяет работать с датами и объектами c произвольной структурой. А в d-bus максимально сложный тип — это структура с безымянными полями (типизированный кортеж, фактически).

Я просто не понимаю

Вот ВЕРЮ!!!.. ;)) :)))

А ты тоже считаешь, что dbus лучше и протокола через сокет, позволяющего структуры любого типа и любой сложности, как у MySQL и полнофункционального RPC как COM или 1С?

Я вообще ничего не «считаю», меня это не трогает...

И я это не трогаю... :))

Да чёж gtk3-то так не любят…

А зачем на венду?

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

JFF — Порт GTK 1.3 на Windows 11 (комментарий)

Монолитное дерьмище с идеальным RPC.

что dbus лучше и протокола через сокет

Вот это фейспалм

Монолитное дерьмище с идеальным RPC.

Чем оно монолитное, если есть серверные модули для Linux, Windows и клиентские для Linux, MacOS, Windows, Web, Android, iOS? И вот между клиентом и сервером и фоновыми процессами на сервере идеальный RPC. Функция из другого процесса выполняется не сложнее, чем из своего.

А здесь только этот цирк с конями: Как через DBus вызвать метод Unmount (IN a{sv} options)

И, что самое ужасное, по крайней мере два человека считают, что в Linux этого достаточно и лучшего [не надо].

У MySQL протокол через сокет. Предоставляет гораздо больше возможностей, чем D-Bus.

Чем оно монолитное, если есть серверные модули для Linux, Windows и клиентские для Linux, MacOS, Windows, Web, Android, iOS? И вот между клиентом и сервером и фоновыми процессами на сервере идеальный RPC. Функция из другого процесса выполняется не сложнее, чем из своего.

Как оно перестает быть монолитным от этого?

Это какой-то позор 🙄