forum.opennet.ru - "Переполнение буфера в Perl, связанное с обработкой символов" (86)

"Переполнение буфера в Perl, связанное с обработкой символов"

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

"Переполнение буфера в Perl, связанное с обработкой символов"	+/–
Сообщение от opennews (??), 14-Апр-25, 10:04
Опубликованы корректирующие обновления интерпретатора Perl 5.40.2 и 5.38.4, в которых устранена уязвимость (CVE-2024-56406), приводящая к переполнению буфера при транслитерации специально оформленных не-ASCII символов при помощи оператора "tr/../../". Не исключается возможность эксплуатации уязвимости для организации выполнения своего кода в системе. Проблема проявляется в релизах Perl, начиная с 2021 года и затрагивает стабильные ветки Perl 5.34, 5.36, 5.38 и 5.40. Проследить за устранением уязвимости в дистрибутивах можно на следующих страницах: Debian, Ubuntu, Fedora, Arch, FreeBSD. Дистрибутивы на основе RHEL 9, SUSE 15 и openSUSE Leap 15.6 уязвимости не подвержены, так как включают версии Perl 5.32 и 5.26... Подробнее: https://www.opennet.me/opennews/art.shtml?num=63068
Ответить \| Правка \| Cообщить модератору

Оглавление

Странно, что перл вообще поддерживает юникод Это слишком прогрессивно для него,, Аноним (1), 10:04 , 14-Апр-25, (1) –13

Лучше всех поддерживает и очень давно , nuclight (??), 11:12 , 14-Апр-25, (19) +11

Да видим, как он поддерживает , Аноним (1), 14:38 , 14-Апр-25, (74) –3
Так давно, что в те времена не было смешанной кодировки или коллектив был не в к, Аноним (75), 14:51 , 14-Апр-25, (75) –2

любая последовательность символов в любой кодировке является валидным perl6 кодо, 12yoexpert (ok), 11:23 , 14-Апр-25, (22) +9

и лишней возможностью запустить что-то случайное, Соль земли (?), 12:00 , 14-Апр-25, (36)
Не спешите так господа, я только-только перевел энтерпрайзы с 4 стабильного перл, Аноним (45), 12:14 , 14-Апр-25, (45) +1

Юникод для всех слишком прогрессивен Нет ни одной библиотеки которая без проблем, Аноним (71), 14:14 , 14-Апр-25, (71)

2025 году отрицать Юникод так же дико, как верить в то, что Земля плоская Такие, Аноним (106), 06:26 , 15-Апр-25, (106) +1

5 лет назад был 2020 год и не 1990 год, ты что-то путаешь , Аноним (1), 11:43 , 15-Апр-25, (109)

Сам перл поддерживает юникод очень и очень давно, возможно раньше, чем многие п, Аноним (108), 11:01 , 15-Апр-25, (108)

Значит, так поддерживает Питон, перл, тикль, добавили юникод все в 1 год, что с, Аноним (1), 13:34 , 15-Апр-25, (111)

Не понимаю, почему бы полностью не перейти в каком-нибудь perl 5 70 на 100 рабо, Жироватт (ok), 10:05 , 14-Апр-25, (2)

Эксплоит был написан вместе с этим бекдором и успешно проработал четыре года , ИмяХ (ok), 10:15 , 14-Апр-25, (5) –1
Потому что бникод не нужен нигде, кроме браузеров , xsignal (ok), 10:43 , 14-Апр-25, (13) –2

Юникод нужен везде, где есть ещё языки кроме английского Делать по кодировке на , Bottle (?), 12:35 , 14-Апр-25, (56) +1

Сделать одну кодировку для всех, которую никто не может поддерживать и поэтому п, Аноним (71), 14:16 , 14-Апр-25, (72)

Кучу разных кодировок все поддерживать тоже не смогут, Аноним (86), 16:49 , 14-Апр-25, (86) +1
которую никто не может поддерживать целикомЭта поправка всё меняет Используй , Аноним (107), 06:48 , 15-Апр-25, (107) +1

Ого, свидетель KOI-8 в треде НенужОн мне ваш юникод с А в почтовике юникод то, Аноним (-), 14:14 , 14-Апр-25, (70) –1

найти чего-нибудь работающего на perl е использующие непроверенные внешние , User (??), 11:11 , 14-Апр-25, (18)
Смысл Повторять ошибку питона 2- 3 Как раз нормально сделано , nuclight (??), 11:13 , 14-Апр-25, (20)

Ошибку Господь с Вами Python 2 8594 3 это лучшее что произошло с питоном, и л, Аноним (92), 18:14 , 14-Апр-25, (92) –1

Ошибка тут была не дропнуть любую поддержку старых веток сразу и навсегда ну мо, Аноним (1), 18:32 , 14-Апр-25, (95) –1

Лучше, вместо каких-нибудь perl 5 70, оставить его в покое и перейти на что-нибу, Xenia Joness (ok), 12:55 , 14-Апр-25, (60) –3

А какие есть варианты Перловку используют чтобы уйти от башизмов и протухших бш-, Аноним (-), 12:58 , 14-Апр-25, (61) +1

Разве у Bash ломают обратную совместимость , Аноним (87), 17:19 , 14-Апр-25, (87) +1

На нём невероятно трудно писать что-то большое по объёму, Аноним (86), 17:37 , 15-Апр-25, (113)

Perl активно используется во многих проектах, например, ядро Linux Но это не то, xsignal (ok), 13:06 , 14-Апр-25, (62) +3
А что в Perl е неприличного и несовременного , xsignal (ok), 13:09 , 14-Апр-25, (63) +2

Бекдоры которые живут годами Хотя может это вполне современно 129300 , Аноним (-), 13:31 , 14-Апр-25, (65) –2

Это какие , xsignal (ok), 13:42 , 14-Апр-25, (66)

Ненадёжный синтаксис, Ан Оним (?), 21:48 , 14-Апр-25, (102)

А что считается полезной работой То, что приносит прибыль За деньги - да , Аноним (64), 13:17 , 14-Апр-25, (64)
Ну, глубокое легаси, которое не меняют, по тому, что оно никому вроде как не меш, User (??), 14:37 , 14-Апр-25, (73) +1
Очевидный booking com, например Достаточно серьёзно Продакшен и прибыль точно , Аноним (93), 18:21 , 14-Апр-25, (93)

Хех, да, на генте amd64 воспроизводится, Fracta1L (ok), 10:12 , 14-Апр-25, (4)

Это только потому, что ты не удалил его вместе с руби Чем можно оправдывать тыс, Аноним (1), 10:19 , 14-Апр-25, (6) –2

Гента без перла тупо не соберётся , bdrbt (ok), 10:43 , 14-Апр-25, (12)
К сожалению, из генты всю эту скриптовую дичь выкинуть невозможно Я пытался , Fracta1L (ok), 10:46 , 14-Апр-25, (14)

просто перепеши на раст, 12yoexpert (ok), 11:25 , 14-Апр-25, (24)

точнее такНАЧНИ, переписывать на rust , Аноним (27), 11:32 , 14-Апр-25, (27) +2
На Си же , Аноним (103), 03:55 , 15-Апр-25, (103)

Выбрал тестовый вариант - страдай , Аноним (23), 11:24 , 14-Апр-25, (23)

https ubuntu com security CVE-2024-56406мне 500ю показывает, Ivan (??), 10:23 , 14-Апр-25, (8)
Публикации CVE надо запретить, а то сплошные публичные действия, направленные на, Аноним (9), 10:29 , 14-Апр-25, (9)

А они находят ошибки только в сях, а в расте не находят Это плохо для раста , xsignal (ok), 10:48 , 14-Апр-25, (15)

Везда находят Но есть нюанс какие именно Если это логическая ошибка - то ниче, Аноним (42), 12:07 , 14-Апр-25, (42) +1

В корне неверно Для минимизации таких ошибок язык должен обладать минимумом син, Аноним (27), 12:20 , 14-Апр-25, (48) –2

Для минимазиции ошибок язык должен занимать как можно меньше внимания программис, Аноним (42), 12:35 , 14-Апр-25, (57)

Если прога завязана на строках, можно свою реализацию написать И если уж там гд, Аноним (98), 20:44 , 14-Апр-25, (98)

проход в раст защитанисправил не благодари, Аноним (46), 12:15 , 14-Апр-25, (46) –1

Вы про закрытые двери Тогда да,но вони про Андроид было много с таким подходом , Аноним (23), 11:26 , 14-Апр-25, (25)

proxmox он же дебиан вчера обновил перлы эти ваши, Анониматор (?), 10:41 , 14-Апр-25, (11) +1

в арч тоже сейчас завезли, Анониматор (?), 12:53 , 15-Апр-25, (110)

Опять сишка же https github com Perl perl5 commit 87f42aa0e0096e9a346c9672aa3a, Аноним (16), 10:51 , 14-Апр-25, (16) +1

Программисты Боинг тоже не умеют кодить - MAXы же падали из-за программной ошибк, xsignal (ok), 11:34 , 14-Апр-25, (29) +2

Ага, особенно если давать задачи по созданию высоконадежных систем людям котор, Аноним (41), 12:07 , 14-Апр-25, (41)

Я тебе скажу даже больше к примеру - погромисты на 1с массово не умеют в регек, Аноним (45), 12:21 , 14-Апр-25, (49)

Просто перл писался ненастоящими сишниками Настоящие сишники такого бы не допус, Аноним (17), 10:57 , 14-Апр-25, (17) –2

А они и не допустили Но пришли желторотики и сказали, что вот в этом месте прове, Аноним (27), 11:35 , 14-Апр-25, (31) +2

А они с этим согласились и приняли изменения Кто-то же ревьювил эти изменения К, Аноним (-), 12:14 , 14-Апр-25, (44)
Какие желторотики Karl Williamson второй по активности среди коммитеров в репе , Аноним (55), 12:35 , 14-Апр-25, (55) +2

Прям удар в псину Возможно стоит глянуть его налоговую декларацию за 2021 год Вд, Аноним (42), 12:42 , 14-Апр-25, (59) +1
Первый патч в 2009 Далее по патчу в год Полностью включился в 2014 Perl5 был вы, Аноним (27), 16:34 , 14-Апр-25, (84) –1

Ах, да Стоит добавить что он включился в разработку после выхода версии 5 20 , Аноним (27), 16:38 , 14-Апр-25, (85)
Ну может быть, 11 лет для тебя - ничего совсем Ты бы ещё сказал, что и с 1994 г, Аноним (88), 17:26 , 14-Апр-25, (88) +1

Это эмоции Реальность от наличия эмоций не изменится Perl был разработан други, Аноним (27), 17:45 , 14-Апр-25, (90) –1

Погоди, перловку создал Ларри Уолл И что интересно он сам забросил 4ю версию и н, Аноним (-), 18:28 , 14-Апр-25, (94)
Главное верить и тогда никакая реальность не страшна 128077 , Аноним (100), 21:24 , 14-Апр-25, (100)

И патчи бывают разные От 1994 до 2009 - 15 лет От 2009 до 2025 - 16 Чел, которы, Аноним (-), 17:34 , 14-Апр-25, (89)

Скрыто модератором, Аноним (27), 17:47 , 14-Апр-25, (91)

я в свое время решил что не буду изучать perl, мне и bash выше крыши а изучить , Аноним (30), 11:35 , 14-Апр-25, (30)

Ты же в курсе, что изучив только синтаксис BASH, ты рискуешь остаться в уголке, , Аноним (45), 12:26 , 14-Апр-25, (50) +1

Где ты видел ванильный sh последние лет 15 Даже в ретроградских openbsd, solaris, Аноним (103), 03:59 , 15-Апр-25, (104)

Perl по сравнению с Bash - эталон ясности, если только специально не запутывать , Аноним (54), 12:31 , 14-Апр-25, (54) +1

Баш последователен, если выкинуть из него совместимость с 50 летними скриптами , Аноним (1), 19:01 , 14-Апр-25, (96) +1

Как говорил Глеб Жеглов - Правопорядок в стране определяется не наличием воров,, xsignal (ok), 11:57 , 14-Апр-25, (35)

Мда ну у тебя и пример конечно Хотя для тебя ничего удивительного А раст т, Аноним (42), 12:04 , 14-Апр-25, (38)
Если исправлять ошибки в корне, то и искать их не нужно Пора бы уже развиваться, Соль земли (?), 12:06 , 14-Апр-25, (40)

Это восхититительно Обосновать закладку оптимизацией И главное что все согласи, Аноним (42), 12:10 , 14-Апр-25, (43)

Настоящий сишник добавляет проверки, только если есть CVE, обосновывающий необхо, Аноним (17), 12:26 , 14-Апр-25, (51) +1

Ты так написал, как будто это что-то плохое Если никому не мешает, то зачем лиш, Аноним (103), 04:04 , 15-Апр-25, (105)

Да закоммитил один из основных разработчиков, он сам с собой согласился и одобри, Аноним (55), 12:40 , 14-Апр-25, (58)

Проверил на debian testing воспроизводится root testing cat etc debian_ve, Аноним (53), 12:29 , 14-Апр-25, (53)
Обновляйтесь , - говорили они , Аноним (115), 20:11 , 15-Апр-25, (115)

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

1. "Переполнение буфера в Perl, связанное с обработкой символов" –13 +/–

Сообщение от Аноним (1), 14-Апр-25, 10:04

Странно, что перл вообще поддерживает юникод. Это слишком прогрессивно для него, ну и вот видим, к чему это приводит.

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

19. "Переполнение буфера в Perl, связанное с обработкой символов" +11 +/–

Сообщение от nuclight (??), 14-Апр-25, 11:12

Лучше всех поддерживает и очень давно.

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

74. "Переполнение буфера в Perl, связанное с обработкой символов" –3 +/–

Сообщение от Аноним (1), 14-Апр-25, 14:38

Да видим, как он поддерживает.

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

75. "Переполнение буфера в Perl, связанное с обработкой символов" –2 +/–

Сообщение от Аноним (75), 14-Апр-25, 14:51

Так давно, что в те времена не было смешанной кодировки или коллектив был не в курсе такой возможности?

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

22. "Переполнение буфера в Perl, связанное с обработкой символов" +9 +/–

Сообщение от 12yoexpert (ok), 14-Апр-25, 11:23

любая последовательность символов в любой кодировке является валидным perl6 кодом

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

36. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Соль земли (?), 14-Апр-25, 12:00

и лишней возможностью запустить что-то случайное

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

45. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (45), 14-Апр-25, 12:14

Не спешите так господа, я только-только перевел энтерпрайзы с 4 стабильного перла.

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

71. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (71), 14-Апр-25, 14:14

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

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

106. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (106), 15-Апр-25, 06:26

2025 году отрицать Юникод так же дико, как верить в то, что Земля плоская. Такие разговоры были актуальны ещё 5 лет назад, но не сегодня. Вы смешны.

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

109. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (1), 15-Апр-25, 11:43

5 лет назад был 2020 год и не 1990 год, ты что-то путаешь.

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

108. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (108), 15-Апр-25, 11:01

Сам перл поддерживает юникод очень и очень давно, возможно раньше, чем многие "прогрессивные" человеки в школу пошли. Другой вопрос - не все модули какого нить спана его нормально поддерживают.

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

111. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (1), 15-Апр-25, 13:34

Значит, так поддерживает. Питон, перл, тикль, добавили юникод все в 1 год, что с того?

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

2. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Жироватт (ok), 14-Апр-25, 10:05

> оформленных не-ASCII символов при помощи оператора "tr/../../".
Не понимаю, почему бы полностью не перейти в каком-нибудь perl 5.70 на 100% работу с юникодом, принудительно переводя файлы в старых кодовых таблицах в их представление на юникоде?
> Не исключается возможность эксплуатации уязвимости для организации выполнения своего кода в системе.
Так уже эксплоит есть, или снова "чисто гипотетически, не исключено, ну, есть вероятность..."?

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

5. "Переполнение буфера в Perl, связанное с обработкой символов" –1 +/–

Сообщение от ИмяХ (ok), 14-Апр-25, 10:15

Эксплоит был написан вместе с этим бекдором и успешно проработал четыре года.

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

13. "Переполнение буфера в Perl, связанное с обработкой символов" –2 +/–

Сообщение от xsignal (ok), 14-Апр-25, 10:43

Потому что бникод не нужен нигде, кроме браузеров.

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

56. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Bottle (?), 14-Апр-25, 12:35

Юникод нужен везде, где есть ещё языки кроме английского.
Делать по кодировке на каждый язык - контроптимальная стратегия, которая приведёт к куче багов.

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

72. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (71), 14-Апр-25, 14:16

Сделать одну кодировку для всех, которую никто не может поддерживать и поэтому плодят кучу багов? Хороший план.

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

86. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (86), 14-Апр-25, 16:49

Кучу разных кодировок все поддерживать тоже не смогут

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

107. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (107), 15-Апр-25, 06:48

> которую никто не может поддерживать
* которую никто не может поддерживать целиком
Эта поправка всё меняет. Используй безопасное-для-твоего-случая подмножество, а не разрешай всё подряд, как в именах файлов в никсах.

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

70. "Переполнение буфера в Perl, связанное с обработкой символов" –1 +/–

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

> Потому что бникод не нужен нигде, кроме браузеров.
Ого, свидетель KOI-8 в треде! НенужОн мне ваш юникод! (с)
А в почтовике юникод тоже не нужен? И в офисном пакете?
Может и в играх не нужен? Смотреть на всякую бнопню так весело!

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

18. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от User (??), 14-Апр-25, 11:11

> Так уже эксплоит есть, или снова "чисто гипотетически, не исключено, ну, есть вероятность..."?
... найти чего-нибудь работающего на perl'е "использующие непроверенные внешние данные в левой части оператора "tr"? Не очень высокая, но есть :)

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

20. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от nuclight (??), 14-Апр-25, 11:13

Смысл? Повторять ошибку питона 2->3 ? Как раз нормально сделано.

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

92. "Переполнение буфера в Perl, связанное с обработкой символов" –1 +/–

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

Ошибку? Господь с Вами! Python 2→3 это лучшее что произошло с питоном, и лучшее что могло бы произойти с кучей других языков копящих вместо этого легаси.

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

95. "Переполнение буфера в Perl, связанное с обработкой символов" –1 +/–

Сообщение от Аноним (1), 14-Апр-25, 18:32

Ошибка тут была не дропнуть любую поддержку старых веток сразу и навсегда (ну может подстелить травки с six всё же правильно).

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

60. "Переполнение буфера в Perl, связанное с обработкой символов" –3 +/–

Сообщение от Xenia Joness (ok), 14-Апр-25, 12:55

Лучше, вместо каких-нибудь perl 5.70, оставить его в покое и перейти на что-нибудь более приличное и современное, чтобы избегать скриптов из хаотично набранных символов.
Что-то не могу припомнить, чтобы в последнее время какие-нибудь новые проекты делали на Perl, и поэтому, внезапно, вопрос. Кто-нибудь использует Perl для работы?  Под работой, полезной, я подразумеваю серьезные проекты, уже выпушенные в продакшен, и приносящие прибыль. Если использовать Perl для запиливания своей версии *тут название вашей супер свободной и быстрой программы с аудиторией в 6 человек*, это в моём понимании полезной работой не считается.

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

61. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (-), 14-Апр-25, 12:58

> Лучше, вместо каких-нибудь perl 5.70, оставить его в покое и перейти на что-нибудь более приличное и современное, чтобы избегать скриптов из хаотично набранных символов.
А какие есть варианты?
Перловку используют чтобы уйти от башизмов и протухших бш-пртянок.
> Под работой, полезной, я подразумеваю серьезные проекты, уже выпушенные в продакшен, и приносящие прибыль.
Т.е 99% СПО выкидывается из списка)))?
> Если использовать Perl для запиливания своей версии *тут название вашей супер свободной и быстрой программы с аудиторией в 6 человек*, это в моём понимании полезной работой не считается.
Ух, классное определение.
Вангую сpaч))

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

87. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (87), 14-Апр-25, 17:19

>протухших бш-пртянок
Разве у Bash ломают обратную совместимость?

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

113. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (86), 15-Апр-25, 17:37

На нём невероятно трудно писать что-то большое по объёму

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

62. "Переполнение буфера в Perl, связанное с обработкой символов" +3 +/–

Сообщение от xsignal (ok), 14-Апр-25, 13:06

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

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

63. "Переполнение буфера в Perl, связанное с обработкой символов" +2 +/–

Сообщение от xsignal (ok), 14-Апр-25, 13:09

> оставить его в покое и перейти на что-нибудь более приличное и современное
А что в Perl'е неприличного и несовременного?

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

65. "Переполнение буфера в Perl, связанное с обработкой символов" –2 +/–

Сообщение от Аноним (-), 14-Апр-25, 13:31

> А что в Perl'е неприличного и несовременного?
Бекдоры которые живут годами?
Хотя может это вполне современно 🤔

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

66. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от xsignal (ok), 14-Апр-25, 13:42

> Бекдоры которые живут годами?
Это какие?

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

102. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Ан Оним (?), 14-Апр-25, 21:48

Ненадёжный синтаксис

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

64. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (64), 14-Апр-25, 13:17

> полезной работой не считается
А что считается полезной работой? То, что приносит прибыль?
За деньги - да!

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

73. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от User (??), 14-Апр-25, 14:37

Ну, глубокое легаси, которое не меняют, по тому, что оно никому вроде как не мешает - есть, и в количествах. Начнет мешать - проще будет переписать на <чем угодно> нежели разбираться\чинить.
Еще вот пенсионерские скрипты вида башпортянка-на-стероидах - обсуждать бессмысленно, помрет вместе с "носителями культуры".
Как-то так.

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

93. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (93), 14-Апр-25, 18:21

> Кто-нибудь использует Perl для работы?  Под работой, полезной, я подразумеваю серьезные проекты, уже выпушенные в продакшен, и приносящие прибыль.
Очевидный booking.com, например. Достаточно серьёзно? Продакшен и прибыль точно есть, я проверил.

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

4. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Fracta1L (ok), 14-Апр-25, 10:12

Хех, да, на генте ~amd64 воспроизводится

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

6. "Переполнение буфера в Perl, связанное с обработкой символов" –2 +/–

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

Это только потому, что ты не удалил его вместе с руби. Чем можно оправдывать тысячи новых перловых пакетов зависимостей в случайном минорном обновлении я не понимаю.

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

12. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от bdrbt (ok), 14-Апр-25, 10:43

>  Чем можно оправдывать тысячи новых перловых пакетов зависимостей в случайном минорном обновлении я не понимаю.
Гента без перла тупо не соберётся.

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

14. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Fracta1L (ok), 14-Апр-25, 10:46

К сожалению, из генты всю эту скриптовую дичь выкинуть невозможно. Я пытался.

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

24. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от 12yoexpert (ok), 14-Апр-25, 11:25

просто перепеши на раст

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

27. "Переполнение буфера в Perl, связанное с обработкой символов" +2 +/–

Сообщение от Аноним (27), 14-Апр-25, 11:32

точнее так
НАЧНИ, переписывать на rust.

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

103. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (103), 15-Апр-25, 03:55

На Си же.

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

23. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (23), 14-Апр-25, 11:24

Выбрал тестовый вариант - страдай.

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

8. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Ivan (??), 14-Апр-25, 10:23

https://ubuntu.com/security/CVE-2024-56406
мне 500ю показывает

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

9. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

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

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

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

15. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от xsignal (ok), 14-Апр-25, 10:48

А они находят ошибки только в сях, а в расте не находят? Это плохо... для раста. Потому что, как известно, в любой программе есть ошибки и если они не обнаруживаются, то тут что-то не так..

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

42. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (42), 14-Апр-25, 12:07

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

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

48. "Переполнение буфера в Perl, связанное с обработкой символов" –2 +/–

Сообщение от Аноним (27), 14-Апр-25, 12:20

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

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

57. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (42), 14-Апр-25, 12:35

> Для минимизации таких ошибок язык должен обладать минимумом синтаксической шелухи.
Для минимазиции ошибок язык должен занимать как можно меньше внимания программиста на всякую ерунду вроде "а изменяет ли эту переменную кто-то еще? а может ли сюда придти null? а что это за void* сюда пришла? я конкотанировал кучу строк, сколько \n мне нужно вычессть из результирующего буфера?" Особенно если продукт больше консольной утилится на 10к строк.
Если внимание тратится на такую фигню, то рано или поздно оно заканчивается. И обычно не вовремя. Как результат, где-то что-то пропускается, не замечается, забывается.

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

98. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (98), 14-Апр-25, 20:44

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

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

46. "Переполнение буфера в Perl, связанное с обработкой символов" –1 +/–

Сообщение от Аноним (46), 14-Апр-25, 12:15

> А они находят ошибки только в сях, а в расте не находят?
проход в раст защитан
> как известно, в любой программе на Си есть ошибки в работе с памятью
исправил. не благодари

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

25. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (23), 14-Апр-25, 11:26

Вы про закрытые двери? Тогда да,но вони про Андроид было много с таким подходом.

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

11. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Анониматор (?), 14-Апр-25, 10:41

proxmox он же дебиан вчера обновил перлы эти ваши

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

110. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Анониматор (?), 15-Апр-25, 12:53

в арч тоже сейчас завезли

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

16. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (16), 14-Апр-25, 10:51

Опять сишка же!
https://github.com/Perl/perl5/commit/87f42aa0e0096e9a346c967...
Даже перловые диды не умеют на сишке кодить, а они же инженеры ого-го!

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

29. "Переполнение буфера в Perl, связанное с обработкой символов" +2 +/–

Сообщение от xsignal (ok), 14-Апр-25, 11:34

Программисты Боинг тоже не умеют кодить - MAXы же падали из-за программной ошибки. Людям вообще свойственно ошибаться и никакой "волшебный язык" этого не изменит.

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

41. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (41), 14-Апр-25, 12:07

> Программисты Боинг тоже не умеют кодить - MAXы же падали из-за программной ошибки.
Ага, особенно если давать задачи по созданию "высоконадежных систем" людям которые этим никтогда не занимались.
И падали они из-за ошибки проектирования железа которую попытались закостылять программно.
Правда учли не все варианты.
> Людям вообще свойственно ошибаться и никакой "волшебный язык" этого не изменит.
Именно! Люди ошибаются. Это факт.
Хуже всего что они ошибаются внезапно.
Поэтому системы взаимодействия с людьми следует делать максимально ошибкоустойчивыми и минимизирующими последствия.
Так появились защитные кожухи на болгарках, пилах и прочем инструменте, двойная изоляция электрики, системы контроля слепых зон, на всяких станках типа прессов - запуск который делается с двух кнопок разнесенных на значительное расстояние (чтобы руку пресс не оттяпал).
В авто появились подушки и ремни - для минимизации потерь при таки произошедшей ошибки.ʼ
На дорогах потоки разделяются отбойниками.
Конечно остаются луддиты и неолуддиты для которых ТБ это ересь, но они довольно часто самовыпиливаются.
ps для не знакомых с математикой мир полон "волшебства")

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

49. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (45), 14-Апр-25, 12:21

>Даже перловые диды не умеют на сишке кодить
Я тебе скажу даже больше (к примеру) - погромисты на 1с массово не умеют в регекспы. Вплоть до тимимдов и нач. департаментов.
Это так, к слову про корректные выборки.

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

17. "Переполнение буфера в Perl, связанное с обработкой символов" –2 +/–

Сообщение от Аноним (17), 14-Апр-25, 10:57

Просто перл писался ненастоящими сишниками. Настоящие сишники такого бы не допустили.

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

31. "Переполнение буфера в Perl, связанное с обработкой символов" +2 +/–

Сообщение от Аноним (27), 14-Апр-25, 11:35

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

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

44. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (-), 14-Апр-25, 12:14

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

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

55. "Переполнение буфера в Perl, связанное с обработкой символов" +2 +/–

Сообщение от Аноним (55), 14-Апр-25, 12:35

Какие желторотики? Karl Williamson второй по активности среди коммитеров в репе перла. Настоящий Си-дед. Неудобно как-то получилось, да?

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

59. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (42), 14-Апр-25, 12:42

> Karl Williamson второй по активности среди коммитеров в репе перла. Настоящий Си-дед.
Прям удар в псину!
> Неудобно как-то получилось, да?
Возможно стоит глянуть его налоговую декларацию за 2021 год.
Вдруг там что-то интересное появилось? В лотерею выиграл. Получил наследство от троюродного дедушки из Латинской Америки.

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

84. "Переполнение буфера в Perl, связанное с обработкой символов" –1 +/–

Сообщение от Аноним (27), 14-Апр-25, 16:34

Первый патч в 2009. Далее по патчу в год.
Полностью включился в 2014.
Perl5 был выпущен в 1994.
Кто он? Если не желторотик?

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

85. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (27), 14-Апр-25, 16:38

Ах, да. Стоит добавить что он включился в разработку после выхода версии 5.20.

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

88. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (88), 14-Апр-25, 17:26

>Первый патч в 2009. Далее по патчу в год.
>Полностью включился в 2014.
>Perl5 был выпущен в 1994.
Ну может быть, 11 лет для тебя - ничего совсем. Ты бы ещё сказал, что и с 1994 года прошло мало годиков.
> Кто он? Если не желторотик?
Он тот, кто активно пилит perl. Он тот, чьим опусом пользуется линукс, и соответственно каждый линуксоид. Как-то гадко называть человека желторотиком, не находишь?

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

90. "Переполнение буфера в Perl, связанное с обработкой символов" –1 +/–

Сообщение от Аноним (27), 14-Апр-25, 17:45

> Как-то гадко называть человека желторотиком, не находишь?
Это эмоции. Реальность от наличия эмоций не изменится. Perl был разработан другими людьми. И стал популярен благодаря другим людям.
В какой-то момент он потерял популярность. И вот тогда пришло новое поколение. Желторотиков.
Результатом их трудов стало отсутствие языка в рейтингах.

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

94. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

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

> Perl был разработан другими людьми. И стал популярен благодаря другим людям.
Погоди, перловку создал Ларри Уолл.
И что интересно он сам забросил 4ю версию и начал делать пятую.
> В какой-то момент он потерял популярность.
Интересно почему)
> И вот тогда пришло новое поколение.
> Результатом их трудов стало отсутствие языка в рейтингах.
А...
1. Т.е он потерял популярность.
2. Потом пришло новое поколение.
3. И теперь они виноваты, что ЯП нет в рейтингах?
У тебя какая-то странная логика.
Если он потерял популярность до прихода "нового поколения" то они явно в этом не виноваты.
Ну или это типичное стариковое "во всем виновата молодежь"

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

100. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (100), 14-Апр-25, 21:24

>Результатом их трудов стало отсутствие языка в рейтингах
Главное верить и тогда никакая реальность не страшна 👍

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

89. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (-), 14-Апр-25, 17:34

> Первый патч в 2009. Далее по патчу в год.
И? патчи бывают разные.
> Perl5 был выпущен в 1994.
От 1994 до 2009 - 15 лет.
От 2009 до 2025 - 16.
> Кто он? Если не желторотик?
Чел, который больше половины жизни пятой перловки отправляет туда патчи)
У которого почти 8к коммитов и его обганяет только один человек с 9 тысячами.
Который уже блин седой местами.
Не, это таки тот самый сишный дед.
Который просто решил "нафига проверять, я же профи. давайте сэкономим пару тактов процессора" и сделал CVE.
Классическая ситуация.

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

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

Сообщение от Аноним (27), 14-Апр-25, 17:47

Еще раз и медленно.
Он пришел после версии 5.20
В тот момент когда perl стал мало кому интересен. С тех пор ситуация стала только хуже.
То есть он пришел в умирающий проект и помогает ему умирать.

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

30. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (30), 14-Апр-25, 11:35

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

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

50. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (45), 14-Апр-25, 12:26

Ты же в курсе, что изучив только синтаксис BASH, ты рискуешь остаться в уголке, потому что оно ПОЧЕМУ ТО не работает на ванильном SH - "несовместимо".
Это как изучить синтаксис какой нибудь zsh или fish, а потом обнаружить, что все твои скрипты надо переписывать... ))

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

104. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (103), 15-Апр-25, 03:59

Где ты видел ванильный sh последние лет 15?
Даже в ретроградских openbsd, solaris, Android, и, прости Господи, interix, по умолчанию ksh, а bash легко ставится.

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

54. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (54), 14-Апр-25, 12:31

Perl по сравнению с Bash - эталон ясности, если только специально не запутывать код.

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

96. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (1), 14-Апр-25, 19:01

Баш последователен, если выкинуть из него совместимость с 50 летними скриптами.

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

35. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от xsignal (ok), 14-Апр-25, 11:57

Как говорил Глеб Жеглов - "Правопорядок в стране определяется не наличием воров, а умением властей их обезвреживать!" Ошибки были, есть и будут всегда. То, что их находят - замечательно! Разработчики Perl умеют их обезвреживать и Perl становится только лучше. А много ли ошибок находят в Rust-коде?..

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

38. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (42), 14-Апр-25, 12:04

> Глеб Жеглов
Мда... ну у тебя и пример конечно... Хотя для тебя ничего удивительного.
> А много ли ошибок находят в Rust-коде?..
А раст то тут причем???

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

40. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Соль земли (?), 14-Апр-25, 12:06

Если исправлять ошибки в корне, то и искать их не нужно. Пора бы уже развиваться.

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

43. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (42), 14-Апр-25, 12:10

> уязвимость возникла после добавленного в 2020 году изменения,
> убирающего дополнительную проверку достаточного выделения
> памяти под предлогом того, что при расчёте размера можно
> обойтись округлением размера в большую сторону.
Это восхититительно!
Обосновать закладку оптимизацией.
И главное что все согласились и ее получилось протолкнуть!
"Сишники дуреют с этой прикормки" (с)
Ну что, сэкономили пару тактов процессора?))

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

51. "Переполнение буфера в Perl, связанное с обработкой символов" +1 +/–

Сообщение от Аноним (17), 14-Апр-25, 12:26

Настоящий сишник добавляет проверки, только если есть CVE, обосновывающий необходимость проверки. Этот подход называется CVE Oriented Programming. Это объясняет, почему именно си-код генерит такое количество CVE (C Vulnerabilities and Exposures).

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

105. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (103), 15-Апр-25, 04:04

Ты так написал, как будто это что-то плохое.
Если никому не мешает, то зачем лишний код добавлять.

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

58. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (55), 14-Апр-25, 12:40

Да закоммитил один из основных разработчиков, он сам с собой согласился и одобрил.

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

53. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (53), 14-Апр-25, 12:29

Проверил на debian testing воспроизводится:
```
root@testing:~# cat /etc/debian_version
trixie/sid
root@testing:~# uname -a
Linux testing.local 6.12.21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.21-1 (2025-03-30) x86_64 GNU/Linux
root@testing:~# perl -e '$_ = "\x{FF}" x 1000000; tr/\xFF/\x{100}/;'
Segmentation fault
root@testing:~# perl -v
This is perl 5, version 40, subversion 1 (v5.40.1) built for x86_64-linux-gnu-thread-multi
(with 42 registered patches, see perl -V for more detail)
```
на stable -- нет:
```
root@stable:~# cat /etc/debian_version
12.10
root@stable:~# uname -a
Linux stable.local 6.12.21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.21-1 (2025-03-30) x86_64 GNU/Linux
root@stable:~# perl -e '$_ = "\x{FF}" x 1000000; tr/\xFF/\x{100}/;'
root@stable:~# perl -v
This is perl 5, version 36, subversion 0 (v5.36.0) built for x86_64-linux-gnu-thread-multi
(with 54 registered patches, see perl -V for more detail)
```

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

115. "Переполнение буфера в Perl, связанное с обработкой символов" +/–

Сообщение от Аноним (115), 15-Апр-25, 20:11

> Проблема проявляется в стабильных релизах Perl начиная с 2021 года
"Обновляйтесь", - говорили они...

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

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

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

Партнёры:

Хостинг:

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

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

1. "Переполнение буфера в Perl, связанное с обработкой символов"	–13 +/–
Сообщение от Аноним (1), 14-Апр-25, 10:04
Странно, что перл вообще поддерживает юникод. Это слишком прогрессивно для него, ну и вот видим, к чему это приводит.
Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Переполнение буфера в Perl, связанное с обработкой символов"	+11 +/–
	Сообщение от nuclight (??), 14-Апр-25, 11:12
	Лучше всех поддерживает и очень давно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Переполнение буфера в Perl, связанное с обработкой символов"	–3 +/–
	Сообщение от Аноним (1), 14-Апр-25, 14:38
	Да видим, как он поддерживает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	75. "Переполнение буфера в Perl, связанное с обработкой символов"	–2 +/–
	Сообщение от Аноним (75), 14-Апр-25, 14:51
	Так давно, что в те времена не было смешанной кодировки или коллектив был не в курсе такой возможности?
	Ответить \| Правка \| К родителю #19 \| Наверх \| Cообщить модератору


	22. "Переполнение буфера в Perl, связанное с обработкой символов"	+9 +/–
	Сообщение от 12yoexpert (ok), 14-Апр-25, 11:23
	любая последовательность символов в любой кодировке является валидным perl6 кодом
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	36. "Переполнение буфера в Perl, связанное с обработкой символов"	+/–
	Сообщение от Соль земли (?), 14-Апр-25, 12:00
	и лишней возможностью запустить что-то случайное
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Переполнение буфера в Perl, связанное с обработкой символов"	+1 +/–
	Сообщение от Аноним (45), 14-Апр-25, 12:14
	Не спешите так господа, я только-только перевел энтерпрайзы с 4 стабильного перла.
	Ответить \| Правка \| К родителю #22 \| Наверх \| Cообщить модератору


	71. "Переполнение буфера в Perl, связанное с обработкой символов"	+/–
	Сообщение от Аноним (71), 14-Апр-25, 14:14
	Юникод для всех слишком прогрессивен. Нет ни одной библиотеки которая без проблем бы его полностью поддерживала. Пока люди пользуются юникодом, ни о какой безопасности не может быть речи (подмножества юникода вполне нормально используются).
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	106. "Переполнение буфера в Perl, связанное с обработкой символов"	+1 +/–
	Сообщение от Аноним (106), 15-Апр-25, 06:26
	2025 году отрицать Юникод так же дико, как верить в то, что Земля плоская. Такие разговоры были актуальны ещё 5 лет назад, но не сегодня. Вы смешны.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	109. "Переполнение буфера в Perl, связанное с обработкой символов"	+/–
	Сообщение от Аноним (1), 15-Апр-25, 11:43
	5 лет назад был 2020 год и не 1990 год, ты что-то путаешь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	108. "Переполнение буфера в Perl, связанное с обработкой символов"	+/–
	Сообщение от Аноним (108), 15-Апр-25, 11:01
	Сам перл поддерживает юникод очень и очень давно, возможно раньше, чем многие "прогрессивные" человеки в школу пошли. Другой вопрос - не все модули какого нить спана его нормально поддерживают.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	111. "Переполнение буфера в Perl, связанное с обработкой символов"	+/–
	Сообщение от Аноним (1), 15-Апр-25, 13:34
	Значит, так поддерживает. Питон, перл, тикль, добавили юникод все в 1 год, что с того?
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Переполнение буфера в Perl, связанное с обработкой символов"	+/–
Сообщение от Жироватт (ok), 14-Апр-25, 10:05
> оформленных не-ASCII символов при помощи оператора "tr/../../". Не понимаю, почему бы полностью не перейти в каком-нибудь perl 5.70 на 100% работу с юникодом, принудительно переводя файлы в старых кодовых таблицах в их представление на юникоде? > Не исключается возможность эксплуатации уязвимости для организации выполнения своего кода в системе. Так уже эксплоит есть, или снова "чисто гипотетически, не исключено, ну, есть вероятность..."?
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Переполнение буфера в Perl, связанное с обработкой символов"	–1 +/–
	Сообщение от ИмяХ (ok), 14-Апр-25, 10:15
	Эксплоит был написан вместе с этим бекдором и успешно проработал четыре года.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Переполнение буфера в Perl, связанное с обработкой символов"	–2 +/–
	Сообщение от xsignal (ok), 14-Апр-25, 10:43
	Потому что бникод не нужен нигде, кроме браузеров.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	56. "Переполнение буфера в Perl, связанное с обработкой символов"	+1 +/–
	Сообщение от Bottle (?), 14-Апр-25, 12:35
	Юникод нужен везде, где есть ещё языки кроме английского. Делать по кодировке на каждый язык - контроптимальная стратегия, которая приведёт к куче багов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	72. "Переполнение буфера в Perl, связанное с обработкой символов"	+/–
	Сообщение от Аноним (71), 14-Апр-25, 14:16
	Сделать одну кодировку для всех, которую никто не может поддерживать и поэтому плодят кучу багов? Хороший план.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	86. "Переполнение буфера в Perl, связанное с обработкой символов"	+1 +/–
	Сообщение от Аноним (86), 14-Апр-25, 16:49
	Кучу разных кодировок все поддерживать тоже не смогут
	Ответить \| Правка \| Наверх \| Cообщить модератору


	107. "Переполнение буфера в Perl, связанное с обработкой символов"	+1 +/–
	Сообщение от Аноним (107), 15-Апр-25, 06:48
	> которую никто не может поддерживать * которую никто не может поддерживать целиком Эта поправка всё меняет. Используй безопасное-для-твоего-случая подмножество, а не разрешай всё подряд, как в именах файлов в никсах.
	Ответить \| Правка \| К родителю #72 \| Наверх \| Cообщить модератору


	70. "Переполнение буфера в Perl, связанное с обработкой символов"	–1 +/–
	Сообщение от Аноним (-), 14-Апр-25, 14:14
	> Потому что бникод не нужен нигде, кроме браузеров. Ого, свидетель KOI-8 в треде! НенужОн мне ваш юникод! (с) А в почтовике юникод тоже не нужен? И в офисном пакете? Может и в играх не нужен? Смотреть на всякую бнопню так весело!
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	18. "Переполнение буфера в Perl, связанное с обработкой символов"	+/–
	Сообщение от User (??), 14-Апр-25, 11:11
	> Так уже эксплоит есть, или снова "чисто гипотетически, не исключено, ну, есть вероятность..."? ... найти чего-нибудь работающего на perl'е "использующие непроверенные внешние данные в левой части оператора "tr"? Не очень высокая, но есть :)
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	20. "Переполнение буфера в Perl, связанное с обработкой символов"	+/–
	Сообщение от nuclight (??), 14-Апр-25, 11:13
	Смысл? Повторять ошибку питона 2->3 ? Как раз нормально сделано.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	92. "Переполнение буфера в Perl, связанное с обработкой символов"	–1 +/–
	Сообщение от Аноним (92), 14-Апр-25, 18:14
	Ошибку? Господь с Вами! Python 2→3 это лучшее что произошло с питоном, и лучшее что могло бы произойти с кучей других языков копящих вместо этого легаси.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	95. "Переполнение буфера в Perl, связанное с обработкой символов"	–1 +/–
	Сообщение от Аноним (1), 14-Апр-25, 18:32
	Ошибка тут была не дропнуть любую поддержку старых веток сразу и навсегда (ну может подстелить травки с six всё же правильно).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	60. "Переполнение буфера в Perl, связанное с обработкой символов"	–3 +/–
	Сообщение от Xenia Joness (ok), 14-Апр-25, 12:55
	Лучше, вместо каких-нибудь perl 5.70, оставить его в покое и перейти на что-нибудь более приличное и современное, чтобы избегать скриптов из хаотично набранных символов. Что-то не могу припомнить, чтобы в последнее время какие-нибудь новые проекты делали на Perl, и поэтому, внезапно, вопрос. Кто-нибудь использует Perl для работы? Под работой, полезной, я подразумеваю серьезные проекты, уже выпушенные в продакшен, и приносящие прибыль. Если использовать Perl для запиливания своей версии тут название вашей супер свободной и быстрой программы с аудиторией в 6 человек, это в моём понимании полезной работой не считается.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	61. "Переполнение буфера в Perl, связанное с обработкой символов"	+1 +/–
	Сообщение от Аноним (-), 14-Апр-25, 12:58
	> Лучше, вместо каких-нибудь perl 5.70, оставить его в покое и перейти на что-нибудь более приличное и современное, чтобы избегать скриптов из хаотично набранных символов. А какие есть варианты? Перловку используют чтобы уйти от башизмов и протухших бш-пртянок. > Под работой, полезной, я подразумеваю серьезные проекты, уже выпушенные в продакшен, и приносящие прибыль. Т.е 99% СПО выкидывается из списка)))? > Если использовать Perl для запиливания своей версии тут название вашей супер свободной и быстрой программы с аудиторией в 6 человек, это в моём понимании полезной работой не считается. Ух, классное определение. Вангую сpaч))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	87. "Переполнение буфера в Perl, связанное с обработкой символов"	+1 +/–
	Сообщение от Аноним (87), 14-Апр-25, 17:19
	>протухших бш-пртянок Разве у Bash ломают обратную совместимость?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	113. "Переполнение буфера в Perl, связанное с обработкой символов"	+/–
	Сообщение от Аноним (86), 15-Апр-25, 17:37
	На нём невероятно трудно писать что-то большое по объёму
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Переполнение буфера в Perl, связанное с обработкой символов"	+3 +/–
	Сообщение от xsignal (ok), 14-Апр-25, 13:06
	Perl активно используется во многих проектах, например, ядро Linux. Но это не тот язык, исключительно на котором пишут некие "серьезные проекты, уже выпушенные в продакшен". Это утилитарный язык, с помощью которого осуществляется поддержка функционирования и разработки на других языках, поэтому он не очень заметен. Например, в моих рабочих проектах используется регрессионная система автотестирования на Perl.
	Ответить \| Правка \| К родителю #60 \| Наверх \| Cообщить модератору


	63. "Переполнение буфера в Perl, связанное с обработкой символов"	+2 +/–
	Сообщение от xsignal (ok), 14-Апр-25, 13:09
	> оставить его в покое и перейти на что-нибудь более приличное и современное А что в Perl'е неприличного и несовременного?
	Ответить \| Правка \| К родителю #60 \| Наверх \| Cообщить модератору