В мультимедийном фреймворке GStreamer, используемом в GNOME, выявлено 29 уязвимостей. Восемь уязвимостей приводят к записи данных за пределы буфера, а одна (CVE-2024-47540) к перезаписи указателя на функцию. Указанные уязвимости могут потенциально использоваться злоумышленниками для организации выполнения кода при обработке некорректно оформленных мультимедийных данных в форматах MKV, MP4, Ogg, Vorbis и Opus, а также субтитров в формате SSA. Остальные уязвимости приводят к разыменованию нулевого указателя или чтению из области памяти за границей буфера, т.е. могут использоваться для инициирования аварийного завершения...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62441
Зато легче для кодера чем ффмпег.
> Зато легче для кодера чем ффмпег.Конечно легче - вон насколько оно "перфорированно".
Зато потешатся любители экономить каждый байт памяти и не важно, что дырявое)
Видимо никогда не пробовал его юзать, документации по нему ноль. Если что-то не работает, то хз почему. Лучше уж ффмпег.
Сишные указатели)
Тебе что взломали через них?
Brain
К счастью, он, всё равно, не использовался.
Нужно, больше, запятых,
Ага, Brain то явно через указатели ломали. Указали куда надо, а там полный беспредел.
А, всё прочее - не указатели, учим матчатсть...
Указатели есть везде, даже в Паскале. Просто не все их показывают.
Указателей практически нигде нет, исключение это си, плюсы, и ещё сравнительно небольшой список языков. В других языках ссылки. Ссылки не допускают арифметики укзателей, произвольных преобразования, ссылок на несуществующие участки памяти и так далее. Даже с учётом указателей, можно взять зависимые типы и строго контролировать происходящее. Но сишники слишком увлечены порчей памяти, чтобы знать об этом.
Как мне тогда прочитать данные из устройства по адресу 0xacabb33f
Не надо читать данные по адресу, это дырень же ж!
По ссылке и прочитать. http://0xacabb33f
Когда ты пишешь очередную формочку с кнопочками, тогда указатели не нужны.
А вот когда работаешь с железом, то "я их дом труба шатал", кто думает что лучше меня знает, как нужно сделать в данном конкретном случае. Указатели - это свобода реализации своих замыслов.
тогда почему в разных ЯП столько дыр с памятью если почти везде ссылки которые практически ничего не допускают и почти всё контролируют ?
10 лет работаю с дотнетом, не видел уязвимостей с памятью ни разу.
Поэтому в .Net столько CVE, позволяющих выполнить произвольный код или переписать занятый участок памяти...
> не все их показывают.Я б сказал, не все доверяют программисту работать с указателями так, как тому захотелось.
A нужно наказывать!
нахрен gstreamer кстати? есть же ffmpeg.
ffmpeg нельзя поставлять в сша ибо патенты на мпег (сказочная хрень, но факт). Вот и носятся с ним.
> ffmpeg нельзя поставлять в сша ибо патенты на мпег (сказочная хреньвас там двое в одной голове ? второй кстати прав
> второй кстати права это для первого
а че, как с freetype нельзя? в их сша-френдли репах поставлять ffmpeg без поддержки мпега (через какой-нибудь -DENABLE_MPEG=0), но позволять заменять ffmpeg другими билдами, где мпег включен. С freetype-ом так и было: в федоре шел без поддержки subpixel antialias, но в rpmfusion он был включен. Так что вопрос открытый: нахрена gstreamer, когда можно без gstreamer.
Прежде чем задавать такой вопрос, тебе надо бы понять что такое ffmpeg и что такое gstreamer. Тогда твой вопрос перестанет иметь смысл.
Совет в конце статьи нерабочий на не древних дистрибутивах, гении из GNOME переименовали tracker miner на TinySPARQL.
Из eng wiki:
"TinySPARQL is a general-purpose SPARQL-based database;"
В debian testing никакой tinysparql нет.
Есть библиотека базы данных libtracker-sparql для tracker.
Сами сервисы в пакетах tracker, tracker-miner-fs, tracker-extract и маскировать надо их.
Переименовали , потому что в tracker-miners одна уязвимость за другой. Совет тут простой. GNOME и подобные жирные куски раздать нуждающимся, а самому воздержаться.
KDE с выходом 6 плазмы перетащил свой Phonon на libvlc. Интересно было бы там уязвимости глянуть.
Phonon чисто kde-либа а кедовский плеер сильно проигрывает тому же mpv (имхо самый нормальный плеер для линукса). Так что - эталонное ненужно.
> Интересно было бы там уязвимости глянуть.Дык глянь или моск совсем уже оджавпскриптился
>> Интересно было бы там уязвимости глянуть.
> Дык гляньЗачем? Проще подождать и почитать на опеннете очередную новость "в libvlc нашли уязвимости"
> или моск совсем уже оджавпскриптился
фу как некрасиво, тебе бы поработать над своим воспитанием, раз родители недоработали.
О нет злоумышленник может уронить плеер с хентаем со сторонней акдиодородкой какой ужыс. Срочно переписать.
Это библиотеку куда только не пихают...
В Протон сидит.( Протон одна из наиважнейших апликух в невиндовом мире. )
Да статье же указанно - "в приложениях Nautilus (GNOME Files), GNOME Videos и Rhythmbox, а также в развиваемом проектом GNOME поисковом движке tracker-miners" т.е.он там ~облачно сканируя сеть скачивая затрояненне видоролики сам... - мало что ли?
(т.б.в условии неиспользвоании доп..аккаунта под каждое такое приложение... т.е.типично).
Ты можешь скачать аудиокнигу, а она автоматом скачает на сервер злоумышленника все твои файлы с паролями.
Вывод: не стоит хранить файлы с паролями.
Это ты сам долумал как про бабайку. Через сабжевые уязвимости за всю историю не было ни одного взлома.
> а также субтитров
> индексирует все файлы в домашнем каталоге без каких-либо действий со стороны пользователяТ.е ты скачал субтитры для своего хентая, а оно похакало твой комп просто в момент "сохранил на в папку download"
Звучит нормально для СИшных проектов и ГНОМа)).
> Восемь уязвимостей приводят к записи данных за пределы буфера,
> а одна к перезаписи указателя на функцию.Ha-ha, classic.
Вообще там ВСЕ дырени типикАл сишные.
CVE-2024-47537 OOB-write in isomp4/qtdemux.c
CVE-2024-47615 OOB-Write in gst_parse_vorbis_setup_packet
CVE-2024-47613 OOB-Write in gst_gdk_pixbuf_dec_flush
CVE-2024-47539 OOB-write in convert_to_s334_1a
CVE-2024-47541 OOB-write in subparse/gstssaparse.cCVE-2024-47538 Stack-buffer overflow in vorbis_handle_identification_packet
CVE-2024-47607 Stack-buffer overflow in gst_opus_dec_parse_headerCVE-2024-47542 Null pointer dereference in id3v2_read_synch_uint
CVE-2024-47544 Null pointer dereference in qtdemux_parse_sbgp
CVE-2024-47599 Null pointer dereference in gst_jpeg_dec_negotiate
CVE-2024-47601 Null pointer dereference in gst_matroska_demux_parse_blockgroup_or_simpleblock
CVE-2024-47602 Null pointer dereference in gst_matroska_demux_add_wvpk_header
CVE-2024-47603 Null pointer dereference in gst_matroska_demux_update_tracks
CVE-2024-47835 Null pointer dereference in parse_lrcCVE-2024-47543 OOB-read in qtdemux_parse_container
CVE-2024-47596 OOB-read in FOURCC_SMI_ parsing
CVE-2024-47597 OOB-read in qtdemux_parse_samples
CVE-2024-47598 OOB-read in qtdemux_merge_sample_table
CVE-2024-47600 OOB-read in format_channel_mask
CVE-2024-47778 OOB-read in gst_wavparse_adtl_chunk
CVE-2024-47777 OOB-read in gst_wavparse_smpl_chunk
CVE-2024-47776 OOB-read in gst_wavparse_cue_chunk
CVE-2024-47775 OOB-read in parse_ds64
CVE-2024-47774 OOB-read in gst_avi_subtitle_parse_gab2_chunkCVE-2024-47545 Integer underflow in FOURCC_strf parsing leading to OOB-read
CVE-2024-47546 Integer underflow in extract_cc_from_data leading to OOB-readCVE-2024-47834 Use-After-Free read in Matroska CodecPrivate
CVE-2024-47606 Memcpy parameter overlap in qtdemux_parse_theora_extension leading to OOB-write
CVE-2024-47540 Uninitialized variable in gst_matroska_demux_add_wvpk_header leading to function pointer ovewritingВот интересно, это все писали диды-какиры или молодые смузихлебы?
Хотя... какая разница - что те писать не умели, что эти)))
Он же на C, что ещё было ожидать? По этой причине не стали его использовать в своё время. И ещё из-за невменяемой схемы распространения с невменяемым разделением плагинов на good/bad/ugly.
FFmpeg на Rust переписали?
Даже на Аду не переписали.
> FFmpeg на Rust переписали?Нет конечно. Это же огроменный кусок ка... кода.
Да и диды копротивляются переписыванию, поэтому по частям не перепишешь. А переписывать все сразу - это очень долго, все-таки кодовая база большая - пилят почти четверть века.А вот отдельные кодеки и сопутствующее на раст перерисывают - rust-av, rav1e, rav1d, ivf-rs, matroska, ffv1, av-mp4, lewton и тд. Но понятно что процесс будет не быстры.
А где же нейросети, про которые столько говорят? Вот, мол, нейросеть перепишет весь код с "дыряшки" на Раст?
> А где же нейросети, про которые столько говорят?
> Вот, мол, нейросеть перепишет весь код с "дыряшки" на Раст?Эм... кто такое говорит? Я слышал из реального только одни экспериментальный проект у DARPA (opennet.ru/opennews/art.shtml?num=61656). И больше про него ничего слышно не было.
А если ты про местных комментаторов... То пфффф.Основная проблема что тебе нужно сеть на чем-то обучить.
А большая часть си кода - это лютый 6ыdloкод без проверок, с нарушением прав владения (да, в сишке нет явного borrowing, но неявный есть всегда и его все равно нужно соблюдать), поточности и тд.
Как ты его на раст оттранслируешь? Оно просто не скомпилируется.
Там местами вообще архитектуру менять придется.
исследование от майкрософт, которые пытаются везде пропихнуть раст, о том, что везде нужно пропихнуть раст. классика, но уже скучно
Да, все уже привыкли к уязвимостям и тому, что всё кругом дырявое. Вяло уже как-то. А если уязвимостей будет ещё меньше, так станет ещё скучнее. А хочется-то веселухи.
посмотрю я на тебя через пару лет, когда у тебя в coreutils реклама будет, а отключить ты её не сможешь, потому что всё уже будет на раст, зависящее от сотни фреймфорков и не работающее без цифровой подписи майкрософт
> посмотрю я на тебя через пару лет, когда у тебя в coreutils реклама будет, а отключить ты её не сможешь, потому что всё уже будет на раст, зависящее от сотни фреймфорков и не работающее без цифровой подписи майкрософтОхохоюшки, вот это поток мысли!
Но если опускаться на твой уровень...
То во-первых, типа нельзя будет опенсорсные uutils (coreutils на расте и благословенной свободной MIT) форкнуть и делать с ними что пожелаешь?
А во вторых, на сишке написанно куча проприетарного софта и всем пофиг.ps ты главное закрывай замки понадежнее, а вдруг придет майкрософт и запилит тебе двери свой цифровой под-пись-ю))
Не смешно потому что ЦП M$ уже давно уровнем ниже coreutils сидит.И не так страшна реклама которую смотришь ты, как реклама которая смотрит тебя.
У параноиков не возникает вопрос как си защитит их от цифровой подписи, они строго уверены, что цифровая подпись возможна только на растие. А ещё параноики не доверяют фреймворкам, и пишут код каждый раз с нуля, заново собирая все баги.
> что цифровая подпись возможна только на растиегде ты это прочитал?
> исследование от майкрософт, которые пытаются везде пропихнуть раст, о том, что везде нужно пропихнуть раст. классика, но уже скучноХм.. т.е это наймиты мелкомягких проникли в команду Г-стримера (код с большой буквы Г) и сделали все эти ошибки-уязвимости?
Какое коварство!
Уже не в первый раз растовики подбрасывают код в штаны СИшникам.
Надо с этим срочно что-то делать!
> Надо с этим срочно что-то делать!Добавить статических анализаторов, срочно. И ещё, это ... как там, забыл. Блин, важное что-то ... а, просто уметь писать код. Вот тогда уж заживём, и никакой раст не нужен будет.
Погоди, Настоящий СИшник пишет отличный код и без всяких анализаторов и прочих смузихлебных новинок.
Вон диды написали кучу кода "на котором мир держится". Такие чудесные проекты как ХОрг, ж-либ-с, ядро линукс.Ты бы еще предложил на этапе компиляции проверять, чтобы никакой указатель не испортился, чтобы все висячие ссылки проверялись.
А что дальше? Может боровчекер добавить?!
Да ты небось растовик в майкрософте работаешь!!
Где переписанное на Раст или аду?
Начните срочно анализировать код на Rust'е. И под unsafe-ковер не забудьте заглянуть. Узнаете много нового об уязвимостях.
При этом, люди постоянно удивляются - "ну зачем они опять переписывают на раст то, что уже и так написано? Только и могут, что переписывать!"Главное, когда такие вопросы задаёшь, игнорировать реальность и не замечать новостей про десятки уязвимостей из-за ошибок работы с памятью в одном лишь приложении.
А если даже и замечать, то говорить "ну и что, тебе же ничего через них не сломали!".
Сишкофилам хочется пожелать одного: давайте вы весь военный софт на своей сишечке напишете? Хельсинг вон все бортовые системы управления боевыми дронами пишет на расте. А потом сравним. Как это один известный человек сказал - проведём высокотехнологический эксперимент.
Просто переход на Rust не уберет уязвимости, они просто изменят свою форму. Не забывай об этом! 🛡️
Если у тебя 50% всех уязвимостей происходят из-за работы с памятью, то уязвимостей станет в два раза меньше. Их не останется столько же в изменённой форме, их станет в два раза меньше. Причём именно они обычно связаны с RCE.
> Если у тебя 50% всех уязвимостей происходят из-за работы с памятьюНу, в данном конкретном случае все 100% - это проблемы с памятью.
Даже всякие Integer underflow потом стреляют из-за OOB.Но дыряшечники будут "лепить галимые отмазы":
- зачем это если есть ffmpeg
(ахаха, а типа ffmpeg не такое же омнище с Integer Overflow CVE-2024-35366, Double Free CVE-2024-35368 и Out-of-bounds Read CVE-2024-35367)- это специально так написали, потому что им так заказали
(ребята, у вас все сишные продукты дырявые, в таком случае всех уже купили и вообще никому доверять нельзя)- это не настоящий сишник, вот настоящий бы никогда!
(а настоящих не существует, хехе)
> зачем это если есть ffmpegПричём, этот ффмпег точно также можно было бы и на расте написать. Всё с теми же ассемблерными вставками, которые раст поддерживает.
> в данном конкретном случае все 100% - это проблемы с памятью.Это смещённость выборки. Там coverage driven fuzzing использовался, но к нему необходим какой-то алгоритмический способ выявления косяков, и я подозреваю, что автор использовал что-то типа valgrind'а, который детектировал именно ошибки работы с памятью, не замечая никаких других. То есть, в этом списке не могли возникнуть ошибки не сводящиеся к неправильной работе с памятью. Невозможно по этому исследованию судить о том, сколько там ошибок другого типа.
> Это смещённость выборки.На 100% уверены?
Тут есть пройтись по тегу GStreamer, то увидим забавный список новостей:Две уязвимости - Use-After-Free и переполнение буфера (opennet.ru/opennews/art.shtml?num=60185)
Три уязвимости - целочисленное переполнение с потенциальным выполнением кода, переполнение буфера (opennet.ru/opennews/art.shtml?num=59852)
Две уязвимости - целочисленное переполнение с потенциальным выполнением кода (opennet.ru/opennews/art.shtml?num=59592)
Две уязвимости - переполнение буфера с потенциальным выполнением кода (opennet.ru/opennews/art.shtml?num=59410)
Одна уязвимость - переполнением буфера + выполнение кода, даже с примером эксплойта (opennet.ru/opennews/art.shtml?num=54465)И это только первая страница поиска (15 новостей), дальше мне лень))
Как видим у GStreamer есть невероятно богатое и дырявое сишное прошлое.
Поэтому можно конечно попытаться объяснить происходящее "особенной" выборкой...
> Поэтому можно конечно попытаться объяснить происходящее "особенной" выборкой...Есть разница между "объяснить происходящее" и "сделать из происходящего дальнейшие выводы". Если ты исходя из убеждения в дырявости gstreamer'а делаешь вывод, что эта выборка говорит о дырявости gstreamer'а, а потом делаешь дальнейший вывод о дырявости gsreamer'а... Знаешь, я когда учился на первом курсе, мой одногруппник летел с экзамена по матану дальше чем видел, совершив схожую ошибку. По-моему, он попытался предел sinx/x взять правилом Лопиталя, применение которого требует знания производной sin, а производная sin выводится с опорой на взятый предел sinx/x. Препод гаркнул "циклический вывод" и с пинка отправил дурака из аудитории на пересдачу.
В данном случае я лишь говорю о том, что из данного исследования в новости нельзя делать никаких выводов о том, каких багов в gstreamer'е больше, багов с памятью или каких-то других. Я не говорю о том, что таких выводов нельзя сделать опираясь на другие факты.
>Даже всякие Integer underflow потом стреляют из-за OOB.Специально против такого и придуманы зависимые типы. Но опять же, сишникам некогда читать матан, они дырки плодят.
И сколько реалтных проблем причинили эти уязвимости нуль? И это при том что самые большие утечки происходят по причине неправильной обработки путей. При том что Раст тоже неправильно обрабатывает пути.
А вот и отмазка нумер 42 из 100500
Ну напиши такой же плеер по функционалу. Пока все что виду от местных любителей — комментарии.
> Ну напиши такой же плеер по функционалЗачем ему писать такой же плеер? Тем более что авторы самого Gstreamer сами на Раст давно перекатываются:
https://gstreamer.freedesktop.org/releases/1.22/
"33% of GStreamer commits are now in Rust (bindings + plugins), and the Rust plugins module is also where most of the new plugins are added these days."
> Зачем ему писать такой же плеер? Тем более что авторы самого Gstreamer сами на Раст давно перекатываются:
> https://gstreamer.freedesktop.org/releases/1.22/Ого, спасибо за уточнение.
Конечно bindings + plugins это только начало, но самый трудный - первый шаг.> "33% of GStreamer commits are now in Rust (bindings + plugins), and the Rust plugins module is also where most of the new plugins are added these days."
Жду с нетерпением анонса переделывания основного проекта.
Тогда точно в комментах будут полыхающие седалища.
> Жду с нетерпением анонса переделывания основного проекта.геморой насидишь, 5 звёзд за несколько лет на гихабе намекают тебе об охеренной нужности расто-плугинов
> звёзд за несколько лет на гихабе намекаютА "mirrored from https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs.git&... тебе ни на что не намекает?
> А "mirrored from https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs.git&... тебе ни на что не намекает?да - это зеркало! Сравно с зеркалом linux
> Зачем ему писать такой же плеер? Тем более что авторы самого Gstreamer
> сами на Раст давно перекатываются:Сделать биндинги и разрешить писать плагины - это не называется перекатываться.
Ползут в направлении в лучшем случае.
Но сам факт удивляет, это да.
>> Ну напиши такой же плеер по функционал
> Зачем ему писать такой же плеер? Тем более что авторы самого Gstreamer
> сами на Раст давно перекатываются:А ну как обычно. Зачем писать что-то, если можно паразитировать и переписывать. Типикал.
Зачем перестраивать дом если можно жить в землянке?
Зачем делать нормальный санузел, если можно бегать на улицу?
Зачем делать нормально, если можно кушать уязвимый код и нахваливать?Твой в-сер особенно смешной с учетом того, что "паразитировать и переписывать" начали сами разработчики GStreamerʼа.
На ком они паразитируют, гений?
> Зачем перестраивать дом если можно жить в землянке?
> Зачем делать нормальный санузел, если можно бегать на улицу?
> Зачем делать нормально, если можно кушать уязвимый код и нахваливать?Мастер сравнений просто. Ну если тебе будет удобнее так, то ты не сам дом построил, а пришел в уже готовый и начал хозяйничать без спроса.
> Твой в-сер особенно смешной с учетом того, что "паразитировать и переписывать" начали
> сами разработчики GStreamerʼа.
> На ком они паразитируют, гений?И? А ты такой радостный что кто-то там начал что-то переписывать? Ведь за 15 лет нельзя было написать свой, а не ждать. Стыдно должно быть тебе. Позор!
> Ну если тебе будет удобнее так, то ты не сам дом построил, а пришел в уже готовый и начал хозяйничать без спроса.Ого, а на доме кто написал д̶о̶м̶ ̶с̶в̶о̶б̶о̶д̶е̶н̶,̶ ̶ж̶и̶в̶и̶т̶е̶ ̶к̶т̶о̶ ̶х̶о̶т̶и̶т̶е̶ код под GPL форкайте / патчите кто хотите?
Или мне нужно спрашивать "а можно к вам отправить pull request"?
Если мой патч не подойдет создателям проекта - они его просто отклонят, это кажется должно быть понятно любому.
Но этот код приняли - значит всех все устраивает.> И? А ты такой радостный что кто-то там начал что-то переписывать?
Конечно. Если больше проектов будут переходить на нормальные языки -> больше людей будут понимать что "не дырявыми одними" -> будет больше запросов на программы на нормальных языках -> у меня будет больший выбор проектов для работы.
Для меня одни плюсы.> Ведь за 15 лет нельзя было написать свой, а не ждать. Стыдно должно быть тебе. Позор!
Воооообще не стыдно)
Написать свой, но зачем? У меня то все нормально работает.
А стыдно это - брак гнать, годами причем.
>> Ведь за 15 лет нельзя было написать свой, а не ждать. Стыдно должно быть тебе. Позор!
> Воооообще не стыдно)
> Написать свой, но зачем? У меня то все нормально работает.
> А стыдно это - брак гнать, годами причем.Нормально у тебя работает явно не плеер на расте, которого нет. Значит ты 15 лет пользуешься чем-то "бракованным" (как ты сам заявляешь) и вот сейчас тебя вдруг порвало об это заявить? Может за эти 15 лет ты завел где-то баги?
>> И? А ты такой радостный что кто-то там начал что-то переписывать?
> Конечно. Если больше проектов будут переходить на нормальные языки -> больше людей
> будут понимать что "не дырявыми одними" -> будет больше запросов на
> программы на нормальных языках -> у меня будет больший выбор проектов
> для работы.
> у меня будет больший выбор проектов
> больший?А какой сейчас? Ноль?
> 33% of GStreamer commits are now in Rustэто два года назад было, сейчас уже 101%. Там самый буйный переписыватель, я с ним как-то пересекался в одном опенсорсном проекте, он предлагал мне мой патч выпилить чтобы его патч заработал. Причём его патч абсолютно левый - какие-то никому ненужные нестандартные форматы добавлял. Мой патч исправлял баг вендорского ядра - там не принимают сторонние патчи, поэтому пришлось локальный костыль делать, собственно весь плагин был под это ядро написан. Ну т.е. понятно да - хер на вас, не важно что перестанет работать, главное чтобы у него заработало :) видимо на заказах сидит и надо стало.
> люди постоянно удивляются - "ну зачем они опять переписывают на раст то, что уже и так написано? Только и могут, что переписывать!"Удивляютя сугубо опеннетные комментаторы - те, которые к разработке ПО никакого отношения не имеют.
Причем на поверку как правило оказывается, что чем меньше персонаж шарит в C, тем сильнее он воюет против Раста.
Может это синдром утенка?
Это как футбольные и прочие фанаты - готовы бить физиономии тем кто обозвал их любимую команду кривоногими инвалидами.
Думаю тут такое же - с детства им вбивали в голову что есть один идеальный ЯП созданный гениальным коммитетом и вообще самый лучший.
А тут приходят какие-то сопляки и говорят "да у вас тут дыреней как в шапке почтальона Печкина!".
Естественно это вызывает баттхерт и гневные вопли.
А потом когда начинаешь задавать вопрос по сonformance они чего-то сливаются.
> Хельсинг вон все бортовые системы управления боевыми дронами пишет на расте.это он вам сам сказал ? так вы тоже говорите - проверить всё равно невозможно
GStreamer - это предшественник PipeWire. Написать адаптер, выкинуть оригинал, и забыть.
Нельзя.
Начнется воняние "на моем ядре 2.3 оно не запустится! как вы посмели что-то выкидывать" и тд
То что мы видим в каждой первой теме про выпиливания некрокода.
Какая проблема сделать другу версию, а не выкидывать все подряд что и так работает.
Угу, а теперь поддерживать 2 куска кода.
Проводить тестирование, отслеживать регрессии.
Это же так просто, когда этим занимается кто-то другой!
Ну бэкпортировать на старые ядра. Линус же юзерспейс не ломает, должно быть сравнительно легко.
> GStreamer - это предшественник PipeWire.Вроде не совсем так. У них разные задачи. Условно говоря, GStreamer это обработка и декодирование потоков. А Pipewire – диспетчеризация. Наверное, теоретически, можно реализовать кодеки и всякие эффекты внутри Pipewire, но зачем?
В общем сильно опоздавший клон Windows Media Foundation.
Запускаю плееры в изоляции уже давно и вам советую.
Изоляция синяя, всё по ко канонам? Или новомодной термоусадкой? :-/
>systemctlА без systemd? Или это только с системгой и гомом? То бишь, сферически и в вакууме?
Гном-сервис который автоматически находит и запускает экспоиты это уже или ещё не совсем год линукса на дескпопе?
Ого, а новость обновилась.> Помимо 29 уязвимостей, выявленных исследователями из GitHub Security
> Lab, в версии 1.24.10 заявлено об исправлении ещё 11 уязвимостей.Прям какое-то сишное бинго сегодня!
Они бы еще написали сколько лет каждая из дыреней жила в этом прекрасном коде,
написсаном луДшими погромистами современности!Может еще не вечер, и что-то еще найдут?))
> Помимо 29 уязвимостей, выявленных исследователями из GitHub Security Lab, в версии 1.24.10 заявлено об исправлении ещё 11 уязвимостей.Да что ж такое!
Надо срочно запретить статические анализаторы, а то они показывают дидов в нехорошем виде.
И вгоняют фанатиков небезопасных языков в депрессию)
> Надо срочно запретить статические анализаторыЭто не статические анализаторы, а coverage driven fuzzing. Идея в том, что фаззер подаёт на вход программе всякие данные, наблюдает за всеми условными переходами, и подбирает такие последовательности на входе, чтобы пронаблюдать как каждый из условных переходов сработает и как он не сработает. Я не знаю, как они там детектируют баги при этом, но предполагаю, что помимо фаззера на выполнением программы наблюдает ещё и valgrind или что-нибудь в этом роде. Потом приходит человек, и разбирает выхлоп валгринда, и перерабатывает его в список багов.
Статический анализ тут ни при чём совершенно. Кроме того, я б сказал, что если код на безопасных языках обильно присыпать assert'ами, то такой фаззинг может и им помочь избавляться от "безопасных" багов, достаточно гонять фаззер и ждать, когда тот наступит на какой-нибудь assert.
Советующие rust, вы правда считаете, что ЯП, ПО на котором нельзя адекватно собрать оффлайн без добавки на несколько попядков большего числа исодников, прям безопаснее?
Довольно печальная ведь получается математика.
Не понял, а если ты в сишной программе хочешь использовать уже ранее написанный код, то как ты это сделаешь без этого написанного кода? Без ... исходников? С уже собранной библой слинкуешься что ли? А чем это более безопасно, по сравнению со сбором исходников?
В сишных программах не учатся жрать с пола исходники, когда надо написать лефтпад, в сишных пргограммах либо он есть в базовой либе, либо пишется с руки.
> в сишных пргограммах либо он есть в базовой либе, либо пишется с рукиВ сишных программах вообще дохрена чего нет, в том числе в базовой либе. И язык скудный, и стандартная библиотека. Поэтому там либо постоянно изобретают велосипед, косой и кривой, либо используют скудные технические решения, типа размещения массива на стеке потому, что в языке нет родных нормальных коллекций типа array list, linked list, hashmap, и так далее, либо всё также линкуются со сторонними либами, которые предоставляют нужное.
Кстати, подход большой базовой либы оказался мертворожденным. Когда его придумывали ещё этого не понимали, к авторам претензий никаких нет, это было давно. А те, кто за толстую базовую либу топят сейчас просто не понимают, про что говорят. Ну просто люди не в теме развития программирования как науки.
Стандартная библиотека - это кладбище. По своему устройству, чисто логически. Потому, что она призвана быть надёжным основанием для программ, которые пишутся на языке. Это значит, что в ней нельзя или очень нежелательно ломать совместимость. Это значит, что если у присутсвующего там решения появляется существенно лучшая альтернатива, то старьё в этой библиотеке остаётся мёртвым грузом, потому что все переходят на стороннее решение. Со временем библиотека начинает представлять из себя кучу мёртвого API которое никто не использует, кроме старого кода, который никто не хочет переписывать под новый API. Такая судьба постигает все, абсолютно все стандартные библиотеки. Python, Java, Scala, C++, и так далее.
Поэтому в идеале стандартную библиотеку делают минимальной - только самое необходимое, что нужно везде и всегда.
Разумеется сишники, живущие в изоляции от внешнего мира последние 30 лет ничего этого не знают и не понимают. Только раст их разбудил из глубокого сна, они такие вылезли типа чё, чё это у вас тут, код какой-то переиспользуете, фичи языка какие-то не такие, как у нас было принято 30 лет назад.
Умойтесь, блин. Проснитесь уже.
> Поэтому в идеале стандартную библиотеку делают минимальной - только самое необходимое, что нужно везде и всегда.Вот только "что нужно везде и всегда" очень разнится от сферы применения.
Для МК и прочей эмбедовки нужно миниально.
Для системщины - уже более.
А для прикладного, можно и целую кучу ункций и возможностей использовать.Например, нужен ли класс/структура/объект String ?
А ведь в СИшке из коробки их нет до сих пор, а в плюсы добавили не в первую версию.
В итоге - парад велосипедов, постоянные проблемы и даже порожденные ими CVEшки.
> Вот только "что нужно везде и всегда" очень разнится от сферы применения. Для МК и прочей эмбедовки нужно миниально.Да, в расте это решено через то, что стандартная библиотека - опциональна. При этом куча хороших, сторонних библиотек под раст умеют собираться в режиме «без стд», что позволяет переиспользовать кучу полезного кода даже там, где нет операционной системы.
При этом на уровне «без стд» всё равно есть какие-то типы, которые ваще самые самые базовые, фактически часть языка.
> В итоге - парад велосипедов, постоянные проблемы и даже порожденные ими CVEшки.Парад велосипедов был бы в любом случае, вопрос только в том, где - как опциональные либы на выбор или как часть базовой библиотеки.