The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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


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

Оглавление

Уязвимости в реализации JPEG XL из состава FFmpeg, opennews (??), 30-Янв-24, (0) [смотреть все]

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


1. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –1 +/–
Сообщение от Аноним (1), 30-Янв-24, 14:44 
Вот тебе и JPEG XL!
Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –20 +/–
Сообщение от Аноним (3), 30-Янв-24, 14:54 
FFmpeg днище, это ни для кого не секрет. У него все собственные парсеры и муксеры/демуксеры максимально кривые. Недавно вон вообще учудили и сломали поддержку вполне валидных mp4 в очередной раз, на этот раз во всех ветках сразу.
Ответить | Правка | Наверх | Cообщить модератору

12. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +3 +/–
Сообщение от Аноним (12), 30-Янв-24, 15:17 
Днище не днище, а у многих пакетов в зависимостях. Без него многое не соберется.
Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –1 +/–
Сообщение от Аноним (3), 30-Янв-24, 15:30 
Это самое страшное. И популярная альтернатива в лице VLC ещё хуже. Ну, есть полноценная альтернатива в виде gstreamer в некотором роде, но у него свои проблемы, хотя ничего ужасного кроме багов с vaapi не припомню. Разве что, в wine он почему-то не может прочитать mp4 файлы с avc+aac (судя по логам), но тут уже вопросы к wine, сам gstreamer такие файлы воспроизводит.
Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –1 +/–
Сообщение от Аноним (24), 30-Янв-24, 15:50 
В отличие от тебя VLC и FFmpeg
Ответить | Правка | Наверх | Cообщить модератору

28. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –2 +/–
Сообщение от Аноним (3), 30-Янв-24, 16:02 
> В отличие от тебя VLC и FFmpeg

Они что? Не заботятся о работе или хотя бы соответствии спецификациям, положили на пользователей? Да, всё так. Я понимаю, что авторы сами не рады популярности, но другого опенсорса у нас нет, могли бы уже не действовать "на отвали". Какой-никакой опыт можно было уже приобрести за это время. Вместо этого тратят ресурсы на срачи и драмы.

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

73. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +1 +/–
Сообщение от Аноним (-), 30-Янв-24, 23:14 
>> В отличие от тебя VLC и FFmpeg
> Они что? Не заботятся о работе или хотя бы соответствии спецификациям, положили
> на пользователей? Да, всё так.

В соответствии с этими спеками в "так называемом MP4" может быть все что угодно. FYI все остальные программы и либы жрут еще меньше комбо "чего угодно" под таким соусом. Сюрприз!

> не действовать "на отвали". Какой-никакой опыт можно было уже приобрести за
> это время. Вместо этого тратят ресурсы на срачи и драмы.

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

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

68. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/–
Сообщение от Аноним (68), 30-Янв-24, 22:40 
Как в анекдоте: "стратегию я вам рассказала, а дальше вы как-нибудь сами"
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

70. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +2 +/–
Сообщение от Аноним (-), 30-Янв-24, 23:04 
> Это самое страшное. И популярная альтернатива в лице VLC ещё хуже.

А самое забавное - что vlc как раз таки и сам пользуется ffmpeg'овскими либами чтобы жрать столько форматов. Представляете?!

> Ну, естьполноценная альтернатива в виде gstreamer в некотором роде, но у него свои
> проблемы, хотя ничего ужасного кроме багов с vaapi не припомню.

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

А теперь коронный номер. Возьмем например модный SVT-AV1. Через ffmpeg его прогнать? Да не вопрос, тот уже несколько лет сие поддерживает. А как там gstreamer поживает? А может, gstreamer сможет схарчить bink video из вон той гамесы? Ах, нет, не сможет? Ну тогда он и не конкурент этой штуке - тот же vcmi не сможет заменить ffmpeg на gstreamer даже если б захотел.

> Разве что, в wine он почему-то не может прочитать mp4 файлы с avc+aac
> (судя по логам), но тут уже вопросы к wine, сам gstreamer такие файлы воспроизводит.

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

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

74. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –2 +/–
Сообщение от Аноним (3), 30-Янв-24, 23:22 
>сам пользуется

Это опциональная зависимость. Кто им только не пользуется, но важен результат. Gpac вот пользуется, но у него почему-то валидные файлы, соответствующие спецификациям на выходе. Прочитать файлы правда так и не смог с багованным ffmpeg, в отличие от vlc и gstremer.

>кусок глюкала с кучей проблем

Каких, например?

>чтобы это знать надо попытаться писать программ

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

>в их сорцы заглядывать

Ты сейчас конечно же покажешь, куда посмотреть. Я вот не использовал gstreamer в своём коде, очень интересно.

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

78. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +3 +/–
Сообщение от Аноним (-), 31-Янв-24, 00:06 
>>сам пользуется
> Это опциональная зависимость. Кто им только не пользуется, но важен результат.

Он настолько опциональный - что я ни разу в жизни VLC без ffmpeg'ской либы не видел. Ну, наверное, его можно самому так отстроить если очень хочется, но остальные так не делают. Потому что если даже так и можно, он из всеядного универсала резко станет нафигнужной байдой играюшей полтора формата. Профачив основное достоинство. И зачем он такой кому? :)

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

Я вообще не знаю что это за байда, ее в актуальном дебиане кажется нет. А gstreamer ненавижу еще с нокийского maemo где они удумали это юзать основным медийным фреймворком, и вот там я смог насладиться этой ср@нью от души.

Вы когда нибудь видели пайплайн этой дряни для записи видео с камеры? А, и --help или чего там подсказываюшего HOW TO - нету. Как максимум поиском в инете найти что так можно. На этом фоне ffmpeg - очень интуитивная и хорошая программа, со встроенным хелпарем, описывающим в том числе и захват экрана и камеры. Так что научиться это делать - в 10 раз проще.

> Прочитать файлы правда так и не смог с багованным ffmpeg,
> в отличие от vlc и gstremer.

Я хз о чем все это - у меня ffmpeg жрет все мыслимые файлы вроде. Учитывая вольность спеков MP4 контейнера я конечно не удивлюсь что что-то где-то каким-то софтом играется. Для начала одна и та же структура может быть MOV, 3GP/3G2, MP4, ISO BMFF и проч - но в мелких деталях и спеках подвидов ЭТОГО - есть "subtle differences". И там вообще-то в спеках знатный бардачелло, на память о том что изначально это - эпловский MOV контейнер в девичестве. Комитет бакланов стандартизировал, стандартизировал, да что-то настандартизировал. В перерывах между ублажением патентных троллей.

>>кусок глюкала с кучей проблем
> Каких, например?

У меня например плеер юзавший это - при открытии некоторых файлов падал где-то в недрах его либ. Дебажить не стал, выпилив к хренам плеер и заменив на - вот - vlc который жрет все что шевелится, без таких эксцессов.

Более того - ffmpeg жрет просто в разы больше форматов. Можно - вот - заставку из геруев III взять и проиграть. VCMI (альтернативный открытый движок) это кстати и делает. И даже сконвертить в другой формат если хочется.

Меня это колыхало потому что в эпоху молодости и глупости я наслушался проприетариев из RadGameTools про офигенный формат, конвертнул в него несколько мувиков, СНЕС ОРИГИНАЛ, и заметил что играется оно только убогим проприетарным плеером RadGameTools'ов который вообще не кодек. А доступ к моим данным - утерян (не переснимать же мне мувик захватом экрана?). И вот потом ffmpeg это - пофиксил. За что я безмерно благодарен этим господам. Теперь я могу опять делать с МОИМИ данными то что захочу.

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

А у gstreamer вообще апи какое-то ушибленое и умеет он по сравнению с ffmpeg - по сути нифига. Фичесет очень разный.

> Ты сейчас конечно же покажешь, куда посмотреть. Я вот не использовал gstreamer
> в своём коде, очень интересно.

Ну вон в pidgin он есть. И это 1 из причин по которым я перестал pidgin использовать, ибо по зависимостям это боль. В его кодеках постоянно CVE перли, так что когда хочет сказать как этого не бывает... кхе-кхе.

Более того - в этой байде есть plugins-base, plugins-good и plugins-bad. Как вы уже поняли без -bad оно полтора формата рюхает - и общее качество кодеков и их падучесть оставляет желать много лучшего. А так посмеяться - есть плагин для - вот - ffmpeg'овских либ.

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

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

84. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/–
Сообщение от Аноним (84), 31-Янв-24, 02:05 
>> Gpac...
> Я вообще не знаю что это за байда, ее в актуальном дебиане кажется нет.

Это одна из немногих прог, умеющая mpeg4 BIFS (которого нигде нету). BIFS - это такой векторный заменятор флеша, который никому не нужен. Но всё же это часть стандарта mpeg4 (part 11).

ИМХО, основная задача была заменить DVD-меню. Но получилось сильно сложно и прям совсем-совсем не взлетело.

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

90. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +1 +/–
Сообщение от Аноним (-), 31-Янв-24, 03:28 
> Это одна из немногих прог, умеющая mpeg4 BIFS (которого нигде нету). BIFS
> - это такой векторный заменятор флеша, который никому не нужен. Но
> всё же это часть стандарта mpeg4 (part 11).

В этом мире много странной фигни. Скажем у меня как-то был webm с "VP10". А, что, вы такого кодека то не знаете? Да и я тоже. Но был краткий миг когда из VP9 уже вырос из VP9 но еще не дорос до AV1, и вот тогда, их тулса генерила - ну вот это вот. Технически оно как бы валидная матрешка.

> ИМХО, основная задача была заменить DVD-меню. Но получилось сильно сложно и прям
> совсем-совсем не взлетело.

ISO в последнее время что-то лажает и делает хз что и зачем, имхо. AV1 их придавил, вон вообще суетятся, форматики строгают, нафиг кому нужные, с патентами, уже штуки 3 убийц AV1 выкатили. или таки 4, со счета сбился.

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

69. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/–
Сообщение от Аноним (-), 30-Янв-24, 22:58 
> FFmpeg днище, это ни для кого не секрет. У него все собственные парсеры и
> муксеры/демуксеры максимально кривые. Недавно вон вообще учудили и сломали
> поддержку вполне валидных mp4 в очередной раз, на этот раз во всех ветках сразу.

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

А "вполне валидный mp4" очень растяжимое понятие. MP4 это лишь контейнер и там можно что угодно сделать. Сколько софта вот прям ща сможет проиграть "MP4" где в ISO BMFF файле по факту AV1 какой-нибудь? А так то - валидный файл, ISO это даже стандартизировал недавно.

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

72. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –3 +/–
Сообщение от Аноним (3), 30-Янв-24, 23:08 
А зачем? Gstreamer поддерживает все адекватные форматы контейнеров и кодеков. Толку от кривого mp4, если он не соответствует никаким спецификациям? Av1 в mp4, кстати, соответствует. Вот vp9 в mp4 уже нет. Да и зачем тебе такие битые файлы? Ты же понимаешь, что кривые нестандартные файлы в принципе существуют только из-за ffmpeg, разрабам которого плевать на валидность?
Ответить | Правка | Наверх | Cообщить модератору

75. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +2 +/–
Сообщение от Аноним (-), 30-Янв-24, 23:31 
> А зачем? Gstreamer поддерживает все адекватные форматы контейнеров и кодеков.

Он поддерживает в разы менее форматов и вообще - кривая глючная байда под узкие нужды гномеров. И CVE в нем - на пару ffmpeg'ов хватит. Это уг настолько ужасно что им почти никто и не пользуется как раз.

> Толку от кривого mp4, если он не соответствует никаким спецификациям?

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

> Av1 в mp4, кстати, соответствует.

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

> Вот vp9 в mp4 уже нет. Да и зачем тебе такие битые файлы? Ты же понимаешь,
> что кривые нестандартные файлы в принципе существуют только из-за ffmpeg,
> разрабам которого плевать на валидность?

Я понимаю что технически ISO BMFF лишь контейнер, как и AVI/MOV(который сам почти как BMFF)/Mastroska/... и технически в него можно загнать что угодно.

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

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

115. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/–
Сообщение от Аноним (115), 31-Янв-24, 18:05 
Кто тебе такое придумал? Критиковать это в первую очередь дать толчок подумать а не раскрыть тебе все карты. Да и цель уничтожить никто не отменял так что живи с этим
Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

94. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –2 +/–
Сообщение от Аноним (94), 31-Янв-24, 07:01 
> FFmpeg днище, это ни для кого не секрет.

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

пока что ты только строчишь спам-комменты на опеннете.
это как бы показатель.

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

118. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/–
Сообщение от Аноним (118), 01-Фев-24, 05:55 
Это днище Голливуд использует
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

123. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/–
Сообщение от Аноним (3), 01-Фев-24, 10:27 
Маловероятно. Исчезающе маловероятно. Или ты про куски в продуктах адобы? Да, они вполне понимают, в каких местах ffmpeg днище и умеют экономить.
Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/–
Сообщение от Аноним (13), 30-Янв-24, 15:21 
> Вот тебе и JPEG XL!

При чем здесь JPEG XL? Сишочники где угодно int переполнят и за буфер вылезут.

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

41. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +1 +/–
Сообщение от Аноним (41), 30-Янв-24, 16:43 
Дак а нафига ты юзаешь этот дырявый ffmpeg? Напиши свой на безопасном языке или юзай готовый, если не способен написать свой ffmpeg без единой ошибки
Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +1 +/–
Сообщение от Аноним (13), 30-Янв-24, 17:35 
> Дак а нафига ты юзаешь этот дырявый ffmpeg? Напиши свой на безопасном языке или юзай готовый, если не способен написать свой ffmpeg без единой ошибки

Каким образом твои умничния относятся к моему вопросу?

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

54. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –1 +/–
Сообщение от Аноним (41), 30-Янв-24, 17:40 
Таким образом, что ffmpeg и jpegXL - это чистое байтодрочерство, где Си - идеальный выбор. Со своими борроу чекерами и прочей чепухой иди в... в веб разработку.
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +2 +/–
Сообщение от Аноним (-), 30-Янв-24, 18:11 
> Си - идеальный выбор.

Ахаха! И как два байта отослать они вышли за пределы массива и выполнили чужой код)))
Сишники даже байтодрочерство не могут сделать нормально!

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

62. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/–
Сообщение от Аноним (41), 30-Янв-24, 18:29 
Фигня это все. Несмотря на эту ошибку, они смогли написать целый ffmpeg. А растаманы даже компилятор свой не написали и собирают весь свой код компилятором написанном на С++.
Ответить | Правка | Наверх | Cообщить модератору

65. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +2 +/–
Сообщение от Аноним (65), 30-Янв-24, 19:20 
Вот опять - тебе пишут про си, а ты на раст съезжаешь. Зачем так?

> А растаманы даже компилятор свой не написали

Так на прекрасном с++ (причем новом! в шланге вроде с++17), а не на богомерзкой окаменелой дыряшке.
Кстати, в gcc тоже куча кода на с++ и ничего, как-то сишное ядро собирает.

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

76. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –1 +/–
Сообщение от Аноним (-), 30-Янв-24, 23:36 
> Вот опять - тебе пишут про си, а ты на раст съезжаешь. Зачем так?

Ну вы же не написали на <чем угодно> аналог ffmpeg, так что он по своему прав.

>> А растаманы даже компилятор свой не написали
> Так на прекрасном с++ (причем новом! в шланге вроде с++17), а не
> на богомерзкой окаменелой дыряшке.

А в этом саммом C++ есть те же "int" из сей дурацкие. Представляете? И вообще, C++ это superset C внезапно. С очень небольшими исключениями. Так что C++ может означать что угодно. Вплоть до откровенного си где из ++ аж // как коменты были, это у виндокодеров было популярно такое. Бывает еще "C с классами" и прочие странные штуки.

> Кстати, в gcc тоже куча кода на с++ и ничего, как-то сишное ядро собирает.

А еще C++ весьма растяжимое понятие включающее в себя и почти весь си.

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

67. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +3 +/–
Сообщение от Аноним (13), 30-Янв-24, 22:00 
> Таким образом, что ffmpeg и jpegXL - это чистое байтодрочерство, где Си - идеальный выбор. Со своими борроу чекерами и прочей чепухой иди в... в веб разработку.

Чел, с тобой все хорошо? С какими "моими" борроу чекерами, если я о Расте даже не упоминал?

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

59. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/–
Сообщение от Бывалый смузихлёб (?), 30-Янв-24, 18:06 
> при обработке в FFmpeg специально оформленных изображений
> возникшем из-за отсутствия проверки превышения размера типа int

Это на чём угодно может произойти

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

77. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +1 +/–
Сообщение от Аноним (-), 30-Янв-24, 23:38 
>> при обработке в FFmpeg специально оформленных изображений
>> возникшем из-за отсутствия проверки превышения размера типа int
> Это на чём угодно может произойти

Даже на хрусте в релизных билдах, что забавно. Ибо рантайм чек этого добра - очень накладное занятие. А насколько все хотели тормозные кодеки - э, а чего они тогда вопят что AV1/265/266 кодировать тормозно? Не хотите еще разика в три это дело обвалить по скорости? :)

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

95. "Уязвимости в реализации JPEG XL из состава FFmpeg"  +/–
Сообщение от Аноним (94), 31-Янв-24, 07:14 
> Сишочники где угодно int переполнят и за буфер вылезут.

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

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

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

104. "Уязвимости в реализации JPEG XL из состава FFmpeg"  –1 +/–
Сообщение от Аноним (104), 31-Янв-24, 09:50 
А чо вы хотели, там же полнота по Тьюрингу...
Туда любую малварь при желании вместе с картинкой зашить можно
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру