> Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для
> разбора которых требуются хитрые манипуляции байтами с реализацией на CА на чем еще реализовывать критичный к скорости код? Безопасность там кстати здорово подтянули - гугель фуззит это добро непрерывно, так что баги чинятся еще до того как их хакеры найдут. И если кто считает что его парсеры валидируются лучше - на честное слово мы ему таки не поверим, пусть делом докажет. Реализовав столько же парсинга с производительностью не хуже и безопаснее. Тогда будет разговор.
> (и высокими рисками каких-либо уязвимостей, что подтверждается практикой)
Практика сейчас такова что там continious fuzzing и куча тестов вылавливают в парсерах самые чудесатые баги.
> и код, который умеет ходить по ssh не должны совмещаться.
Очень интересный вывод. Наверное, уровень экспертизы такой же как и с безопасностью.
> И тем более этого не должно происходить в одной библиотеке, которую потом подключает
> все кому не лень.
А может быть, правильный ответ - в том что эта библиотека все-же должна стать безопасной? И таки в этом направлении они хорошо подвинулись, нарулив фуззинг и тесты оптом.
Если кто думает что может лучше - пусть придет и покажет, вместо разглагольствований о том что, чему и сколько "должен". Вас никто не заставляет пользоваться этими библиотеками вообще. А то что там парсеров дофига и в них баги случаются - да, человечество придумало дофига форматов и протоколов. Некоторые из них даже навороченные и без багов их все реализовать может быть нетривиально. Но наверное в этом не ffmpeg виноват. И даже более того - лажа будет и с другими ЯП и проч.
> И далеко не всем из тех, кто использует ffmpeg нужно работать с сетью
> - но этот код разом оказывается во всех этих приложениям.
И, собственно, чего? Поэтому предлагается нагнуть тех кто все-таки хочет какое-нибудь потоковое аудио и видео? Так не пойдет.
> ssh, в приложении, которое просто хотело сделать какие-то мультимедиа-конвертации - это
> очень-очень плохо с точки зрения безопасности. Если вы этого не понимаете,
> не вижу смысла обсуждать это с вами дальше.
У меня ffmpeg сможет вылезти в сеть только очень гранулярно, контролируемо и тогда когда я этого явно захочу. И вот тогда мне будет вполне удобно и хорошо. Поговорите еще со мной о безопасности, мистер эксперт.
> Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop
Пардон, он без сети бесполезен чуть более чем полностью.
> (я может там в приватном чате пароль к архиву кидаю,
И чего? Там еще и кутя мегов на сто кода. При том это не какие-то парсеры которые фуззером можно прозвонить а круто абстрагированные плюсы, на синтаксическом анализе которых спятит что угодно. Туда же и пихтонр@сты всякие, кстати - там вообще безопасность по методу неуловимого Джо. Когда Джо начинает шуметь, у него находят eval() на входных данных вообще, как в bitmessage (который в отличие от телеги еще и явно пиарился как такой из себя весь секурный, а достаточно то всего разик посмотреть в тот код, чтобы оценить чего ждать от этих кодеров).
> а оно мне это куда-нибудь по ssh?..),
Оно по ssh будет ломиться только если программа об этом явно попросит. И если твой телеграм уже поимели настолько что он просит либу сходить по ssh - жалкие потуги обрубить фичу в либе тебя явно не спасут, о великий спец по безопасности.
> HandBrake-gui (обертка для конвертации), x264
> (тупо конвертер и файлика в файлик!!
Так они и не вызывают функций работающих с сетью. Если стремно можно в контейнер вообще засунуть.
> И теперь ВНЕЗАПНО получил возможность ходить по сети как угодно,
> ему можно передать URL и тп) и т.п.
А вот это еще не факт. Впрочем, если handbrake сможет транскодинг сразу с урлы - да это вообще пожалуй фича а не баг.
