| 1.1, Аноним (1), 11:12, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Обещали же в файрфоксе все эти парсеры в васм скомпилровать. RLBox.
| | |
| |
| 2.79, Аноним (-), 16:27, 22/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Обещали же в файрфоксе все эти парсеры в васм скомпилровать.
Чтобы тормозило и жрало память еще и это? Файрфокс и так после открытия нескольких вкладок начинает дико якорить уже.
| | |
|
| 1.6, Аноним (6), 11:41, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
Эти ошибки - результат эры PC. До PC все писали на басике и паскале и не парились. Потом пришли ребята, которые сказали, надоело системые проги на асме катать. Давайте изобретем си. Вот и изобрели себе на голову. А писали бы на басике, проблем бы не знали.
| | |
| |
| 2.35, Аноним (35), 13:57, 22/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Историческая безграмотность это настоящая беда современной молодежи!
Керниган и Ритчи (K&R) опубликовали «Язык программирования Си» в 1978 году. Ни каких РС, бэйсиков и паскалей еще даже в проекте не было.
| | |
| |
| 3.43, Аноним (43), 14:28, 22/11/2025 [^] [^^] [^^^] [ответить]
| +6 +/– | |
> Керниган и Ритчи (K&R) опубликовали «Язык программирования Си» в 1978 году. Ни каких РС, бэйсиков и паскалей еще даже в проекте не было.
Тем временем в нашей вселенной: язык программирования Pascal был создан в 1970.
| | |
| 3.77, Медведь (ok), 16:23, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
 > Историческая безграмотность это настоящая беда современной молодежи! Керниган и Ритчи (K&R) опубликовали «Язык программирования Си» в 1978 году. Ни каких РС, бэйсиков и паскалей еще даже в проекте не было.
Беда!
> Язык программирования Си разрабатывался в период с 1969 по 1973
Ой, беда!
> Бейсик был придуман в 1964 году преподавателями Дартмутского Колледжа Джоном Кемени и Томасом Курцем, и под их руководством был реализован командой студентов колледжа
Ой, беда-беда!
> Язык программирования Pascal был создан в 1970 году на основе языка Алгол-60.
Беда, однозначно!
| | |
|
|
| 1.19, Аноним (-), 12:51, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ] | +3 +/– | Шикарная новость С одной стороны ничего нового, типиkaл си код Но один пикантн... большой текст свёрнут, показать | | |
| 1.22, Аноним (22), 13:04, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Странная ошибка. Попытка заюзать такую в реале должна быть винда на экране: либо будет специально-скрафченный корявый ввод при просмотре 16-RGB, либо получится корявый вывод 8-RGBA. Ну или забыли только про это одно место, а вывод трансформируется где-то ещё (и тогда вопрос - а было ли переполнение)
| | |
| |
| 2.67, Анонимусс (-), 15:38, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
> либо будет специально-скрафченный корявый ввод при просмотре 16-RGB,
> либо получится корявый вывод 8-RGBA.
А уже не важно что будет на экране - подумаешь, битое изображение - главное что сторонний код уже успеет выполниться.
И выполнится он с правами процесса запустившего либу. Рута там надеюсь не будет, но прошерстить и отправить все что нужно куда нужно оно вполне сможет.
| | |
|
| 1.23, бсдшник (-), 13:12, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Кстати забавно, если открыть страничку FreeBSD из новости (vuxml.org/freebsd/pkg-png.html), то там есть очень классная табличка
2015-11-15 libpng buffer overflow in png_set_PLTE
2015-01-05 png -- heap overflow for 32-bit builds
2012-04-08 png -- memory corruption/possible remote code execution
2010-06-28 png -- libpng decompression buffer overflow
2010-04-20 png -- libpng decompression denial of service
2008-04-25 png -- unknown chunk processing uninitialized memory access
2007-10-11 png -- multiple vulnerabilities
2007-05-16 png -- DoS crash vulnerability
2004-08-04 libpng stack-based buffer overflow and other code concerns
2004-05-02 libpng denial-of-service
Что какбЭ в полной мере характеризует качество кода этой либы и йазычка, на которой она написана.
| | |
| |
| |
| 3.45, Аноним (43), 14:32, 22/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
В любой более-менее популярной софтине на Си постоянно находят десятки CVE из-за ошибок с памятью, что как бы намекает на качество языка.
| | |
| 3.52, Аноним (-), 14:49, 22/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Никак язык это не характеризует.
Ещё как! Идеальный инструмент для сокрытия бэкдоров. И, как показывает коммит, бэкдор из новости добавили, когда прятали предыдущий бэкдор. Цирк, да и только. А те, кто защищает этот макроассемблер - или сознательные саботажники, или полезные иди от ы.
| | |
|
|
| |
| 2.55, Анонимусс (-), 14:56, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> В разработке этой библиотеки используются статические анализаторы
Используют.
"A Coverity project for libpng is at scan.coverity.com/projects/4061. The project is set up to scan the head of each of the libpng10 through libpng17 branches" [1]
И текущая libpng16 в него включена.
Но что-то не сильно помогает)))
> и санитайзеры
Как минимум часть багов нашли с из помощь [2]. Но используются ли они на постоянку при разработке на офф сайте и в README не сказано.
Скорее всего нет, патамушта диды и так пишут код на отлично!
[1] libpng.sourceforge.io
[2] github.com/pnggroup/libpng/issues/275
| | |
| |
| 3.83, Аноним (87), 16:43, 22/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Но что-то не сильно помогает)))
Я задавал вопрос, а как в сишке проверить отсутствие разыменноывания нулевого указателя. Мне дали аж целых два флага для gcc, и ни один из них не заработал.
>Но используются ли они на постоянку при разработке на офф сайте и в README не сказано.
Если статический анализатор не включён в обязательные сборочные зависимости - значит не используют.
| | |
| |
| 4.88, Медведь (ok), 17:49, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Если статический анализатор не включён в обязательные сборочные зависимости - значит не используют.
Если хлеб в магазине не прикручен скотчем к колбасе, бутерброд ты никогда не сделаешь. Инфа сотка!
| | |
| |
| 5.89, Аноним (87), 18:16, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ну вот покажите мне, где в libpng используется этот самый анализатор. И да, почему сишные проверки ломаются от рефакторинга?
| | |
|
|
|
| 2.81, Аноним (87), 16:40, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Кошкажена - вот возьмите и как настоящий апологет сишки возьмите и посмотрите.
| | |
|
| 1.71, Аноним (87), 16:08, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ] | +/– | Дыроделы, ваше оправдание Почему заведомо уязвимый код скомпилировался Я конеч... большой текст свёрнут, показать | | |
| |
| 2.85, Анонимусс (-), 16:47, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Вы представляете, верификацию можно было делать ещё до появления ненужнораста!
А вы знаете сколько времени и денег потратили на эту верификацию?
Скорее всего нет, раз пишите такое.
Ядро L4 это 8,700 строк C и 600 строк ассемблера.
В статье "seL4: Formal Verification of an OS Kernel" есть детали как проходила верификация.
Она состояла из трех фаз:
1) упрощенная версия ядра дизайнилась и имплементилась на Хаскеле + писался фреймворк для верификации
2) написали abstract spec
3) имплементировали все ядро и провалидировали
Общий размер пруфа - 200,000 строк Isabelle script - примерно в 20 раз больше чем кода на дыpяxe и асме.
Теперь по времени
- написание abstract заняло примерно 4 человеко-месяца
- два человеко-года ушло на весь Haskell прототип (design, documentation, coding, testing)
- на executable spec потратили всего лишь 2 человеко-месяца
- начальная трансляция в С заняла 3 недели, а полная C implementation - 2 человеко-месяца
- общие затраты на seL4-specific proof 11 человеко-лет
При этом в процессе разработки и верификации было внесено около 300 изменений в abstract spec и 200 в executable spec. Около 50% изменений были из-за багов в алгоритмах или архитектуре.
При этом оценка доказательства аналогичного ядра по такой же методологии - 6-8 человеко-лет.
> Кто из вас знает хаскель, окамл, или любой другой пригодный для цели верификации язык?
А кто из вас умеет проводить формальную верификацию?))
Вы даже правильно посчитать размер буфера, чтобы за границы не выходить, не в состоянии.
----------------------------------------------------------
Источник sigops.org/s/conferences/sosp/2009/papers/klein-sosp09.pdf
| | |
| |
| 3.86, Аноним (87), 16:55, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>При этом оценка доказательства аналогичного ядра по такой же методологии - 6-8 человеко-лет.
А куда спешим? Выше приводили, небольшой срез из freebsd
>2004-05-02
Я думаю, что за более чем двадцать лет как-то бы уже успели. Особенно, если местные експерты бы вместо того, чтобы здесь строчить комметарии о ненужно раста взяли бы и все вместе принялись писать.
| | |
|
|
|
