форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+1 +/–
Сообщение от opennews on 30-Ноя-14, 23:06
В открытой (http://www.opennet.dev/opennews/art.shtml?num=38662) компанией Cisco библиотеке OpenH264 (https://github.com/cisco/openh264), предоставляющей средства для кодирования и декодирования потоков H.264, выявлена уязвимость (http://tools.cisco.com/security/center/viewAlert.x?alertId=3...), которая может привести к выполнению кода, при обработке специально оформленных данных в приложениях, использующих OpenH264. Одним из наиболее известных продуктов, использующих OpenH264 для обеспечения поддержки видеокодека H.264, является web-браузер Firefox. Поддержка OpenH264 была добавлена начиная с выпуска Firefox 33 (http://www.opennet.dev/opennews/art.shtml?num=40824). По сообщению (https://bugzilla.mozilla.org/show_bug.cgi?id=1105688#c1) разработчиков Mozilla, Firefox не подвержен проблеме, так как несмотря на то, что информация об уязвимости анонсирована только сейчас, фактически исправления уязвимости были внесены (https://github.com/cisco/openh264/pull/1088/files) без лишней огласки в кодовую базу ещё в начале июля и вошли в состав ветки OpenH264 1.1 (https://github.com/cisco/openh264/releases/tag/v1.1), которая используется в Firefox. URL: http://tools.cisco.com/security/center/viewAlert.x?alertId=3... Новость: http://www.opennet.dev/opennews/art.shtml?num=41157
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

3. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	–15 +/–
Сообщение от Ahulinux (ok) on 01-Дек-14, 00:06
значит до июля уязвимость активно эксплуатировалась. Еще раз становиться очевидно что браузером должен оставаться браузером. Либо в инете надо сидеть с виртуалки.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+9 +/–
	Сообщение от Аноним (??) on 01-Дек-14, 02:05
	А до июля эта библиотека в браузере была?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	9. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+1 +/–
	Сообщение от Aceler (ok) on 01-Дек-14, 08:00
	> значит до июля уязвимость активно эксплуатировалась. Ага, как только она в октябре в браузере появилась, так сразу до июля и начала.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	20. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от Аноним (??) on 01-Дек-14, 12:28
	Можно подумать, в виртуалках нет уязвимостей, ага.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	24. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от Sergey722 (ok) on 01-Дек-14, 12:52
	Так нужно запускать одну виртуалку внутри другой (другой в плане ПО)...
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	31. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от Аноним (??) on 01-Дек-14, 22:10
	Можно подумать, в других виртуалках нет уязвимостей
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	25. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от iZEN (ok) on 01-Дек-14, 14:31
	> Либо в инете надо сидеть с виртуалки. Ага — каждой программе по jail(8). ;)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+4 +/–
Сообщение от th3m3 (ok) on 01-Дек-14, 02:06
А меня и штатная возможность через GStreamer устраивала, отрубил этот кодек из-за ненадобности.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от Аноном on 01-Дек-14, 10:21
	Тоже самое сделал, никаких минусов/изменений не увидел.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

6. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+2 +/–
Сообщение от Аноним (??) on 01-Дек-14, 05:30
>фактически исправления уязвимости были внесены без лишней огласки в кодовую базу Где ссылка на коммит? "Океания всегда воевала с Остазией".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	–4 +/–
Сообщение от vn971 (ok) on 01-Дек-14, 06:13
Кстаааати. Что скажут об эпизоде люди, ранее утверждавшие безопасность CPP? Вы вот прям точно всё равно уверены что CPP безопасен, и для написания кода без "языковых" ошибок достаточно будет вам заплатить побольше? (Извините за передёргивание если что.) Или может быть ржавчина (rust-lang) всё-таки имеет смысл? И может быть JVM не позволяет такого вида ошибок? (При всей отстойности JVM по ооочень широкому спектру других вещей.)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	–1 +/–
	Сообщение от vn971 (ok) on 01-Дек-14, 06:17
	(Я понимаю что тема психологически не простая. Но отступает ли всё-таки любая психология перед очевидным багом, привязанным к конкретному языку и практически невозможная на rust/jvm.)
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	17. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+1 +/–
	Сообщение от kurokaze (ok) on 01-Дек-14, 11:33
	> (Я понимаю что тема психологически не простая. Но отступает ли всё-таки любая > психология перед очевидным багом, привязанным к конкретному языку и практически невозможная > на rust/jvm.) Credo, quia absurdum
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+3 +/–
	Сообщение от JSmith (??) on 01-Дек-14, 08:28
	JVM сам по себе дает массу возможностей отстрелить себе ногу. И для таких низкоуровневых вещей, как видеокодеки - любой managed код это бестолковая трата ресурсов. Зачастую даже для видеокодеков делают оптимизации ассемблерными вставками - там, где это очень критично, не то что cpp. Управляемый код имеет смысл в уровнях много выше, базовая система обязана быть настолько производительной, насколько это возможно. Для безопасности C++ существуют тонны софта, обеспечивающего анализ кода и его тестирование, - как открытые, так и проприетарные. И конкретно Mozilla Foundation вполне располагает средствами, чтобы купить необходимый для контроля софт и время специалистов-аналитиков. C++ никогда не был и не будет безопасным языком. Это бред. Но в текущих условиях он обеспечивает хороший баланс скорости и синтаксических/функциональных плюшек.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	11. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от freehck (ok) on 01-Дек-14, 09:18
	Знаете, эти плюшки скорее время тратят, нежели экономят. Я припоминаю, что неделю отлавливал языковые баги в C++, а потом плюнул и переписал всё за 3 дня на Common Lisp. И получил готовый к работе код. В общем, не видел я на практике, чтобы плюс'ы обеспечивали какой-то там баланс. Единственный вариант, когда я могу на нём писать быстро - это использовать С++ только возможности языка C плюс одна или две плюшек C++ (Полиморфизм, например, бывает очень кстати). А в общем случае весь функционал плюсов использовать не получается, ибо язык сильно переусложнён и изобилует багами, что печально.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	18. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+1 +/–
	Сообщение от kurokaze (ok) on 01-Дек-14, 11:35
	> весь функционал плюсов использовать не получается, ибо язык сильно переусложнён и > изобилует багами, что печально. Ты всё правильно для себя решил. Не получается - не трожь
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	19. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+1 +/–
	Сообщение от F on 01-Дек-14, 12:13
	Я про синтаксический сахар в принципе - мне, например, очень нравился когда-то ассемблер, но при всём - более-менее серьезный проект на нем не написать. Макроассемблеры же очень быстро по существу начинают догонять Си (в процессе дописывания макросов) - то есть уход от низкого уровня. Плюсы хороши большой кодовой базой, массой народа на них работающих, множеством отработанных техник и рецептов. Сейчас порог входа я бы оценил как равный любому "детский" паскаль/бейсик. CL - минимум в этом плане проигрывает (впрочем, как и любой другой функциональный язык). С++ достаточно выразительный, чтобы на нем можно было написать что угодно - от ОС до приложений и скриптов. ЗЫ Полиморфизм и объекты - это и есть основной инкремент относительно Си.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	36. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от freehck (ok) on 02-Дек-14, 07:57
	> Плюсы хороши большой кодовой базой, массой народа на них работающих, множеством отработанных > техник и рецептов. И это основной минус. Масса народа, которая в общем-то не разбирается в языке, и которая лезет давать свои "дельные" советы. А разбираться в языке сложно из-за переусложнённых правил вычисления. Вон в институте Макса Планка ребята до сих пор находят ошибки в стандарте, так что разбирается ли хоть кто-то в этом языке - вопрос тот ещё. На debian-russian я уже неоднократно поднимал треды о проблемах языков С и Cxx. Что примечательно, с пониманием дела отвечали всегда одни и те же люди: в основном программисты на Lisp и Haskell. > Сейчас порог входа я бы оценил как равный любому "детский" паскаль/бейсик. Ох. Надо мне каяться: я долго пытался, ловил ошибки присваивания определённых мною объектов, ловил презабавные глюки при использовании cout - и в конце концов так и не вошёл. Что вообще такое этот "порог входа"? Я вот пишу программу, вроде пишу так, как написано в примерах - а код после компиляции выполняет что угодно, но только не то, что я ожидаю. А вот со Scheme/CL у меня всё получилось гораздо быстрее, не говоря уже о том, что вообще получилось. > CL - минимум в этом плане проигрывает (впрочем, как и любой другой функциональный язык). Ну, начнём с того, что CL - НЕ функциональный язык. А закончим тем, что систем (библиотек) на CL есть ну просто завались. А если вам кажется, что в CL их маловато, то посмотрите на Scheme - в том же Racket их столько, что я думаю могли бы потягаться с С/Сxx. > С++ достаточно выразительный, чтобы на нем можно было написать что угодно - > от ОС до приложений и скриптов. Ну это вы загнули. Это на лиспе можно написать что угодно. Плюс'ы для ОС - это больно жирно, да и не даром ведь ядро на чистом Си пишут. А скрипты... тут DSL всяко удобнее. Не думаю, что я предпочту C++ Perl-у или Bash-у. > ЗЫ Полиморфизм и объекты - это и есть основной инкремент относительно Си. Реализация ООП в Cxx сильно страдает. Хотя бы от того, что при изменении полей класса при внешней неизменности методов Вам всё равно необходимо перекомпилировать весь код, который этот класс использует. Вообще, вот что можно почитать по этому поводу, а то мне перечислять все проблемы уж очень долго будет: http://yosefk.com/c++fqa/defective.html
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	33. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от Аноним (??) on 02-Дек-14, 06:04
	> В общем, не видел я на практике, чтобы плюс'ы обеспечивали какой-то там баланс. Пока вы не видите - игроделы на нем здоровенные проекты наворачивают, например. И да, их скорость и предсказуемость поведения - интересует. По этим же причинам на них пишут требовательные к скорости программы, которые на сях уже стало слишком разлаписто писать.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от vn971 (ok) on 01-Дек-14, 10:01
	Спасибо за ответ. Если вдуматься, на самом деле, то я ни в одном месте не говорил про то плохой ли язык c++. Я прошу признать одну конкретную проблему. Кстати, Mozilla Foundation вроде и должна "распологать средствами чтобы ***", но на самом деле и не распологает ими: они сами на каких-то из видяшек говорили что по-прежнему > 90% ошибок это разыменовывания null pointer-ов и прочие именно языковые ловушки. Да и в Яндексе, если верить другой видяшке, тоже допускаются такие ошибки. То есть это уходит в продакшон, потом в конце концов одна из машинок заваливается с ошибкой. Потом это инспектируют, с какой-то вероятностью находят ошибку, чинят, релизят новую версию.. And the circle goes on.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	22. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+1 +/–
	Сообщение от F on 01-Дек-14, 12:30
	>[оверквотинг удален] > Если вдуматься, на самом деле, то я ни в одном месте не > говорил про то плохой ли язык c++. Я прошу признать одну > конкретную проблему. > Кстати, Mozilla Foundation вроде и должна "распологать средствами чтобы ***", но на > самом деле и не распологает ими: они сами на каких-то из > видяшек говорили что по-прежнему > 90% ошибок это разыменовывания null pointer-ов > и прочие именно языковые ловушки. ... То есть это уходит в > продакшон, потом в конце концов одна из машинок заваливается с ошибкой. > Потом это инспектируют, с какой-то вероятностью находят ошибку, чинят, релизят новую > версию.. And the circle goes on. Говорят, что подавляющее большинство такого прекрасно ловится статическими анализаторами. Проблема же ошибок кода в целом - это проблема явно не языка программирования, а программиста. Да, никто не спорит, чем строже язык, тем сложнее в нем начудить. Вопрос цены. В данном случае цена - способность кодека выполнять свою задачу. Т.е. (для кодека) работать за минимальное время. Поэтому управляемый код для кодека H.264 - исключен. Думаю, даже больше - особо критичные куски кода даже не используют ресурсоемких возможностей С++ (вроде упомянутого тут полиморфизма). Стоит делать различие между managed и unmanaged/классическим кодом, ок? Ориентированный на массы софт - тоже понятно, почему в основном не на управляемом коде (JVM/.Net) - охват аудитории зависит и от поддержки старого железа, т.е. низкой ресурсоемкости - что для managed code неверно как в части памяти, так и в части CPU. Кстати, показательно (сейчас будет флейм) - managed Андроид по отзывчивости явно сливает unmanaged iOS / Symbian при равном железе. И программисты на Андроиде вынуждены пользоваться NDK в тех местах, где производительность критична.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	23. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от Crazy Alex (ok) on 01-Дек-14, 12:45
	Эм... не то чтобы флейм, но некоторая корректировка. Я бы не называл iOS-код unmanaged. Там вполне приличный подсчет ссылок. Что до отзывчивости андроида - когда гугл таки собрался и сделал AOT в Android 5 жизнь резко улучшилась. Так что дело там скорее в превосходстве заранее скомпилированного кода перед JIT.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	26. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от vn971 (ok) on 01-Дек-14, 14:46
	Ещё раз, вы считаете что я говорю что CPP плохой/неподходящий язык? Я это где-то говорил или имел в виду, по-вашему?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	27. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от vn971 (ok) on 01-Дек-14, 15:09
	Иными словами, я за -- называть плюсы хорошим компромиссом для риал-таймовых задач или тех где высокие требования к ресурсам. я против -- притворяться что не видишь слона в комнате (небезопасность).
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	28. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+1 +/–
	Сообщение от Аноним (??) on 01-Дек-14, 18:22
	> я против -- притворяться что не видишь слона в комнате (небезопасность). У каждого языка свой небезопасный слон в комнате. У одного это прямой доступ к памяти, у другого динамическая типизация и duck typing, а значит возможность подсовывания объекта другого типа, у третьего injections, у четвертого eval() (частный случай injections), у пятого уязвимости в интерпретаторе или VM, у шестого излишняя зависимость от переменных окружения (частный случай уязвимости в интерпретаторе). NULL/Null/null/nil, опять таки, не только в С/С++ есть. Уже ж несколько лет назад это обсасывали на форумах.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	35. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+1 +/–
	Сообщение от Аноним (??) on 02-Дек-14, 06:11
	> Уже ж несколько лет назад это обсасывали на форумах. Ну вон в вебе используют пыхи, питоны и прочие. В результате то иньекции чего попало, то загрузка абы каких файлов, то еще какая-нибудь хрень. И в результате теперь системы в основном ломают через дырявую вебню. Си теперь конечно стал менее виноват, а вот взломов меньше не стало. Даже больше. Да что там, даже целые червяки появились, долбящие вебню на автомате. Не багом - так глупым паролем админа.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	39. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от F on 08-Дек-14, 21:20
	>> Уже ж несколько лет назад это обсасывали на форумах. > Ну вон в вебе используют пыхи, питоны и прочие. В результате то > иньекции чего попало, то загрузка абы каких файлов, то еще какая-нибудь > хрень. И в результате теперь системы в основном ломают через дырявую > вебню. Си теперь конечно стал менее виноват, а вот взломов меньше > не стало. Даже больше. Да что там, даже целые червяки появились, > долбящие вебню на автомате. Не багом - так глупым паролем админа. Таки я вас уверяю - в вебе образца 97-98 года (когда еще была масса cgi, писаных на C/C++) сплошь и рядом в норме вещей были stack overflow. Пыха тогда просто не было, да, перловка тоже давала прикурить (салют Леше Павлову, если кто помнит такого).
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	12. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от Аноним (??) on 01-Дек-14, 09:55
	Построчная проверка кода.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	15. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+1 +/–
	Сообщение от Вася Пупкин on 01-Дек-14, 11:25
	Блин, ну что ж вам свербит-то так? Да пишите на чём хотите, и другим не мешайте. Сколько можно уже по кругу всё это обсуждать..
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	16. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+2 +/–
	Сообщение от kurokaze (ok) on 01-Дек-14, 11:31
	> Кстаааати. Что скажут об эпизоде люди, ранее утверждавшие безопасность CPP? Толстота. Вообразил себе оппонентов, вложил им в уста воображаемые аргументы и начал героически их развенчивать, PROFIT! Взрослеть то собираешься? >И может быть JVM не позволяет такого вида ошибок? JVM написана на плюсах, конец религии
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	34. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	–1 +/–
	Сообщение от Аноним (??) on 02-Дек-14, 06:08
	> Вы вот прям точно всё равно уверены что CPP безопасен, Чего бы это вдруг? Си++ позволяет себе прострелить пятки при желании. Единственная проблема - языки которые делают добавочные проверки на видеокодеке провалятся по производительности. Раза так в три. И юзеры, особенно с слабыми компьютерами, обложат такой кодек матом. Особенно при попытках посмотреть что-нибудь в разрешении поболее почтовой марки. > (При всей отстoйности JVM по ооочень широкому спектру других вещей.) Вы, конечно, извините, но кому и зачем надо кодек, тормозящий в 3 раза сильнее и икающий в моменты когда GC приспичило собрать мусор? Это сойдет как PoC, показать "ява не тормозит" всему миру. Но на практике этим будет пользоваться разве что сам автор, которому свое не пахнет.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	37. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от Ordu (ok) on 02-Дек-14, 09:36
	> икающий в моменты когда GC приспичило собрать мусор Я не интересовался именно джавой, но мне несколько удивительно слышать, что джава так и не научилась гонять gc в отдельном потоке. Уж кому-кому, а жабе с её популярностью и использованием во всех щелях это просто необходимо. В связи с этим вопрос: это вы чисто умозрительно предполагаете икание у java-кодека, или на своём опыте сталкивались? Расскажете как воспроизвести?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	38. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от vn971 (ok) on 02-Дек-14, 14:54
	Ответ такой что нет, это было исключительно умозрительное предположение анонима, и совершенно неверное. В JVM gc-шка является настраиваемой, т.е. ты можешь указать её сам при старте jvm. Версия которая не делает "stop the world" возникла уже очень давно, и вроде по дефолту и запускается в JVM тоже уже давно. Т.е. gc действительно идёт в параллельном потоке. При всём при этом, я вообще хотел лишь обратить внимание на безопасность c/cpp. По факту писать именно кодеки я ни за что на JVM не рекомендую. Будет гигантское потребление памяти и медленная скорость работы (хоть и "плавная", без пауз). Касательно рекоммендаций, мне кажется кодеки надо писать на rust-lang. Или, если этот язык кажется недостаточно стабильным, то по-старинке на c/cpp.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

21. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
Сообщение от Аноним (??) on 01-Дек-14, 12:28
Эти и другие недоговорки со стороны Mozilla уже начинают напрягать. А ещё опен соурс называется.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+2 +/–
	Сообщение от Нимо Ан on 01-Дек-14, 18:45
	> Эти и другие недоговорки со стороны Mozilla уже начинают напрягать. А ещё > опен соурс называется. Ну потому и называется: читайте сорсы, в них никаких недоговорок нет.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	30. "В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."	+/–
	Сообщение от Dragonic (ok) on 01-Дек-14, 21:26
	ну написано же, что уязвимости в лисе нет и не было, проблемы?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

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

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