После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library (glibc) 2.33, которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2017. В состав нового выпуска включены исправления от 72 разработчиков...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54508
Список уязвимостей намекает на правоту доводов тех, кто остаётся на простых 8-битных кодировках. 20 лет уже прошло с повального перехода на Unicode, а всё те же детские проблемы продолжают всплывать и конца этому не видно.
CVE-2019-25013 очень нехорошие впечатления производит, как бы не всплыл эксплоит, позволяющий атаковать любые приложения, вызывающие iconv. Год в CVE тоже напрягает. Они два года не исправляли баг или держали в секрете информацию о дыре?
О чем ты через юникод символы даже айфоны атаковали, вплоть до перезагрузки при получении символа. А Эплу прям не все равно на такие уязвимости. А тем кто делает iconv им то точно пофиг.
Очевидно, на EUC-KR всем более-менее класть.
Вместо программистов деньги надо платить тестировщикам. Программисты не нужны. Нужны тестировщики, которые будут тестировать выход из нейросетей.
А исправит всё это дед Михалыч.
Нейросеть пусть исправляет за что ей деньги платять... ой, то есть электричество тратят.
Скайнет получится, но потом. А пока посмотрите фильм, сценарий для которого написала нейросеть. Бессмысленная бессмыслица.
> Скайнет получится, но потом. А пока посмотрите фильм, сценарий для которого написала нейросеть. Бессмысленная бессмыслица.Просто примитивные мешки с мясом не способны постигнуть грандиозный замысел.
Ты так пишешь как будто скайнет это что-то плохое.
слава роботам!!!!
УВЧ !
Неизбежны только сметь и налоги (на роботов ;) !
Чем тупее программисты, тем нужнее тестировщики.
Не верно. Тупой прогер будеи больше времени фиксить баги. Умный - больше пилить фичи, производя новые баги.
Пару лет назад десяточка сразу улетала в бсод при открытии текстового файла с utf-8 в notepad++ и некоторых других программах. Этот utf-8 был корректный на линуксе, но некорректный на венде и макос. Такие вот детские проблемы у неё, 30 лет уже тащат.
А что, в Винде преобразования кодировок выполняются в ядре, что от их проблем в BSOD?
> А что, в Винде преобразования кодировок выполняются в ядре, что от их
> проблем в BSOD?Надо было создать такой файл ещё, но мне к тому времени уже надоело перезагружаться и я сохранил тот файл в utf-16 -- с ней проблем не возникло. А потом и вовсе выкинул венду из процесса.
Зказошник, однако
> Зказошник, однакоЯ сам был в шоке от такого бага, но это в целом типичный уровень венды.
Интероперабельность ваших 100500 простых 8-битных кодировок где-то у плинтуса. Не пойдёт.
Ещё лучше выкинуть компьютеры. Тогда точно никаких уязвимостей не будет.
>реализована поддержка загрузки оптимизированных реализацийо-о-о-о. о-о-о-о! теперь можно забыть про VectorAngles_SSE, VectorAngles_3DNOW, VectorAngles_AVX и выбор VectorAngles = кому-то из них? Ну, круто, чо. Джвадцать лет ждал.
>В Linux прекращена корректировка прав доступа к устройствам терминала силами Glibc. Администраторам теперь нужно следить за режимом доступа к /dev/pts самостоятельноНи дня без хипстеров и их модой выпиливать "устаревшие" технологии.
А зачем системе делать двойную работу?
Зачем тогда нужна система, если у неё даже банального резервирования функционала нет?
[анекдот про три билета и проездной]
Затем, чтобы каждая её составная часть занималась своим делом.
Чем оно лучше musl и uClibc?
тем, что классика
Так понимаю даже если доплатить, ничего не будет?
Ну все, ждет glibc на расте!
Сравнение: http://www.etalabs.net/compare_libcs.html
Сравнение от разрабов musl? Ню-ню
Ну хоть какое-то. Давай другое.
Т.е. для операция c UTF надо использовать musl, а для всего остального достаточно Glibc? Звучит как мегавелосипед, надо попробовать.
https://git.musl-libc.org/cgit/libc-bench/
CFLAGS = -O3 -march=native -mtune=native
У меня вот так:
glibc 2.32-5
b_malloc_sparse (0)
time: 0.024667712, virt: 38992, res: 38980, dirty: 38980b_malloc_bubble (0)
time: 0.015058248, virt: 39364, res: 39240, dirty: 39240b_malloc_tiny1 (0)
time: 0.000589027, virt: 688, res: 568, dirty: 568b_malloc_tiny2 (0)
time: 0.001705194, virt: 688, res: 568, dirty: 568b_malloc_big1 (0)
time: 0.006052890, virt: 160, res: 36, dirty: 36b_malloc_big2 (0)
time: 0.002650046, virt: 80192, res: 8044, dirty: 8044b_malloc_thread_stress (0)
time: 0.007435453, virt: 16808, res: 156, dirty: 156b_malloc_thread_local (0)
time: 0.003369966, virt: 16808, res: 172, dirty: 172b_string_strstr ("abcdefghijklmnopqrstuvwxyz")
time: 0.007469129, virt: 160, res: 24, dirty: 20b_string_strstr ("azbycxdwevfugthsirjqkplomn")
time: 0.008151978, virt: 160, res: 24, dirty: 20b_string_strstr ("aaaaaaaaaaaaaacccccccccccc")
time: 0.003106639, virt: 160, res: 24, dirty: 20b_string_strstr ("aaaaaaaaaaaaaaaaaaaaaaaaac")
time: 0.003298937, virt: 160, res: 24, dirty: 20b_string_strstr ("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac")
time: 0.004199191, virt: 160, res: 24, dirty: 20b_string_memset (0)
time: 0.002559836, virt: 160, res: 24, dirty: 20b_string_strchr (0)
time: 0.001449032, virt: 160, res: 24, dirty: 20b_string_strlen (0)
time: 0.001225345, virt: 160, res: 24, dirty: 20b_pthread_createjoin_serial1 (0)
time: 0.052410040, virt: 8352, res: 28, dirty: 28b_pthread_createjoin_serial2 (0)
time: 0.040370453, virt: 32928, res: 52, dirty: 52b_pthread_create_serial1 (0)
time: 0.040070966, virt: 40820, res: 10724, dirty: 10724b_pthread_uselesslock (0)
time: 0.018573501, virt: 8352, res: 28, dirty: 28b_pthread_createjoin_minimal1 (0)
time: 0.055794819, virt: 8356, res: 28, dirty: 28b_pthread_createjoin_minimal2 (0)
time: 0.080734030, virt: 32944, res: 52, dirty: 52b_utf8_bigbuf (0)
time: 0.014984457, virt: 292, res: 168, dirty: 168b_utf8_onebyone (0)
time: 0.060253994, virt: 292, res: 168, dirty: 168b_stdio_putcgetc (0)
time: 0.030089557, virt: 160, res: 24, dirty: 20b_stdio_putcgetc_unlocked (0)
time: 0.021394856, virt: 160, res: 24, dirty: 20b_regex_compile ("(a|b|c)*d*b")
time: 0.004064140, virt: 292, res: 172, dirty: 172b_regex_search ("(a|b|c)*d*b")
time: 0.002545791, virt: 292, res: 172, dirty: 172b_regex_search ("a{25}b")
time: 0.031420295, virt: 292, res: 228, dirty: 228musl 1.2.2, скомпилированная с -O3 -march=native -mtune=native
b_malloc_sparse (0)
time: 0.018086124, virt: 8472, res: 8472, dirty: 8472b_malloc_bubble (0)
time: 0.029208808, virt: 148, res: 84, dirty: 84b_malloc_tiny1 (0)
time: 0.000815813, virt: 24, res: 24, dirty: 24b_malloc_tiny2 (0)
time: 0.000590137, virt: 620, res: 600, dirty: 600b_malloc_big1 (0)
time: 0.009659560, virt: 16, res: 16, dirty: 16b_malloc_big2 (0)
time: 0.007070165, virt: 87396, res: 16064, dirty: 13044b_malloc_thread_stress (0)
time: 0.026452695, virt: 52, res: 52, dirty: 52b_malloc_thread_local (0)
time: 0.021053161, virt: 84, res: 84, dirty: 84b_string_strstr ("abcdefghijklmnopqrstuvwxyz")
time: 0.004645396, virt: 8, res: 8, dirty: 8b_string_strstr ("azbycxdwevfugthsirjqkplomn")
time: 0.005817365, virt: 8, res: 8, dirty: 8b_string_strstr ("aaaaaaaaaaaaaacccccccccccc")
time: 0.004017669, virt: 8, res: 8, dirty: 8b_string_strstr ("aaaaaaaaaaaaaaaaaaaaaaaaac")
time: 0.004091413, virt: 8, res: 8, dirty: 8b_string_strstr ("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac")
time: 0.004958556, virt: 8, res: 8, dirty: 8b_string_memset (0)
time: 0.001293495, virt: 8, res: 8, dirty: 8b_string_strchr (0)
time: 0.004946605, virt: 8, res: 8, dirty: 8b_string_strlen (0)
time: 0.004114283, virt: 8, res: 8, dirty: 8b_pthread_createjoin_serial1 (0)
time: 0.054616411, virt: 8, res: 8, dirty: 8b_pthread_createjoin_serial2 (0)
time: 0.045479414, virt: 8, res: 8, dirty: 8b_pthread_create_serial1 (0)
time: 0.040029458, virt: 50008, res: 10008, dirty: 10008b_pthread_uselesslock (0)
time: 0.014679810, virt: 8, res: 8, dirty: 8b_pthread_createjoin_minimal1 (0)
time: 0.059266487, virt: 8, res: 8, dirty: 8b_pthread_createjoin_minimal2 (0)
time: 0.039402904, virt: 8, res: 8, dirty: 8b_utf8_bigbuf (0)
time: 0.010321686, virt: 8, res: 8, dirty: 8b_utf8_onebyone (0)
time: 0.020891645, virt: 8, res: 8, dirty: 8b_stdio_putcgetc (0)
time: 0.039510467, virt: 8, res: 8, dirty: 8b_stdio_putcgetc_unlocked (0)
time: 0.033731822, virt: 8, res: 8, dirty: 8b_regex_compile ("(a|b|c)*d*b")
time: 0.017231408, virt: 36, res: 24, dirty: 24b_regex_search ("(a|b|c)*d*b")
time: 0.013933366, virt: 12, res: 12, dirty: 12b_regex_search ("a{25}b")
time: 0.038705624, virt: 12, res: 12, dirty: 12
Тем, что оно работает, в отличие от?
Это утверждение или вопрос?
А как лучше всего засанитайзить юникод ? Ну чтоб и набор стандартных буковок был для языков не затронут.
> набор стандартных буковокЭто каких? Что такое «стандартные буковки»? Ты в курсе, что бывает не только латиница и русская кириллица, но еще с десяток кириллиц, два десятка латиниц, а так же греческий, грузинский, армянский и прочие алфавиты, которые в разы старше той же кириллицы и вполне живы и используются?
Потому и спрашиваю о наличии готового решения.
Что ты имеешь в виду под "засанитайзить"? Простейшая валидация сводится к тому, чтобы разбить поток байт на char'ы таким образом, чтобы:а. если старший первого байта 0, то это однобайтовый чар
б. если старшие биты первого байта 10, то это двухбайтовый чар, и следующий байт должен иметь 10 в старших двух битах
в. если старшие биты первого байта 110, то это трёхбайтовый чар, и следующие 2 байта должны иметь 10 в старших двух битах
г. если старшие биты первого байта 1110, то это четырёхбайтовый чар, и следующие 3 байта должны иметь 10 в старших двух битах.
д. если мы добрались до сюда, значит пора запускать процесс обработки ошибки InvalidUTF8.Все "стандартные буковки" попадают в пункт (а), и они не будут затронуты, потому как старший бит у них 0.
По идее, в любой строковой библиотеке работающей с юникодом такая валидация должна быть, и сводится к вызову функции. Это гарантирует валидность кодирования, но какие-то из чаров прошедших таким образом проверку могут быть неопределены. Если тебе это важно, то надо таскать с собой таблички валидных чаров, и по ним ещё проверять.
Если же тебе хочется справляться с ошибками, то заменяй все байты, которые не удалось декодировать на '?', и всё. Будет по-уродски, но тут всё просто: нефиг инвалидный utf8 пихать в программу, и не будет уродства.
> Что ты имеешь в виду под "засанитайзить"Опасные диапазоны для всяких имен и неожиданные кавычки с прочими неожиданно "поддерживаемыми" ништяками для фс, баз, жысоноф и всей такой фигни
>> Что ты имеешь в виду под "засанитайзить"
> Опасные диапазоны для всяких имен и неожиданные кавычки с прочими неожиданно "поддерживаемыми"
> ништяками для фс, баз, жысоноф и всей такой фигниАнрил. Обезопасить строку от всего-всего-всего -- это анрил. Либо поумерить хотелки и широту покрываемых санитайзером кейсов, либо ограничивать допустимые чары предикатом is_ascii_alphanumeric. Под любое послабление этого предиката можно придумать кейс, когда это приведёт к беде. Хотя даже так плохо -- если оно иногда alpha, а иногда numeric, то какой-нибудь библиотеке в программе может сорвать крышу, когда она, скажем, напорется на 0xfffffffffffffffffffffffffffffffffff, ей переполнит 128 битный целочисленный тип, и хрен её знает, что она сделает дальше. Начнёт читать последующие буквы как хекскод, чтобы записать его на стек, включить исполняемость стека и сделать call %esp? От программистов и их программ никогда не знаешь чего ожидать.
Что-то такое и "Ну чтоб и набор стандартных буковок был для языков не затронут.". У меня вот с лингвистрисизмусомством полная беда, может быть есть готовые решения какбы.
Это вы про utf8, но кроме нее есть еще четыре -- utf{16|32}{b|l}
И в довесок к этому каждая может имет, а может и не иметь сигнатуру в начале файла. Итого 10 вариантов.
Мало того, вдобавок к этим десяти есть овердофига разных 8-байтных кодировок. Попробуй сразу разберись, что перед тобой.
> Это вы про utf8, но кроме нее есть еще четыре -- utf{16|32}{b|l}
> И в довесок к этому каждая может имет, а может и не
> иметь сигнатуру в начале файла. Итого 10 вариантов.
> Мало того, вдобавок к этим десяти есть овердофига разных 8-байтных кодировок. Попробуй
> сразу разберись, что перед тобой.Нахрен они нужны, если есть utf8? utf8 лучше всех подходит как транспортная кодировка, и я рекомендую класть на все остальные с прибором.
Грамотно!
Неа, неграмотно. Я там напутал с первыми байтами, там должны быть значения 110..., 1110..., 11110..., чтобы взяв произвольный байт из потока можно было бы определить, является ли он первым байтом чара или байтом-продолжением (байт-продолжение выглядит как 10...). Я не люблю править уже написанные сообщения, считая что сказанное должно оставаться сказанным, и поэтому ждал когда мне укажут на косяк, чтобы довести до завершения, но никто не указал. И я забыл об этом.
Во, хоть кто-то не гонится, высунув язык, за нумерацией вида 100500.
Ну всё же, к нумерациям вида 3.x уже перейти можно.
Вот это криворукие у glibc программисты, если на прекрасном Си допускают переполнение буфера. Это же банальнейшая вещь, с которой справится любой джун из комментов Опеннета.
Язык тебя никак не защитить от кривых рук. Так зачем использовать другой язык если дело в руках?
Вот я и говорю - даже в glibc не нашлось кодеров с прямыми руками. Потому что все они в комментах Опеннета обитают.
Просто чтобы ты понял Раст не нужен. А ты обычный фанбой, который скоро закончит школу и забудет про это всё.
А у тебя прямые руки?
> А у тебя прямые руки?Нет, и растут из нижних полушарий мозга.
Зачем добавлять синхронизатор в кп авто, нужны просто прямые руки. Зачем изолировать провода, только рукожоп может дотронуться до оголенного. Зачем закрывать шестерни станка щитком, только криворукий сможет туда сунуть свои рученки.Зачем писать нормальные структуры данных, которые будут хранить не только указатель на буфер, но и его длину. Давайте лучше будем сами вычислять в десятке мест, причем без проверок - так же быстрее. А... где-то добавили или вычли лишнюю единицу... Ну, с кем не бывает.
Так оно что с проверкой крашнулось бы, что без - в обоих случая это баг и надо исправлять.
При крэше вы хоть узнаете что что-то пошло не так.
А если мы выходили за пределы массива (строка напр.) и там по счастливой случайности всего был \0, то об этом узнают только когда там окажется что-то другое.
Да, можно санитайзер включить, погонять прогу и отловить краши. Даже на сях без проверок. Нужно ли чтобы санитайзер был встроен в язык и не отключался - спорный вопрос. Свобода выбора средств есть и это хорошо.
> Зачем закрывать шестерни станка щитком, только криворукий сможет туда сунуть свои рученки.Если продолжать аналогию, то проверка с выбрасыванием необработанного исключения - это не щиток поставить в месте, куда руки совать не следует, а казнить на месте за неправильные действия.
Не обязательно бросать исключение. Можно вернуть ошибку (хотя бы int или bool, если язык не дает ничего более вменяемого типа optional или tuple).
Плюс в некоторых случаях намного лучше чтобы программа просто упала, чем выдала неверный результат.Главное чтобы нужно было проверять ограниченное количество мест внутри объекта чтобы минимизировать (не полностью исключить, а уменьшить шанс на пару порядков) вероятность ошибки. И покрыть тестами один объект существенно легче чем кучу кода.
> Не обязательно бросать исключение. Можно вернуть ошибку (хотя бы int или bool,
> если язык не дает ничего более вменяемого типа optional или tuple).Можно. Но тогда придётся работать учётом того, что функция может не вернуть ожидаемый результат, а это уже проверки и обработка возможной ошибки по сути, что по трудозатратам не сказать что меньше ручной проверки выхода за пределы массива.
> Плюс в некоторых случаях намного лучше чтобы программа просто упала, чем выдала
> неверный результат.да
> Главное чтобы нужно было проверять ограниченное количество мест внутри объекта чтобы минимизировать
> (не полностью исключить, а уменьшить шанс на пару порядков) вероятность ошибки.
> И покрыть тестами один объект существенно легче чем кучу кода.Одну сишную ни от чего не зависящую функцию покрыть тестами ничуть не сложнее, чем на любом другом языке.
> Зачем писать нормальные структуры данных,Вот и не надо , если тебе надо - сделай но только для себя. А лучше иди вон раст учи.
Кривая и косая дрель рано или поздно запорет высверливание правильной и ровной дырки. Так что си -- кривой инструмент, для использования которого приходится искривлять мозги и руки прогерам. Отсюда и кривопопие, конца которому не видать.
Си просто повторяет архитектуру компьютера. Ты лучше, скажи инженерам Интела и АМД что у них компьютеры кривые.Си такой, потому-что компьютеры такие. Ну, что дошло?
Жду, когда арчик пересоберут хотя бы под x86-64-v2. Нужно больше оптимизаций под современные процессоры.
Лучше будет если сразу для x86-64-v4. Для Арчевода ты какой-то консервативный.
Есть Garuda Linux с кучей ядер, скомпилированных под определённый процессор.
У меня, например, Artix с подключенными репами chaotic-aur.
Чего и всем арчеводам желаю.
Кстати, из ожидания подобных уязвимостей, мы в blists, когда добавляли туда поддержку iconv, разрешили только реально сколько-нибудь распространенные кодировки. Их список оказался не таким уж маленьким, но пока пересечения с перечисленными в новости нет:
https://github.com/openwall/blists/blob/99ca31b9ac49429c114a...
Ой, китайские это очень зря. Японские я бы тоже запретил. И хинди с ивритской вязью (чисто на всякий случай). Просто из-за того как они устроены и потому, что в юникоде они имеют платформозависимые символы (ты декодируешь на линуксе и у тебя всё нормально, а потом оказывается, что все приложения на венде крашатся, да и сама она в бсод улетает).
Может и зря, но они реально встречались в недавних сообщениях в списках рассылки по Linux и Open Source, и после их разрешения корректно отображались в браузере (в utf-8, под Linux). Не хотелось искусственно ломать то что иначе просто работает.
> при наличии /dev/ptmx считают псевдо-ФС devpts примонтированной к /dev/ptsЭэээ... это "считают" вызывает у меня тревожные мысли. Когда код "считает", вместо того, чтобы честно вывалиться в ошибку - это чревато, ящетаю.
ну ОК, а как собрать его с оптимизацией для конкретного железа?
Сейчас сыпит ошибками "ISA not compatible" и т.д.
Добавить libc_cv_include_x86_isa_level=no
> Добавлен новый режим защиты "_FORTIFY_SOURCE=3", предназначенный для определения во время компиляции и во время работы возможных переполнений буфераЖдем поддержки в gcc и добавляем в make.conf
CFLAGS= .... -D_FORTIFY_SOURCE=3