forum.opennet.ru - "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, OpenClaw, Nix и ядре Linux" (107)

"Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, OpenClaw, Nix и ядре Linux"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, OpenClaw, Nix и ядре Linux"	+/–
Сообщение от opennews (??), 10-Апр-26, 17:36
Несколько выявленных за последние дни опасных уязвимостей, большинство из которых можно эксплуатировать удалённо:... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=65183
Ответить \| Правка \| Cообщить модератору

Оглавление

И это они ещё с мифосом не экспериментировали , Аноним (1), 17:36 , 10-Апр-26, (1) +4

Это ещё даже Алису не попробовали, Аноним (70), 20:16 , 10-Апр-26, (70) +3
Это ведь просто баг, да , Аноним (90), 21:47 , 10-Апр-26, (90) +2

Фича,а вот в БСД это ЦВЕ и не такой старый как эта Линукс-фича , Аноним (114), 00:31 , 11-Апр-26, (114)

Разве Так много ошибок в столь разных проектах - я думаю это оно и есть , Витюшка (?), 22:43 , 10-Апр-26, (95)

https days-since-openclaw-cve com Days since last OpenClaw CVE - 0A new CVE wa, Аноним (2), 17:39 , 10-Апр-26, (2) +8
Ужас Зачем нейронку для их выявления сделали , Аноним (3), 17:42 , 10-Апр-26, (3) –5

Чтобы на раст не переписывать Кстати, получается, что не выгодно Если ошибок с, Сладкая булочка (?), 17:56 , 10-Апр-26, (5)

Так во все эти проекты особенно в ядро каждый релиз добавляют 100500 строк нов, Аноним (11), 18:08 , 10-Апр-26, (11)

В этом и цель деньги за токены В итоге все счастливы Продолжайте вести наблюде, Сладкая булочка (?), 18:17 , 10-Апр-26, (19) +1

Цель кого Если корпе сказать вам не надо тратить деньги на токены, нужно просто, Аноним (-), 18:21 , 10-Апр-26, (21) +1

На чем твоя уверенность, что на переписывание создание новых уязвимостей трати, Сладкая булочка (?), 18:28 , 10-Апр-26, (25)

Причина в теории Ты сам-то хоть понял, что написал 128514 Нет, причина дыр п, Аноним (29), 18:45 , 10-Апр-26, (29)

Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует, так , Сладкая булочка (?), 18:51 , 10-Апр-26, (31)

А зачем сразу всех Давайте начнем с некого класса ошибок, которые не просто са, Аноним (35), 18:55 , 10-Апр-26, (35)

Нет, ты сводишь все к волшебному инструменту, которого нет , Сладкая булочка (?), 19:04 , 10-Апр-26, (42)

Что все Ты кажется невнимательно читала Волшебного инструмента не существует , Аноним (80), 21:15 , 10-Апр-26, (80)

А никто и не говорит про все Речь про проблемы работы с памятью , Аноним (29), 18:57 , 10-Апр-26, (37)

Про нее и речь Ты можешь построить формальную модель, но в реальном мире особе, Сладкая булочка (?), 19:02 , 10-Апр-26, (39)

Есть большая разница у тебя unsafe только в низкоуровневом коде и у тебя весь, Аноним (43), 19:05 , 10-Апр-26, (43) –1

Не будет, т к отустуствие ub в unsafe блоке - это допущение, которое не проверя, Сладкая булочка (?), 19:14 , 10-Апр-26, (49)
Конечно будет, потому что количество небезопасного кода сокращается в десятки ра, Аноним (29), 19:25 , 10-Апр-26, (56)
У тебя любой примитив синхронизации будет с unsafe внутри Алгоритмы работают в, Сладкая булочка (?), 19:31 , 10-Апр-26, (59)
А вся логика снаружи - нет Об этом как бы и речь Программные алгоритмы работают, Аноним (29), 19:47 , 10-Апр-26, (66) –1

Нет, ты только что пел буквально про все уязвимости , а не только те, что вызва, Аноним (29), 19:18 , 10-Апр-26, (51)

Очередной дешевый тролинг с обвинениями Продолжать не буду Главное не забывать , Сладкая булочка (?), 19:24 , 10-Апр-26, (54) –1
Нет, просто констатация того факта, что ты переобуваешься на лету и как теперь , Аноним (29), 19:30 , 10-Апр-26, (58)
У тебя всегда тролинг строится по одной схеме Мой тебе совет пора что-то менят, Сладкая булочка (?), 19:34 , 10-Апр-26, (61)

зависит от области определения той или иной функции, типы как раз и есть те о, Аноним (40), 19:02 , 10-Апр-26, (40)

Посмотри формальную верификацию чего-либо околосистемного , Сладкая булочка (?), 19:10 , 10-Апр-26, (47)

Допустим шедуллер процессов, ввода-вывода, и т д и что Сложно это верифицирова, Аноним (40), 19:23 , 10-Апр-26, (53)

Мне не важно, что ты думаешь Найди и покажи такую верификацию, а мы посмотрим, , Сладкая булочка (?), 19:25 , 10-Апр-26, (55)
Скрыто модератором, Аноним (29), 19:32 , 10-Апр-26, (60)
Скрыто модератором, Сладкая булочка (?), 19:37 , 10-Апр-26, (63)
Вот sel4 systems Verification proofs html sel4 systems Verification implicatio, Аноним (40), 19:48 , 10-Апр-26, (67) –1
А внутрь ты смотрел Доказывают они, на самом деле, свойства урезанной статичной , Сладкая булочка (?), 20:52 , 10-Апр-26, (74)
ой все понятно, ЫЫ-шный бот очередной Вот https github com seL4 l4v blob maste, Аноним (40), 00:48 , 11-Апр-26, (115)

Ты не понимаешь, что несешь При формальной верификации кода для каждой функции,, Аноним (29), 19:06 , 10-Апр-26, (44) –1

Ну дак это искусственные условия На практике многие утверждения приходится акси, Сладкая булочка (?), 19:19 , 10-Апр-26, (52) +2

Это как раз не исукственные условия - это условия, которые ты контролируешь на у, Аноним (29), 19:38 , 10-Апр-26, (64) –1

Нет Это выставление условий модели удобных для доказательства В sel4 доказываю, Сладкая булочка (?), 20:56 , 10-Апр-26, (77) +1
п здешь и провокация, открой директорию proof, Аноним (40), 00:50 , 11-Апр-26, (118)

Так и есть, но это ведь не самообман, вы говорите за формальную верификацию как , Аноним (40), 19:46 , 10-Апр-26, (65) –2

gt оверквотинг удален Ответил здесь https www opennet ru openforum vsluhforu, Сладкая булочка (?), 20:53 , 10-Апр-26, (75)

дырява твоя модель памяти и архитектура Фон-как его там-Неймана , Аноним (40), 18:53 , 10-Апр-26, (33)

Вы забыли привести доказательства Проблему разыменновывания нулевого указателя , Аноним (101), 23:21 , 10-Апр-26, (101)

Доказательство чего Проблемы останова Интернет в помощь Можно решить обе пробл, Сладкая булочка (?), 23:43 , 10-Апр-26, (106)

Как связана проблема останова и разыменновывание нулевого указателя А то что, па, Аноним (101), 00:10 , 11-Апр-26, (110) –1

Ты мне ответь, если с самого начала речь шла про теорию вычислимости и проблему , Сладкая булочка (?), 00:17 , 11-Апр-26, (113) –1

Да да, The RUST crowd , Аноним83 (?), 21:15 , 10-Апр-26, (79)

И кто же, интересно, эти те кто притормозят , Аноним (15), 18:12 , 10-Апр-26, (15)

Те же, кто дают команду на внедрение , Сладкая булочка (?), 18:15 , 10-Апр-26, (17) +1
ОНИ Судя по всему мысля такова - подобные проверки требуют много токенов- умств, Аноним (-), 18:17 , 10-Апр-26, (18)

Уязвимости были, есть и будут Никто не осиливает Писать низкоуровневый код сло, Сладкая булочка (?), 18:20 , 10-Апр-26, (20)

Вопрос в количестве Вопрос так же в количестве На плохом языке ты можешь получит, Аноним (-), 18:24 , 10-Апр-26, (22)

Про что речь Про безопасные языки Ну вот жс безопасный же А сколько уязвимо, Сладкая булочка (?), 18:31 , 10-Апр-26, (27) –1

А сколько в npm находят уязвимостей типа buffer overflow и double free , Аноним (29), 18:55 , 10-Апр-26, (34) –1

Ну шо ты начинаешь с Тут тебя пытаются убедить что дырявый ЯП еще огого Надо , Аноним (35), 18:59 , 10-Апр-26, (38) –1

Внезапно в расте все это есть , Сладкая булочка (?), 21:40 , 10-Апр-26, (88)

Ясно выше написано, что уязвимости этим не ограничиваются, но похоже ты не читае, Сладкая булочка (?), 21:40 , 10-Апр-26, (87)

Выше ты влез в ветку с обсуждения с набросом про Раст цитата Чтобы на раст н, Аноним (29), 00:02 , 11-Апр-26, (109)

Если бы внимательно прочитал всю ветку, то понял бы, что речь с самого начала шл, Сладкая булочка (?), 00:15 , 11-Апр-26, (112)

нет, его писали на листе бумаги, это ваши современные зоопарки ISA привели к том, Аноним (40), 19:13 , 10-Апр-26, (48)
Да и слава богу, может те другие будет проще выловить А если и нет, то всяко ин, Аноним (57), 19:27 , 10-Апр-26, (57)
Что за булевая логика - есть нет Наличие уязвимостей, это вопрос их количества,, Аноним (101), 23:08 , 10-Апр-26, (97) –2

Не надо свои заскоки на других переносить Проверять этой штукой достаточно перед, Аноним83 (?), 21:18 , 10-Апр-26, (83) +1

Не притормозят, а наоборот закупятся токенами и с помощью ИИ перепишут на Раст , Аноним (29), 19:51 , 10-Апр-26, (68)

А сопровождать кто будет , Сладкая булочка (?), 23:48 , 10-Апр-26, (108)

а представляете, когда-то это все будет работать без косяков и язв , dannyD (?), 17:55 , 10-Апр-26, (4) +1

Никогда не будет Появятся новые типы уязвимостей, и новые способы защиты от них, Аноним (71), 20:37 , 10-Апр-26, (71)

1 все это описанно в книжке Пети Ж -П О чем размышляют роботы советское изд, dannyD (?), 20:56 , 10-Апр-26, (76)
Один из вырожденных сценариев развития с гиперболизацией роли ИИ Почему бы не по, Аноним83 (?), 21:34 , 10-Апр-26, (86)

Два года назад местные диванные экономисты писали буквально то же самое И про , Аноним (29), 22:59 , 10-Апр-26, (96) +1

Местные эксперты тут на 2015 год обещали сингулярность и всех в дворники Но это, Аноним (100), 23:20 , 10-Апр-26, (100)

Оно уже работает лет 5-10 без косяков Падения на цельных данных пролечили, сейча, Аноним83 (?), 21:21 , 10-Апр-26, (84)

Это все ИИ-шески понаходили , Феникс123 (?), 17:57 , 10-Апр-26, (7)

Ну да, ИИ начали учить, дали почитать документы Центра Развлекательных Увлечений, Аноним (90), 00:53 , 11-Апр-26, (119)

Интересно найдут ли ошибки в верифицированной библиотеке hacl Было бы инетерес, Сладкая булочка (?), 17:58 , 10-Апр-26, (8)

Или тот же SPARKNaCL, Аноним (-), 18:25 , 10-Апр-26, (23)
тут уже спеку на анализ давать надо, а не код имплементацию , Аноним (40), 19:07 , 10-Апр-26, (45)

ЕМНИП они заверяли, что там верифицирована работа с памятью Почему бы не попроб, Сладкая булочка (?), 21:04 , 10-Апр-26, (78)

я так понимаю cups чинить уже некому или нашли очередного беднягу за спасибо , 11009 (?), 18:01 , 10-Апр-26, (9) +2

Он используется в куче дистрибутивов линукс и даже в бсд Конечно Сообщество 848, Аноним (-), 18:27 , 10-Апр-26, (24)
А чего было не посмотреть по ссылке в репу - там какая то жисть есть , Аноним83 (?), 21:48 , 10-Апр-26, (91)
Там чинить то особо нечего Все принтеры работают как исполнители кода прилетевш, Аноним (98), 23:10 , 10-Апр-26, (98)

Ну, Ж-стример всегда отличался какчственным кодом Шикарно А ведь в нем уже нахо, Аноним (11), 18:05 , 10-Апр-26, (10) –1

Я так понимаю, Гном так и не засунул в сендбокс эту индексирующую утилиту и оно , Аноним (26), 18:30 , 10-Апр-26, (26)

Как вы себе представляете это в песочнице , Аноним83 (?), 21:52 , 10-Апр-26, (92) +1
От того что ты засунешь процесс в сендбокс, чрутнешь его в tmp null, отнимешь в, Аноним (98), 23:37 , 10-Апр-26, (104)

А сколько уязвимостей может быть не опубликовано в массы а использовано кем над, Аноним (12), 18:09 , 10-Апр-26, (12) +1

То же самое можно и про проприетарный код сказать, и про Rust В последнем вообщ, Аноним (98), 23:48 , 10-Апр-26, (107)

Ха-ха-ха Так их , Аноним (15), 18:09 , 10-Апр-26, (13)

Какая удобная уязвимость , Аноним (90), 00:49 , 11-Апр-26, (117)

nfsd - не проверили размер буфера и получили out-of-bounds writeio_uring - чтени, Аноним (16), 18:12 , 10-Апр-26, (16) +6

Винда 8212 зло , Аноним (41), 19:03 , 10-Апр-26, (41) –1

Да, Аноним (62), 19:34 , 10-Апр-26, (62) +1

Учитывая сколько в io_uring находят всякого - похоже там коду академичности не х, Аноним83 (?), 21:45 , 10-Апр-26, (89)
Как забавно когда баги, которые легко исправляются - это для свидетелей низкоур, Аноним (98), 23:19 , 10-Апр-26, (99) +1

Некоторые баги в принципе не должны возникать Почему программа, содержащая синт, Аноним (101), 23:24 , 10-Апр-26, (102)

Ни один язык не защищает от этого, просто потому что данные, которые тебе отдаёт, Аноним (98), 23:43 , 10-Апр-26, (105)

И что дальше Если ядро не попортило память приложению, то приложение само себе , Аноним (101), 00:13 , 11-Апр-26, (111)

Ахаха 23 года дырени, и нашлась она только благодаря ИИ Ну что, воины против ИИ, Аноним (29), 18:52 , 10-Апр-26, (32)

Если бы ты посмотрел на то как в целом работает NFS, включая юзерспейсные инстру, Аноним (98), 23:27 , 10-Апр-26, (103) +1
тому, что стала неактуальной из-за применения ИИ, который создал более актуа, Аноним (90), 00:48 , 11-Апр-26, (116)

Прикалываются что ли Метаданные WAV даже ардуина восьми битная читает, Oe (?), 19:08 , 10-Апр-26, (46)

Там, эээ, как следствие, формат проприетарный и в нём часто через обруч прыгать , Аноним (50), 19:16 , 10-Апр-26, (50) +1

Ахаха Что-то пилят, всё допилить не могут , Аноним (69), 19:52 , 10-Апр-26, (69)

Сообщения [Сортировка по времени | RSS]

1. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +4 +/–

Сообщение от Аноним (1), 10-Апр-26, 17:36

> 5 уязвимостей, выявленных в ходе экспериментов с инструментарием Claude Code
И это они ещё с мифосом не экспериментировали...

Ответить | Правка | Наверх | Cообщить модератору

70. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +3 +/–

Сообщение от Аноним (70), 10-Апр-26, 20:16

Это ещё даже Алису не попробовали

Ответить | Правка | Наверх | Cообщить модератору

90. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +2 +/–

Сообщение от Аноним (90), 10-Апр-26, 21:47

> через отправку запросов к NFS-серверу узнать содержимое областей памяти ядра. Проблема вызвана ошибкой, проявляющейся начиная с ядра 2.6.0 (2003 год).
Это ведь просто баг, да?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

114. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (114), 11-Апр-26, 00:31

Фича,а вот в БСД это ЦВЕ и не такой старый как эта Линукс-фича.

Ответить | Правка | Наверх | Cообщить модератору

95. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Витюшка (?), 10-Апр-26, 22:43

Разве? Так много ошибок в столь разных проектах - я думаю это оно и есть.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +8 +/–

Сообщение от Аноним (2), 10-Апр-26, 17:39

> OpenClaw
https://days-since-openclaw-cve.com/
Days since last OpenClaw CVE - 0
A new CVE was published in the last 24 hours.
Because who needs security when you have vibes?
Best CVE-less streak - 12 days

Ответить | Правка | Наверх | Cообщить модератору

3. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –5 +/–

Сообщение от Аноним (3), 10-Апр-26, 17:42

Ужас! Зачем нейронку для их выявления сделали?!

Ответить | Правка | Наверх | Cообщить модератору

5. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 17:56

Чтобы на раст не переписывать. Кстати, получается, что не выгодно. Если ошибок с памятью не будет, то кто будет менять деньги на токены. Думаю притормозят внедрение раста.

Ответить | Правка | Наверх | Cообщить модератору

11. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (11), 10-Апр-26, 18:08

Так во все эти проекты (особенно в ядро) каждый релиз добавляют 100500 строк нового кода.
И если бракоделы будут работать как диды, то такие проверки придется делать постоянно.
>Думаю притормозят внедрение раста.
Какой славный копиум)
Так уже в хроме больше чем 1.5 ляма строк раст кода, в андроиде больше 5 лямов.

Ответить | Правка | Наверх | Cообщить модератору

19. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 18:17

> такие проверки придется делать постоянно.
В этом и цель: деньги за токены. В итоге все счастливы.
>>Думаю притормозят внедрение раста.
> Какой славный копиум)
> Так уже в хроме больше чем 1.5 ляма строк раст кода, в
> андроиде больше 5 лямов.
Продолжайте вести наблюдение.

Ответить | Правка | Наверх | Cообщить модератору

21. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Аноним (-), 10-Апр-26, 18:21

> В этом и цель: деньги за токены.
Цель кого?
> В итоге все счастливы.
Если корпе сказать "вам не надо тратить деньги на токены, нужно просто внедрить..." то значительная часть задумается.
> Продолжайте вести наблюдение.
Продолжаю.
Дырявые ЯП будут вытеснены на обочину истории.
Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину.

Ответить | Правка | Наверх | Cообщить модератору

25. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 18:28

>> В итоге все счастливы.
> Если корпе сказать "вам не надо тратить деньги на токены, нужно просто
> внедрить..." то значительная часть задумается.
На чем твоя уверенность, что на переписывание + создание новых уязвимостей тратится меньше денен?
>> Продолжайте вести наблюдение.
> Продолжаю.
> Дырявые ЯП будут вытеснены на обочину истории.
> Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину.
А причина в самой теории вычислимости. Можно только уменьшить симптомы, но проблемы никуда не уйдет.

Ответить | Правка | Наверх | Cообщить модератору

29. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (29), 10-Апр-26, 18:45

>>> Дырявые ЯП будут вытеснены на обочину истории.
>> Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину.
> А причина в самой теории вычислимости
Причина в теории? Ты сам-то хоть понял, что написал? 😂
Нет, причина дыр при работе с памятью - это именно дырявые языки.

Ответить | Правка | Наверх | Cообщить модератору

31. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 18:51

>>>> Дырявые ЯП будут вытеснены на обочину истории.
>>> Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину.
>> А причина в самой теории вычислимости
> Причина в теории? Ты сам-то хоть понял, что написал? 😂
Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует, так как это эквивалентно решению проблемы остановки, что принципиально невозможно. Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями.

Ответить | Правка | Наверх | Cообщить модератору

35. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (35), 10-Апр-26, 18:55

> Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует,
А зачем сразу "всех"?
Давайте начнем с некого класса ошибок, которые не просто самые распространенные причины CVE, но и приводят к очень плохим последствиям.
И распространенность этого класса ошибок можно видеть прям в этой новости.
> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями.
Ну, т.е раз современной пилой можно попасть по пальцу, то давайте махать каменным топором как диды?
Я правильно понял идею?

Ответить | Правка | Наверх | Cообщить модератору

42. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 19:04

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

Ответить | Правка | Наверх | Cообщить модератору

80. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (80), 10-Апр-26, 21:15

> Нет, ты сводишь все
Что "все"?
> к волшебному инструменту, которого нет.
Ты кажется невнимательно читала.
Волшебного инструмента не существует.
Есть развитие инструмента - то что мы наблюдаем всю историю человечества.
От палки-копалки к деревянной лопате, потом к железной, а потом и к миниэкскаватору.
Но некоторые так и остаются с палкой-копалкой.

Ответить | Правка | Наверх | Cообщить модератору

37. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (29), 10-Апр-26, 18:57

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

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

39. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 19:02

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

Ответить | Правка | Наверх | Cообщить модератору

43. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Аноним (43), 10-Апр-26, 19:05

Есть большая разница "у тебя unsafe только в низкоуровневом коде" и "у тебя весь код unsafe и CVEшка может случиться даже при парсинге строки в UI".
Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке будет гораздо легче.

Ответить | Правка | Наверх | Cообщить модератору

49. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 19:14

> Есть большая разница "у тебя unsafe только в низкоуровневом коде" и "у
> тебя весь код unsafe и CVEшка может случиться даже при парсинге
> строки в UI".
> Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке
> будет гораздо легче.
Не будет, т.к. отустуствие ub в unsafe блоке - это допущение, которое не проверяется. Эти проверки уже идут в райнтайме (смотри miri и сколько багов он нашел в safe коде). Это как раз аналогично тому, что в формализме мы говорим "забей, тут все будет выполняться", а по факту оно не выполняется, например, из-за аппаратной ошибки, чем и пользуются экплуатации уязвимостей.

Ответить | Правка | Наверх | Cообщить модератору

56. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (29), 10-Апр-26, 19:25

>> Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке будет гораздо легче.
> Не будет, т.к. отустуствие ub в unsafe блоке - это допущение, которое не проверяется
Конечно будет, потому что количество небезопасного кода сокращается в десятки раз по сравнению с изначальными 100% сишочной лапши. Не говоря уж о том, что вся хитроумная логика и асинхронщина находятся за пределами unsafe.
> например, из-за аппаратной ошибки
Ох как ты ловко спрыгнул с обсуждения языков и алгоритмов на аппаратные ошибки.

Ответить | Правка | Наверх | Cообщить модератору

59. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 19:31

>>> Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке будет гораздо легче.
>> Не будет, т.к. отустуствие ub в unsafe блоке - это допущение, которое не проверяется
> Конечно будет, потому что количество небезопасного кода сокращается в десятки раз по
> сравнению с изначальными 100% сишочной лапши. Не говоря уж о том,
> что вся хитроумная логика и асинхронщина находятся за пределами unsafe.
У тебя любой примитив синхронизации будет с unsafe внутри.
>> например, из-за аппаратной ошибки
> Ох как ты ловко спрыгнул с обсуждения языков и алгоритмов на аппаратные
> ошибки.
Алгоритмы работают в реальном мире на секунду. Если хочешь рассуждать о них в отрыве, то тебе в теоретики, но тогда проблемы с памятью тебя вообще волновать не должны в твоей модели.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

66. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Аноним (29), 10-Апр-26, 19:47

>>  что вся хитроумная логика и асинхронщина находятся за пределами unsafe.
> У тебя любой примитив синхронизации будет с unsafe внутри.
А вся логика снаружи - нет. Об этом как бы и речь.
>>> например, из-за аппаратной ошибки
>> Ох как ты ловко спрыгнул с обсуждения языков и алгоритмов на аппаратные ошибки.
> Алгоритмы работают в реальном мире на секунду. Если хочешь рассуждать о них в отрыве
Программные алгоритмы работают, внезапно, сугубо в пределах программы, и чисто физически не могут иметь отношения к потенциальным аппаратным ошибкам.
Заканчивай чушь нести.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

51. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (29), 10-Апр-26, 19:18

>>> поиск всех уязвимостей
>> Речь про проблемы работы с памятью.
> Про нее и речь.
Нет, ты только что пел буквально про "все уязвимости", а не только те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, я смотрю.
> Ты можешь построить формальную модель, но в реальном мире (особенно низкоуровневом) придется из нее выходить, чтобы что-то сделать, поэтому есть unsafe
Главное, что за пределами unsafe в 95% остального кода этих проблем не будет.
> прочие проблемы с асинхронным кодом.
Давай поподробнее, что это за "проблемы с асинхронностью". Вот с учетом того, что одна из основных целей создания borrow checker была как раз решение всех проблем с асинхронным/многопоточным кодом, а не просто "память не ронять".

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

54. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 19:24

>>>> поиск всех уязвимостей
>>> Речь про проблемы работы с памятью.
>> Про нее и речь.
> Нет, ты только что пел буквально про "все уязвимости", а не только
> те, что вызваны работой с памятью. Ты прямо на лету переобуваешься,
> я смотрю.
Очередной дешевый тролинг с обвинениями? Продолжать не буду.
>> Ты можешь построить формальную модель, но в реальном мире (особенно низкоуровневом) придется из нее выходить, чтобы что-то сделать, поэтому есть unsafe
> Главное, что за пределами unsafe в 95% остального кода этих проблем не
> будет.
Главное не забывать это повторять перед сном.
>> прочие проблемы с асинхронным кодом.
> Давай поподробнее, что это за "проблемы с асинхронностью". Вот с учетом того,
> что одна из основных целей создания borrow checker была как раз
> решение всех проблем с асинхронным/многопоточным кодом, а не просто "память не
> ронять".
Видно, что дальше рекламных буклетов раста ты не смортел. Штош, это было сразу понятно.

Ответить | Правка | Наверх | Cообщить модератору

58. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (29), 10-Апр-26, 19:30

>> Нет, ты только что пел буквально про "все уязвимости", а не только те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, я смотрю.
> Очередной дешевый тролинг с обвинениями?
Нет, просто констатация того факта, что ты переобуваешься на лету и (как теперь очевидно) не в состоянии отвечать за свои собственные слова.
> Главное не забывать это повторять перед сном.
> Видно, что дальше рекламных буклетов раста ты не смортел. Штош, это было сразу понятно.
> Очередной дешевый тролинг
Какая ирония...

Ответить | Правка | Наверх | Cообщить модератору

61. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 19:34

>>> Нет, ты только что пел буквально про "все уязвимости", а не только те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, я смотрю.
>> Очередной дешевый тролинг с обвинениями?
> Нет, просто констатация того факта, что ты переобуваешься на лету и (как
> теперь очевидно) не в состоянии отвечать за свои собственные слова.
У тебя всегда тролинг строится по одной схеме? Мой тебе совет: пора что-то менять, палишься.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

40. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (40), 10-Апр-26, 19:02

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

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

47. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 19:10

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

Ответить | Правка | Наверх | Cообщить модератору

53. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (40), 10-Апр-26, 19:23

> Посмотри формальную верификацию чего-либо околосистемного.
Допустим шедуллер процессов, ввода-вывода, и т.д. и что? Сложно это верифицировать? Думаю даже на оборот, у таких систем строго должна быть описана спека, и всякая имплементация должна быть верифицирована. Не вижу проблемы. Перед тем как писать код какого-либо шедуллера, необходимо написать теоретическую (научную) статью описывающий алгоритм, доказать его корректность и т.д., написать строгую спецификацию с приложениями по имплементации, и только после всего этого писать имплементацию (кодировать), которую собственно потом необходимо верифицировать. А в реальности что? - "я у мамы погромист" или "бабушка, я не нах*р"! :)

Ответить | Правка | Наверх | Cообщить модератору

55. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 19:25

>> Посмотри формальную верификацию чего-либо околосистемного.
> Допустим шедуллер процессов, ввода-вывода, и т.д. и что? Сложно это верифицировать? Думаю даже на оборот
Мне не важно, что ты думаешь. Найди и покажи такую верификацию, а мы посмотрим, где там допущения.

Ответить | Правка | Наверх | Cообщить модератору

60. Скрыто модератором +/–

Сообщение от Аноним (29), 10-Апр-26, 19:32

> Мне не важно, что ты думаешь. Найди и покажи
В общем, ничего содержательного по теме ты выдать больше не способен. Ну ничего: будет тебе уроком больше не бросаться умными терминами, смысла которых ты не понимаешь.

Ответить | Правка | Наверх | Cообщить модератору

63. Скрыто модератором +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 19:37

>> Мне не важно, что ты думаешь. Найди и покажи
> В общем, ничего содержательного по теме ты выдать больше не способен. Ну
> ничего: будет тебе уроком больше не бросаться умными терминами, смысла которых
> ты не понимаешь.
Что, не получилось найти верификацию? А должно было быть "просто" как ты говорил https://www.opennet.dev/openforum/vsluhforumID3/139772.html#53 Ну ничего, сейчас щеки надуем, неберем побольше воздуха и выдадим грозный комментарий. Получается, ты бумажный тигр?)

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

67. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Аноним (40), 10-Апр-26, 19:48

> Найди и покажи такую верификацию
Вот
//sel4.systems/Verification/proofs.html
//sel4.systems/Verification/implications.html
//sel4.systems/Verification/assumptions.html
> Мне не важно, что ты думаешь.
Ясно, понятно, только я не тот аноним с которым ты выше троллишся.

Ответить | Правка | Наверх | Cообщить модератору

74. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 20:52

>> Найди и покажи такую верификацию
> Вот
> //sel4.systems/Verification/proofs.html
> //sel4.systems/Verification/implications.html
> //sel4.systems/Verification/assumptions.html
А внутрь ты смотрел?
Доказывают они, на самом деле, свойства урезанной статичной версии ядра https://github.com/seL4/l4v/blob/59b2d2f630119be823f3f444651...
> This specification is a cut-down version of the seL4 abstract specification
> that removes all system calls apart from notifications. The resulting kernel
> is a classic static separation kernel without any dynamism.
>
> A proof that seL4 is equivalent to this cut-down version if configured
> appropriately can be found in the `proof` directory under
> [`bisim`](../../proof/bisim/).
Переходим https://github.com/seL4/l4v/tree/59b2d2f630119be823f3f444651... и читаем
> This proof establishes that seL4, if configured fully statically with 1-level CSpaces and notification caps only, is bi-similar to a static separation kernel that has no other system calls than signalling notifications.
То есть, доказательтво проводится на статичной конфигурации с тривиальным менеджером памяти, который на практике бесполезен.
При этом надежность микроядерной архитектуры надежная, никто не спорит.

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

115. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (40), 11-Апр-26, 00:48

> А внутрь ты смотрел?
ой все понятно, ЫЫ-шный бот очередной.
Вот https://github.com/seL4/l4v/blob/master/README.md
Overview
The repository is organised as follows.
spec: a number of different formal specifications of seL4
    abstract: the functional abstract specification of seL4
    sep-abstract: an abstract specification for a reduced version of seL4 that is configured as a separation kernel
Что ты мне на урезанную спеку указываешь? Ты в директорию abstract смотри.
А вот директория доказательств.
//github.com/seL4/l4v/blob/master/proof/README.md
This directory contains the formal proofs about seL4, which mostly prove properties about the various seL4 specifications.
Each such proof lives in its own subdirectory:
access-control - Access Control Proof
asmrefine - Assembly Refinement Proof
bisim - Bisimilarity of seL4 with a static Separation Kernel
capDL-api - CapDL API Proofs
crefine - C Refinement Proof
drefine - CapDL Refinement Proof
infoflow - Confidentiality Proof
invariant-abstract - Abstract Spec Invariant Proof
refine - Design Spec Refinement Proof
sep-capDL - CapDL Separation Logic Proof
A proof that seL4 is equivalent to this cut-down version if configured appropriately can be found in the proof directory under bisim.
перевод нужен?
> Переходим в bisim и читаем
там еще куча других директорий пройдись по ним тоже.
> То есть, доказательтво проводится на статичной конфигурации с тривиальным менеджером памяти, который на практике бесполезен.
бред!!! Вот все доказательства
access-control - Access Control Proof
asmrefine - Assembly Refinement Proof
bisim - Bisimilarity of seL4 with a static Separation Kernel
capDL-api - CapDL API Proofs
crefine - C Refinement Proof
drefine - CapDL Refinement Proof
infoflow - Confidentiality Proof
invariant-abstract - Abstract Spec Invariant Proof
refine - Design Spec Refinement Proof
sep-capDL - CapDL Separation Logic Proof

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

44. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Аноним (29), 10-Апр-26, 19:06

> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями.
Ты не понимаешь, что несешь. При формальной верификации кода для каждой функции, ее аргументов и их типов жестко задаются пред/пост-условия и инварианты, и если они отсутствуют или не полны, то верификатор просто откажется дать тебе ответ.
Ты бы хоть посмотрел, как это работает в том же Ada/Spark, прежде чем умными словами бросаться. Допущениями решается, блждад...

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

52. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +2 +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 19:19

>> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями.
> Ты не понимаешь, что несешь. При формальной верификации кода для каждой функции,
> ее аргументов и их типов жестко задаются пред/пост-условия и инварианты, и
> если они отсутствуют или не полны, то верификатор просто откажется дать
> тебе ответ.
Ну дак это искусственные условия. На практике многие утверждения приходится аксиоматизировать. Что-то остается недоказанным. Что-то приходится допускать.
> Ты бы хоть посмотрел, как это работает в том же Ada/Spark, прежде
> чем умными словами бросаться. Допущениями решается, блждад...
Покажи мне на ada/spark формально верифицированный аллокатор, например.

Ответить | Правка | Наверх | Cообщить модератору

64. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Аноним (29), 10-Апр-26, 19:38

> Ну дак это искусственные условия. На практике многие утверждения приходится аксиоматизировать. Что-то остается недоказанным. Что-то приходится допускать.
Это как раз не исукственные условия - это условия, которые ты контролируешь на уровне алгоритма. Все поведение за пределами алгоритма (например, сломанное железо) к самому алгоритму и его реализации в коде отношения не имеет, и, соответсвенно, чисто физически не сожет быть математически верифицируемым.
Это как бы очевидно, не?

Ответить | Правка | Наверх | Cообщить модератору

77. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 20:56

>> Ну дак это искусственные условия. На практике многие утверждения приходится аксиоматизировать. Что-то остается недоказанным. Что-то приходится допускать.
> Это как раз не исукственные условия - это условия, которые ты контролируешь
> на уровне алгоритма. Все поведение за пределами алгоритма (например, сломанное железо)
> к самому алгоритму и его реализации в коде отношения не имеет,
> и, соответсвенно, чисто физически не сожет быть математически верифицируемым.
> Это как бы очевидно, не?
Нет. Это выставление условий модели удобных для доказательства. В sel4 доказывают не про исходник, а про модель на haskell, доказывают не полные свойства, а некоторые урезанные варианты, в урезанных конфигурациях.

Ответить | Правка | Наверх | Cообщить модератору

118. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (40), 11-Апр-26, 00:50

> В sel4 доказывают не про исходник, а про модель на haskell, доказывают не полные свойства, а некоторые урезанные варианты, в урезанных конфигурациях.
п*здешь и провокация, открой директорию proof

Ответить | Правка | Наверх | Cообщить модератору

65. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –2 +/–

Сообщение от Аноним (40), 10-Апр-26, 19:46

> Ну дак это искусственные условия. На практике многие утверждения приходится аксиоматизировать. Что-то остается недоказанным. Что-то приходится допускать.
Так и есть, но это ведь не самообман, вы говорите за формальную верификацию как за самообман, тоже самое можно сказать про всю математику, где есть допущения, аксиомы и другие "неловкие" моменты, и все сведется к тому, а что есть собственно понятие - "доказать" (формально доказать). Брауэр вообще не признавал доказательства от противного :)
Вот seL4 описали эти моменты:
//sel4.systems/Verification/proofs.html
//sel4.systems/Verification/implications.html
//sel4.systems/Verification/assumptions.html
А вот тут про ironclad-os:
//ironclad-os.org/formalverification.html

Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

75. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 20:53

>[оверквотинг удален]
> верификацию как за самообман, тоже самое можно сказать про всю математику,
> где есть допущения, аксиомы и другие "неловкие" моменты, и все сведется
> к тому, а что есть собственно понятие - "доказать" (формально доказать).
> Брауэр вообще не признавал доказательства от противного :)
> Вот seL4 описали эти моменты:
> //sel4.systems/Verification/proofs.html
> //sel4.systems/Verification/implications.html
> //sel4.systems/Verification/assumptions.html
> А вот тут про ironclad-os:
> //ironclad-os.org/formalverification.html
Ответил здесь https://www.opennet.dev/openforum/vsluhforumID3/139772.html#74

Ответить | Правка | Наверх | Cообщить модератору

33. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (40), 10-Апр-26, 18:53

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

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

101. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (101), 10-Апр-26, 23:21

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

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

106. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 23:43

>>А причина в самой теории вычислимости. Можно только уменьшить симптомы, но проблемы никуда не уйдет.
> Вы забыли привести доказательства.
Доказательство чего? Проблемы останова? Интернет в помощь.
> Проблему разыменновывания нулевого указателя можно
> решить очень просто. Проблему выхода за границы массива можно решить чуть
> сложнее. И так далее.
Можно решить обе проблемы ценой производительности или созданием сложной формализованной системы, которую придется обходить в низкоуровневом коде (привет unsafe).

Ответить | Правка | Наверх | Cообщить модератору

110. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Аноним (101), 11-Апр-26, 00:10

>Проблемы останова?
Как связана проблема останова и разыменновывание нулевого указателя?
>Можно решить обе проблемы ценой производительности
А то что, память не успеете попортить?
>которую придется обходить в низкоуровневом коде (привет unsafe)
Вы опять забыли приветси доказательство того, что разыменноывание нулевого указателя, ровно как и выход за границу массива, нужно обходить. Но, даже если вы вдруг окажитесь правы, в чём лично я соменваюсь, то из этого всё равно не следует вывод, что unsafe блоки в этом языке будут хуже, чем язык, который целиком состоит из unsafe.

Ответить | Правка | Наверх | Cообщить модератору

113. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Сладкая булочка (?), 11-Апр-26, 00:17

>>Проблемы останова?
> Как связана проблема останова и разыменновывание нулевого указателя?
Ты мне ответь, если с самого начала речь шла про теорию вычислимости и проблему останова.
>>Можно решить обе проблемы ценой производительности
> А то что, память не успеете попортить?
Прикидываться идиотом тебе идет, продолжай.
>>которую придется обходить в низкоуровневом коде (привет unsafe)
> Вы опять забыли приветси доказательство того, что разыменноывание нулевого указателя,
> ровно как и выход за границу массива, нужно обходить. Но, даже
> если вы вдруг окажитесь правы, в чём лично я соменваюсь, то
> из этого всё равно не следует вывод, что unsafe блоки в
> этом языке будут хуже, чем язык, который целиком состоит из unsafe.
На этот бред нет никакого смысла отвечать. Ты сначала перечитай, а потом что-то там требуй.

Ответить | Правка | Наверх | Cообщить модератору

79. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним83 (?), 10-Апр-26, 21:15

Да да, "The RUST crowd" :)

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

15. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (15), 10-Апр-26, 18:12

> Думаю притормозят внедрение раста.
И кто же, интересно, эти те кто притормозят?

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

17. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 18:15

>> Думаю притормозят внедрение раста.
> И кто же, интересно, эти те кто притормозят?
Те же, кто дают команду на внедрение.

Ответить | Правка | Наверх | Cообщить модератору

18. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (-), 10-Апр-26, 18:17

ОНИ!
Судя по всему мысля такова:
- подобные проверки требуют много токенов
- умственноотсталые будут делать одни и те же уязвимости, как они делают c 1972 года
- поэтому проверки надо будет делать постоянно, желательно после каждого коммита
- следовательно компании предоставляющие ЫЫ инфраструктуру смогут заработать много денег
Идея в общем-то имеет какую-то логику, но вопрос "а нафига это корпам которые код пишут" остается открытым.
Не проще ли выкинуть на мороз тех, кто не осиливает новые технологии?

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

20. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 18:20

> Идея в общем-то имеет какую-то логику, но вопрос "а нафига это корпам
> которые код пишут" остается открытым.
> Не проще ли выкинуть на мороз тех, кто не осиливает новые технологии?
Уязвимости были, есть и будут. Никто не осиливает. Писать низкоуровневый код сложно. Да даже без этого уязвимости будут, только другие. А корпам выгодно иметь дешевых разработчиков. Думайте.

Ответить | Правка | Наверх | Cообщить модератору

22. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (-), 10-Апр-26, 18:24

> Уязвимости были, есть и будут.
Вопрос в количестве.
> Никто не осиливает.
Вопрос так же в количестве)
На плохом языке ты можешь получить рут просто нажав backspace 28 раз.
> Писать низкоуровневый код сложно.
Особенно если использовать для написания инструменты прошлого тысячелетия.
> Да даже без этого уязвимости будут, только другие.
Т.е мы избавимся от части уязвимостей? Ну так это отлично.
> А корпам выгодно иметь дешевых разработчиков.
А еще они любят срезать косты на других направлениях.

Ответить | Правка | Наверх | Cообщить модератору

27. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 18:31

>> Уязвимости были, есть и будут.
> Вопрос в количестве.
Про что речь? Про "безопасные языки"? Ну вот жс безопасный же. А сколько уязвимостей в npm находят. Вот и думай.

Ответить | Правка | Наверх | Cообщить модератору

34. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Аноним (29), 10-Апр-26, 18:55

> Ну вот жс безопасный же. А сколько уязвимостей в npm находят.
А сколько в npm находят уязвимостей типа buffer overflow и double free?

Ответить | Правка | Наверх | Cообщить модератору

38. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Аноним (35), 10-Апр-26, 18:59

Ну шо ты начинаешь?! (с)

Тут тебя пытаются убедить что дырявый ЯП еще огого!
Надо не только обмазать овнокод санитайзарами, фаззерами, но и запускать регулярную ИИшку.

Ответить | Правка | Наверх | Cообщить модератору

88. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 21:40

> Ну шо ты начинаешь?! (с)
> Надо не только обмазать овнокод санитайзарами, фаззерами, но и запускать регулярную ИИшку.
Внезапно в расте все это есть.

Ответить | Правка | Наверх | Cообщить модератору

87. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 21:40

>> Ну вот жс безопасный же. А сколько уязвимостей в npm находят.
> А сколько в npm находят уязвимостей типа buffer overflow и double free?
Ясно выше написано, что уязвимости этим не ограничиваются, но похоже ты не читаешь. А подобные ошибки в v8 или spider monkey находят регулярно https://app.opencve.io/cve/?product=v8&vendor=google

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

109. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (29), 11-Апр-26, 00:02

>>> Ну вот жс безопасный же. А сколько уязвимостей в npm находят.
>> А сколько в npm находят уязвимостей типа buffer overflow и double free?
> Ясно выше написано, что уязвимости этим не ограничиваются, но похоже ты не читаешь
Выше ты влез в ветку с обсуждения с набросом про Раст (цитата): "Чтобы на раст не переписывать. [..] Если ошибок с памятью не будет" И даже вон про ошибки с памятью сразу упомянул.
А теперь прикидываешься валенком и пытаешься съехать с темы. Да еще и приплетаешь соломенные чучела в виде V8 и Spidermokey, которые на C++. Да еще и в ответ на свой же вброс про js и npm.
Просто фантастический инфантилизм.

Ответить | Правка | Наверх | Cообщить модератору

112. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 11-Апр-26, 00:15

>>>> Ну вот жс безопасный же. А сколько уязвимостей в npm находят.
>>> А сколько в npm находят уязвимостей типа buffer overflow и double free?
>> Ясно выше написано, что уязвимости этим не ограничиваются, но похоже ты не читаешь
> Выше ты влез в ветку с обсуждения с набросом про Раст (цитата):
> "Чтобы на раст не переписывать. [..] Если ошибок с памятью не
> будет" И даже вон про ошибки с памятью сразу упомянул.
Если бы внимательно прочитал всю ветку, то понял бы, что речь с самого начала шла про ошибки не только с памятью. Но ты как обычно увидел "раст" и сразу начал писать оскорбления.
> Да еще и приплетаешь соломенные чучела в виде V8 и Spidermokey, которые на C++.
> Да еще и в ответ на свой же вброс про js и npm.
Вообще-то это очень использумые проекты, как бы ты к ним не относился. А суть проста (опять же, если бы ты не прочитал), то понял, что речь идет о копиляторе и среде исполнения, на которую можно провести атаку из "безопасного" языка.

Ответить | Правка | Наверх | Cообщить модератору

48. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (40), 10-Апр-26, 19:13

> Писать низкоуровневый код сложно
нет, его писали на листе бумаги, это ваши современные зоопарки ISA привели к тому, что обычному студенту в лом читать 4000 страниц референс мануала по архитектуре ЦПУ, который через полгода будет выкинут на свалку, потому-что и ЦПУ проектирует такие же "дятлы" в угоду прибыли. Архитектура Фон-Неймана - кал!!!

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

57. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (57), 10-Апр-26, 19:27

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

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

97. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –2 +/–

Сообщение от Аноним (101), 10-Апр-26, 23:08

>Да даже без этого уязвимости будут, только другие.
Что за булевая логика - есть/нет? Наличие уязвимостей, это вопрос их количества, и их вида. Когда сишник пишет код, он допускает как ошибки управления памятью, так и другие ошибки, вроде неправильной проверки имени файлов. И как бы сишники не бахвалились, от того, что они вручную управляют памятью, другие ошибки никуда не исчезают.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

83. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Аноним83 (?), 10-Апр-26, 21:18

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

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

68. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (29), 10-Апр-26, 19:51

> Если ошибок с памятью не будет, то кто будет менять деньги на токены.
> Думаю притормозят внедрение раста.
Не притормозят, а наоборот: закупятся токенами и с помощью ИИ перепишут на Раст еще быстрее.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

108. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 23:48

> перепишут
А сопровождать кто будет?

Ответить | Правка | Наверх | Cообщить модератору

4. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от dannyD (?), 10-Апр-26, 17:55

а представляете, когда-то это все будет работать без косяков и язв!

Ответить | Правка | Наверх | Cообщить модератору

71. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (71), 10-Апр-26, 20:37

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

Ответить | Правка | Наверх | Cообщить модератору

76. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от dannyD (?), 10-Апр-26, 20:56

1. все это описанно в книжке Пети Ж.-П. "О чем размышляют роботы?" советское издание 1987 год, оригинал 1982 год.
В книге известного французского ученого дается оригинальное изложение основных тенденций развития роботов с программным управлением, адаптацией и элементами искусственного интеллекта, построенное на многочисленных забавных иллюстрациях. Однако такая занимательность подачи материала не означает элементарности содержания.
2. Проблематика "современной" математики, широкой публике непонятна уже более тысячи лет.
и что?

Ответить | Правка | Наверх | Cообщить модератору

86. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним83 (?), 10-Апр-26, 21:34

Один из вырожденных сценариев развития с гиперболизацией роли ИИ.
Почему бы не посмотреть на проблему с другой стороны: пузырь ИИ лопнет в ближайший 1-2 года ибо туда инвестированы миллиарды, которые пошли на ДЦ и электричество, а отдачи этих инвестиций НЕТ и не планируется.
Проверки кода, генерация ИИ бреда - это всё не даст и 1% возврата потраченного.
Обучение новых моделей стоит всё дороже, плюс данных для обучения всё меньше.
Можете вспомнить мегахайп про блокчейн 5 лет назад - и где оно теперь?
(этим как пользовались полтора фрика так и дальше пользуются)
Если взглянуть глобально то человечество подошло к порогу своего развития, когда требуется глубокий рефакторинг.
И кремниевые технологии достигли своего физического предела.
И знания нуждаются в переработке и очистке: написано 100500 книг, многие из которых не содержат ничего нового, иногда там откровенное враньё. Те данные для обучения нуждаются в чистке.
Без этого не получится шагнуть дальше: энергии и производительности не хватит, а загружая мусор в обучащую выборку - будет такой же мусор на выходе.
Дурачки за которых ИИ думает - есть уже сейчас. Раньше такие были в религии в основном.

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

96. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Аноним (29), 10-Апр-26, 22:59

> пузырь ИИ лопнет в ближайший 1-2 года
> И кремниевые технологии достигли своего физического предела.
Два года назад местные диванные экономисты писали буквально то же самое. И про "уперлись в технический предел". Но в этот раз точно сбудется, да?
Тебе самому-то не смешно?
> Можете вспомнить мегахайп про блокчейн 5 лет назад - и где оно теперь?
Там же, где и был - в крипте. Кстати, что там по ней? Уже больше 15 лет диванные экономисты предрекают ее крах "вот-вот, совсем скоро уже!".

Ответить | Правка | Наверх | Cообщить модератору

100. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (100), 10-Апр-26, 23:20

> Два года назад местные диванные экономисты писали буквально то же самое. И про "уперлись в технический предел". Но в этот раз точно сбудется, да?
Местные эксперты тут на 2015 год обещали сингулярность и всех в дворники. Но это надо понимать другое?
> Там же, где и был - в крипте. Кстати, что там по ней? Уже больше 15 лет диванные экономисты предрекают ее крах "вот-вот, совсем скоро уже!".
Как там недиванные? "Ещё пару лет и все банки с свифтами закончатся, всё в крипте" - этому тезису уже больше 15 лет. Или тут тоже не помним?

Ответить | Правка | Наверх | Cообщить модератору

84. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним83 (?), 10-Апр-26, 21:21

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

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

7. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Феникс123 (?), 10-Апр-26, 17:57

Это все ИИ-шески понаходили?

Ответить | Правка | Наверх | Cообщить модератору

119. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (90), 11-Апр-26, 00:53

Ну да, ИИ начали учить, дали почитать документы Центра Развлекательных Увлечений, там столько интересного нашлось, что ИИ смог рассказать про баги в ядре.

Ответить | Правка | Наверх | Cообщить модератору

8. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 17:58

Интересно найдут ли ошибки в верифицированной библиотеке hacl*? Было бы инетересно.

Ответить | Правка | Наверх | Cообщить модератору

23. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (-), 10-Апр-26, 18:25

Или тот же SPARKNaCL

Ответить | Правка | Наверх | Cообщить модератору

45. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (40), 10-Апр-26, 19:07

тут уже спеку на анализ давать надо, а не код (имплементацию)

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

78. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Сладкая булочка (?), 10-Апр-26, 21:04

> тут уже спеку на анализ давать надо, а не код (имплементацию)
ЕМНИП они заверяли, что там верифицирована работа с памятью. Почему бы не попробовать найти вулны в генерированном си коде?

Ответить | Правка | Наверх | Cообщить модератору

9. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +2 +/–

Сообщение от 11009 (?), 10-Апр-26, 18:01

я так понимаю cups чинить уже некому? или нашли очередного беднягу за спасибо?

Ответить | Правка | Наверх | Cообщить модератору

24. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (-), 10-Апр-26, 18:27

Он используется в куче дистрибутивов линукс и даже в бсд.
Конечно Сообщество™ не может скинуться по копейке, чтобы нанять человека.
Как говорится: узрите силу Сообщества™

Ответить | Правка | Наверх | Cообщить модератору

91. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним83 (?), 10-Апр-26, 21:48

А чего было не посмотреть по ссылке в репу?! - там какая то жисть есть.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

98. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (98), 10-Апр-26, 23:10

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

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

10. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Аноним (11), 10-Апр-26, 18:05

> GStreamer - 11 уязвимостей: 3 переполнением буфера и 8 уязвимостей вызваны целочисленным переполнением или разыменованием нулевого указателя
Ну, Ж-стример всегда отличался какчственным кодом))
> CUPS - 8 уязвимостей, две могут использоваться для организации удалённого выполнения своего кода с правами root
Шикарно!
А ведь в нем уже находили подобную дырень.
> NixOS - Уязвимость даёт возможность перезаписать любой файл в системе ... с правами root. Проблема вызвана некорректным устранением уязвимости CVE-2024-27297 в 2024 году.
А как дышали, как дышали!
> В ядре Linux устранено 5 уязвимостей, выявленных в ходе экспериментов с инструментарием Claude Code
Даже дырявый опенклод находит уязвимости в ядре.

Ответить | Правка | Наверх | Cообщить модератору

26. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (26), 10-Апр-26, 18:30

> Ну, Ж-стример всегда отличался какчственным кодом))
Я так понимаю, Гном так и не засунул в сендбокс эту индексирующую утилиту и оно до сих пор выполняет все скачанные файлы просто так?

Ответить | Правка | Наверх | Cообщить модератору

92. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Аноним83 (?), 10-Апр-26, 21:52

Как вы себе представляете это в песочнице?

Ответить | Правка | Наверх | Cообщить модератору

104. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (98), 10-Апр-26, 23:37

От того что ты засунешь процесс в сендбокс, чрутнешь его в /tmp/null, отнимешь все привилегии и setuidнешь его в 2^32-1, багованный код менее багованным не станет и любая неправильно прочитанная пнгшка сможет например задудосить твой комп. Просто нужно выкидывать на мороз фреймворки (GObjectы всякие) с абстракциями и писать парсеры файлов и форматов напрямую как чтение байтиков из памяти. Все файловые форматы - это поток данных от начала и до конца с определёнными опкодами, меняющими состояние парсера.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

12. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Аноним (12), 10-Апр-26, 18:09

А сколько уязвимостей может быть не опубликовано в массы а использовано "кем надо" и даже "кем не надо".

Ответить | Правка | Наверх | Cообщить модератору

107. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (98), 10-Апр-26, 23:48

То же самое можно и про проприетарный код сказать, и про Rust. В последнем вообще баги приходится находить в рантайме в коде ядра, как показывает практика. "ЫЫЫЫ, ЗАТО Я,ЯЯЯ ВЫЗВАЛ КРАШ С ЛОГОМ, А НЕ ЯДРО ПАНИКАНУЛО/ БРАУЗЕР ПРИШИБЛО СЕГФОЛТОМ"

Ответить | Правка | Наверх | Cообщить модератору

13. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (15), 10-Апр-26, 18:09

> помечена как неопасная так как она проявляется только на 32-разрядных платформах
Ха-ха-ха. Так их!

Ответить | Правка | Наверх | Cообщить модератору

117. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (90), 11-Апр-26, 00:49

Какая удобная уязвимость!

Ответить | Правка | Наверх | Cообщить модератору

16. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +6 +/–

Сообщение от Аноним (16), 10-Апр-26, 18:12

> В ядре Linux устранено 5 уязвимостей,
nfsd - не проверили размер буфера и получили out-of-bounds write
io_uring - чтение за пределами буфера
ksmbd - конвертили unsigned 32 в signed int (как же хорошо что язык это делает неявно) и получили heap buffer overflow
- race condition
и futex забыли (или забили?) на проверить могут ли флаги не совпадать
В общем все как обычно))

Ответить | Правка | Наверх | Cообщить модератору

41. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." –1 +/–

Сообщение от Аноним (41), 10-Апр-26, 19:03

> В общем все как обычно))
Винда — зло?

Ответить | Правка | Наверх | Cообщить модератору

62. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Аноним (62), 10-Апр-26, 19:34

Да

Ответить | Правка | Наверх | Cообщить модератору

89. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним83 (?), 10-Апр-26, 21:45

Учитывая сколько в io_uring находят всякого - похоже там коду академичности не хватило чтобы сделать нормальное архитектурное решение, которое бы не плодило баги в реализации.
> race condition
> futex забыли (или забили?)
Не всегда требуется жёсткая синхронизация через мьютексы и пр, иногда можно забить.
Например, для балансировщика нагрузки не критично если случится race и кто то получит чуть больше/меньше заданий.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

99. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Аноним (98), 10-Апр-26, 23:19

Как забавно когда баги, которые легко исправляются - это для свидетелей "низкоуровневая работа с памятью должна быть уничтожена" (когда компьютеры буквально только для этого и нужны - читать данные, менять их и писать обратно) большая причина хейтить Линукс, чем переписывание рандомных участков кода который никому не мешал всякими рандомами с "солидными" доменами в коммитах приводят к паникам на системах x86_64 пятилетней давности, выкидыванию на помойку "устаревших" GPU просто потому что чип контроллера переписали на "более красивый лад" "протестив" его работу в виртуалке на макоси/винде, а работающий код выпиливают из ядра потому что "нету мейнтейнера" - буквально должности тела с печатью "я проверил, мамой клянусь"м

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

102. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (101), 10-Апр-26, 23:24

>Как забавно когда баги, которые легко исправляются
Некоторые баги в принципе не должны возникать. Почему программа, содержащая синтаксическую ошибку не компилируется, а программа, содержащая разыменновывание нулевого указателя/выходящая за пределы массива - не просто компилируется, а ещё и память портит?

Ответить | Правка | Наверх | Cообщить модератору

105. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (98), 10-Апр-26, 23:43

> программа, содержащая разыменновывание нулевого указателя/выходящая за пределы массива - не просто компилируется, а ещё и память портит?
Ни один язык не защищает от этого, просто потому что данные, которые тебе отдаёт операционная система - это просто набор байтиков с длинной. Что внутри них ядро не интересует, и как это интерпретирует Rust код, написанный внутри unsafe потому что ты буквально создаёшь новый вид на память из непроверяемых никак кроме самописной логикой данных из буфера, лежит уже на совести того, кому ты делегировал писать unsafe код.

Ответить | Правка | Наверх | Cообщить модератору

111. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (101), 11-Апр-26, 00:13

>просто потому что данные, которые тебе отдаёт операционная система - это просто набор байтиков с длинной
И что дальше? Если ядро не попортило память приложению, то приложение само себе память портить не должно.

Ответить | Правка | Наверх | Cообщить модератору

32. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (29), 10-Апр-26, 18:52

> В ядре Linux
> Уязвимость в драйвере NFS
> начиная с ядра 2.6.0 (2003 год).
> Claude Code
Ахаха! 23 года дырени, и нашлась она только благодаря ИИ.
Ну что, воины против ИИ, ваш выход! "Лже-ИИ бесполезен", говорили они. "Лже-ИИ ничего не пониает", говорили они. "Лже-ИИ разбирается только на том, на чем был натренирован", говорили они...

Ответить | Правка | Наверх | Cообщить модератору

103. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Аноним (98), 10-Апр-26, 23:27

Если бы ты посмотрел на то как в целом работает NFS, включая юзерспейсные инструменты и что они делают с файловой системой (спойлер - рут рутом погоняет и исполняет рандомные пожелания чего угодно, прилетевшего на сокет, который ты даже отдебажить не можешь потому что этот сокет открывается и читается самим драйвером в ядре), то ты бы уже сам давно написал бы юзерспейсную имплементацию на fuse. Это такая же бредятина, как и запихивание драйверов для VPN типа OpenVPN и Wireguard в ядро вместо того чтобы добавлять механизмы для более эффективного контроля пакетов из юзерспейса.

Ответить | Правка | Наверх | Cообщить модератору

116. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (90), 11-Апр-26, 00:48

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

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

46. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Oe (?), 10-Апр-26, 19:08

> обработке данных в форматах WAV
Прикалываются что ли? Метаданные WAV даже ардуина восьми битная читает

Ответить | Правка | Наверх | Cообщить модератору

50. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +1 +/–

Сообщение от Аноним (50), 10-Апр-26, 19:16

Там, эээ, как следствие, формат проприетарный и в нём часто через обруч прыгать надо. Как видим, это умеют не только лишь все. Лично мне приходилось патчить туеву хучу софта, чтобы WAVE_FORMAT с fffe поддерживался, иначе файлы тупо не определялись. Показательно.

Ответить | Правка | Наверх | Cообщить модератору

69. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..." +/–

Сообщение от Аноним (69), 10-Апр-26, 19:52

Ахаха... Что-то пилят, всё допилить не могут!

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+4 +/–
Сообщение от Аноним (1), 10-Апр-26, 17:36
> 5 уязвимостей, выявленных в ходе экспериментов с инструментарием Claude Code И это они ещё с мифосом не экспериментировали...
Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+3 +/–
	Сообщение от Аноним (70), 10-Апр-26, 20:16
	Это ещё даже Алису не попробовали
	Ответить \| Правка \| Наверх \| Cообщить модератору


	90. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+2 +/–
	Сообщение от Аноним (90), 10-Апр-26, 21:47
	> через отправку запросов к NFS-серверу узнать содержимое областей памяти ядра. Проблема вызвана ошибкой, проявляющейся начиная с ядра 2.6.0 (2003 год). Это ведь просто баг, да?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	114. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Аноним (114), 11-Апр-26, 00:31
	Фича,а вот в БСД это ЦВЕ и не такой старый как эта Линукс-фича.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	95. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Витюшка (?), 10-Апр-26, 22:43
	Разве? Так много ошибок в столь разных проектах - я думаю это оно и есть.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору

2. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+8 +/–
Сообщение от Аноним (2), 10-Апр-26, 17:39
> OpenClaw https://days-since-openclaw-cve.com/ Days since last OpenClaw CVE - 0 A new CVE was published in the last 24 hours. Because who needs security when you have vibes? Best CVE-less streak - 12 days
Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	–5 +/–
Сообщение от Аноним (3), 10-Апр-26, 17:42
Ужас! Зачем нейронку для их выявления сделали?!
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 17:56
	Чтобы на раст не переписывать. Кстати, получается, что не выгодно. Если ошибок с памятью не будет, то кто будет менять деньги на токены. Думаю притормозят внедрение раста.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Аноним (11), 10-Апр-26, 18:08
	Так во все эти проекты (особенно в ядро) каждый релиз добавляют 100500 строк нового кода. И если бракоделы будут работать как диды, то такие проверки придется делать постоянно. >Думаю притормозят внедрение раста. Какой славный копиум) Так уже в хроме больше чем 1.5 ляма строк раст кода, в андроиде больше 5 лямов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+1 +/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 18:17
	> такие проверки придется делать постоянно. В этом и цель: деньги за токены. В итоге все счастливы. >>Думаю притормозят внедрение раста. > Какой славный копиум) > Так уже в хроме больше чем 1.5 ляма строк раст кода, в > андроиде больше 5 лямов. Продолжайте вести наблюдение.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+1 +/–
	Сообщение от Аноним (-), 10-Апр-26, 18:21
	> В этом и цель: деньги за токены. Цель кого? > В итоге все счастливы. Если корпе сказать "вам не надо тратить деньги на токены, нужно просто внедрить..." то значительная часть задумается. > Продолжайте вести наблюдение. Продолжаю. Дырявые ЯП будут вытеснены на обочину истории. Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 18:28
	>> В итоге все счастливы. > Если корпе сказать "вам не надо тратить деньги на токены, нужно просто > внедрить..." то значительная часть задумается. На чем твоя уверенность, что на переписывание + создание новых уязвимостей тратится меньше денен? >> Продолжайте вести наблюдение. > Продолжаю. > Дырявые ЯП будут вытеснены на обочину истории. > Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину. А причина в самой теории вычислимости. Можно только уменьшить симптомы, но проблемы никуда не уйдет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Аноним (29), 10-Апр-26, 18:45
	>>> Дырявые ЯП будут вытеснены на обочину истории. >> Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину. > А причина в самой теории вычислимости Причина в теории? Ты сам-то хоть понял, что написал? 😂 Нет, причина дыр при работе с памятью - это именно дырявые языки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 18:51
	>>>> Дырявые ЯП будут вытеснены на обочину истории. >>> Спасти ИИшка тут не поможет, так как устряняет симптомы, а не причину. >> А причина в самой теории вычислимости > Причина в теории? Ты сам-то хоть понял, что написал? 😂 Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует, так как это эквивалентно решению проблемы остановки, что принципиально невозможно. Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Аноним (35), 10-Апр-26, 18:55
	> Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует, А зачем сразу "всех"? Давайте начнем с некого класса ошибок, которые не просто самые распространенные причины CVE, но и приводят к очень плохим последствиям. И распространенность этого класса ошибок можно видеть прям в этой новости. > Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями. Ну, т.е раз современной пилой можно попасть по пальцу, то давайте махать каменным топором как диды? Я правильно понял идею?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 19:04
	>> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями. > Ну, т.е раз современной пилой можно попасть по пальцу, то давайте махать > каменным топором как диды? > Я правильно понял идею? Нет, ты сводишь все к волшебному инструменту, которого нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Аноним (80), 10-Апр-26, 21:15
	> Нет, ты сводишь все Что "все"? > к волшебному инструменту, которого нет. Ты кажется невнимательно читала. Волшебного инструмента не существует. Есть развитие инструмента - то что мы наблюдаем всю историю человечества. От палки-копалки к деревянной лопате, потом к железной, а потом и к миниэкскаватору. Но некоторые так и остаются с палкой-копалкой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Аноним (29), 10-Апр-26, 18:57
	> Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует А никто и не говорит про все. Речь про проблемы работы с памятью.
	Ответить \| Правка \| К родителю #31 \| Наверх \| Cообщить модератору


	39. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 19:02
	>> Идеального алгоритма, гарантирующего поиск всех уязвимостей, не существует > А никто и не говорит про все. Речь про проблемы работы с > памятью. Про нее и речь. Ты можешь построить формальную модель, но в реальном мире (особенно низкоуровневом) придется из нее выходить, чтобы что-то сделать, поэтому есть unsafe в разных языках и прочие проблемы с асинхронным кодом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	–1 +/–
	Сообщение от Аноним (43), 10-Апр-26, 19:05
	Есть большая разница "у тебя unsafe только в низкоуровневом коде" и "у тебя весь код unsafe и CVEшка может случиться даже при парсинге строки в UI". Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке будет гораздо легче.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 19:14
	> Есть большая разница "у тебя unsafe только в низкоуровневом коде" и "у > тебя весь код unsafe и CVEшка может случиться даже при парсинге > строки в UI". > Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке > будет гораздо легче. Не будет, т.к. отустуствие ub в unsafe блоке - это допущение, которое не проверяется. Эти проверки уже идут в райнтайме (смотри miri и сколько багов он нашел в safe коде). Это как раз аналогично тому, что в формализме мы говорим "забей, тут все будет выполняться", а по факту оно не выполняется, например, из-за аппаратной ошибки, чем и пользуются экплуатации уязвимостей.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Аноним (29), 10-Апр-26, 19:25
	>> Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке будет гораздо легче. > Не будет, т.к. отустуствие ub в unsafe блоке - это допущение, которое не проверяется Конечно будет, потому что количество небезопасного кода сокращается в десятки раз по сравнению с изначальными 100% сишочной лапши. Не говоря уж о том, что вся хитроумная логика и асинхронщина находятся за пределами unsafe. > например, из-за аппаратной ошибки Ох как ты ловко спрыгнул с обсуждения языков и алгоритмов на аппаратные ошибки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	59. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 19:31
	>>> Более того если у тебя каким-то образом помечены "стремные" места, то ИИшке будет гораздо легче. >> Не будет, т.к. отустуствие ub в unsafe блоке - это допущение, которое не проверяется > Конечно будет, потому что количество небезопасного кода сокращается в десятки раз по > сравнению с изначальными 100% сишочной лапши. Не говоря уж о том, > что вся хитроумная логика и асинхронщина находятся за пределами unsafe. У тебя любой примитив синхронизации будет с unsafe внутри. >> например, из-за аппаратной ошибки > Ох как ты ловко спрыгнул с обсуждения языков и алгоритмов на аппаратные > ошибки. Алгоритмы работают в реальном мире на секунду. Если хочешь рассуждать о них в отрыве, то тебе в теоретики, но тогда проблемы с памятью тебя вообще волновать не должны в твоей модели.
	Ответить \| Правка \| К родителю #56 \| Наверх \| Cообщить модератору


	66. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	–1 +/–
	Сообщение от Аноним (29), 10-Апр-26, 19:47
	>> что вся хитроумная логика и асинхронщина находятся за пределами unsafe. > У тебя любой примитив синхронизации будет с unsafe внутри. А вся логика снаружи - нет. Об этом как бы и речь. >>> например, из-за аппаратной ошибки >> Ох как ты ловко спрыгнул с обсуждения языков и алгоритмов на аппаратные ошибки. > Алгоритмы работают в реальном мире на секунду. Если хочешь рассуждать о них в отрыве Программные алгоритмы работают, внезапно, сугубо в пределах программы, и чисто физически не могут иметь отношения к потенциальным аппаратным ошибкам. Заканчивай чушь нести.
	Ответить \| Правка \| К родителю #59 \| Наверх \| Cообщить модератору


	51. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Аноним (29), 10-Апр-26, 19:18
	>>> поиск всех уязвимостей >> Речь про проблемы работы с памятью. > Про нее и речь. Нет, ты только что пел буквально про "все уязвимости", а не только те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, я смотрю. > Ты можешь построить формальную модель, но в реальном мире (особенно низкоуровневом) придется из нее выходить, чтобы что-то сделать, поэтому есть unsafe Главное, что за пределами unsafe в 95% остального кода этих проблем не будет. > прочие проблемы с асинхронным кодом. Давай поподробнее, что это за "проблемы с асинхронностью". Вот с учетом того, что одна из основных целей создания borrow checker была как раз решение всех проблем с асинхронным/многопоточным кодом, а не просто "память не ронять".
	Ответить \| Правка \| К родителю #39 \| Наверх \| Cообщить модератору


	54. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	–1 +/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 19:24
	>>>> поиск всех уязвимостей >>> Речь про проблемы работы с памятью. >> Про нее и речь. > Нет, ты только что пел буквально про "все уязвимости", а не только > те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, > я смотрю. Очередной дешевый тролинг с обвинениями? Продолжать не буду. >> Ты можешь построить формальную модель, но в реальном мире (особенно низкоуровневом) придется из нее выходить, чтобы что-то сделать, поэтому есть unsafe > Главное, что за пределами unsafe в 95% остального кода этих проблем не > будет. Главное не забывать это повторять перед сном. >> прочие проблемы с асинхронным кодом. > Давай поподробнее, что это за "проблемы с асинхронностью". Вот с учетом того, > что одна из основных целей создания borrow checker была как раз > решение всех проблем с асинхронным/многопоточным кодом, а не просто "память не > ронять". Видно, что дальше рекламных буклетов раста ты не смортел. Штош, это было сразу понятно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Аноним (29), 10-Апр-26, 19:30
	>> Нет, ты только что пел буквально про "все уязвимости", а не только те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, я смотрю. > Очередной дешевый тролинг с обвинениями? Нет, просто констатация того факта, что ты переобуваешься на лету и (как теперь очевидно) не в состоянии отвечать за свои собственные слова. > Главное не забывать это повторять перед сном. > Видно, что дальше рекламных буклетов раста ты не смортел. Штош, это было сразу понятно. > Очередной дешевый тролинг Какая ирония...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 19:34
	>>> Нет, ты только что пел буквально про "все уязвимости", а не только те, что вызваны работой с памятью. Ты прямо на лету переобуваешься, я смотрю. >> Очередной дешевый тролинг с обвинениями? > Нет, просто констатация того факта, что ты переобуваешься на лету и (как > теперь очевидно) не в состоянии отвечать за свои собственные слова. У тебя всегда тролинг строится по одной схеме? Мой тебе совет: пора что-то менять, палишься.
	Ответить \| Правка \| К родителю #58 \| Наверх \| Cообщить модератору


	40. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Аноним (40), 10-Апр-26, 19:02
	> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями. зависит от области определения той или иной функции, "типы" как раз и есть те "ограничители" допустимых значений аргументов функций.
	Ответить \| Правка \| К родителю #31 \| Наверх \| Cообщить модератору


	47. "Опасные уязвимости в GStreamer, CUPS, wolfSSL, OpenSSL, Open..."	+/–
	Сообщение от Сладкая булочка (?), 10-Апр-26, 19:10
	>> Попытка доказать правильность программы через верификацию часто сталкивается с алгоритмической неразрешимостью и решается различными допущениями. > зависит от области определения той или иной функции, "типы" как раз и > есть те "ограничители" допустимых значений аргументов функций. Посмотри формальную верификацию чего-либо околосистемного.
	Ответить \| Правка \| Наверх \| Cообщить модератору