| |
| 2.2, мяв (?), 12:01, 25/07/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
хотелось бы видеть поддержку tcb в glibc. в мусле она, например, есть. в бузибоксе пока нет, правда.
как и защиту аллокатора, как в мусле. у них оно mallocng называлется(или называлось). чтото между стандартным маллоком и hardened от графенос
| | |
| |
| 3.3, мяв (?), 12:02, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– |
tcp - это типа того, что поттеринг хотел в своем homed, со своим passwd для каждого юзера.
| | |
|
| 2.19, Аноним (19), 13:33, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– |
Было бы что осиливать, а вот трейдоф производительности не подходит большинству пользователей -- как ни крути. Ну и безопасность, в мусле вечно уязвимости уровня выполнение кода в printf. Из положительного разве что более компактные бинари, особенно, если встройка. Только вот совпадение, после перехода на мусл openwrt сразу перестал помещаться -- могли и на глибц мигрировать тогда уж.
| | |
| 2.40, Аноним (40), 16:12, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– |
Операционная система GNU/Linux на базе musl должна работать медленее чем Glibc. Маленькие бинарники на означают, что система станет работать автоматически быстрее.
| | |
|
| 1.4, Аноним (4), 12:03, 25/07/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
одну gethostbyaddr д0лбанную функцию никак не могут написать корректно.
| | |
| |
| 2.5, Аноним (5), 12:32, 25/07/2026 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Как говорил классик: "Довольно пустой болтовни! Покажите ваш код!"
В ответе ожидается ссылка на репозитории с вашими проектами.
| | |
| |
| 3.23, Аноним (4), 13:47, 25/07/2026 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> "Довольно пустой болтовни! Покажите ваш код!"
вот щас выну и покажу.
> В ответе ожидается ссылка на репозитории с вашими проектами.
наивный какой, лопух? :)
| | |
|
| |
| 3.10, Аноним (5), 12:46, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Я не спросил, что за ней скрывается)
Я попросил ВАШУ реализацию gethostbyaddr, которую ВЫ смогли реализовать)
Чтобы оценить, что лично ВЫ можете и в какой форме)
Вдруг вы тот самый герой, кто напишет все и вся с первого раза без багов и ошибок)
| | |
| |
| 4.24, Аноним (4), 13:48, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Я попросил ВАШУ реализацию gethostbyaddr, которую ВЫ смогли реализовать)
спеку в студию и увидишь код!
| | |
|
| |
| |
| |
| 6.36, llolik (ok), 14:46, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– |
 > Там ещё десятка два RFC сверху навалено, если не больше.
Ну я про сопутствующие об этом и имел в виду.
| | |
|
| 5.34, Аноним (4), 14:43, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– |
Это не спека!!! Это рекомендации!!! Там максимум спека самого протокола может быть, а спеки по имплементации нет, только рекомендации!!!
| | |
| |
| 6.37, llolik (ok), 14:49, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Это не спека!!! Это рекомендации!!! Там максимум спека самого протокола может быть,
> а спеки по имплементации нет, только рекомендации!!!
А ты имплементировать dns-резолвер будешь как-то отлично от протокола и рекомендаций стандарта? Что он отрезолвит в таком случае?
| | |
| |
| 7.38, Аноним (4), 15:07, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> А ты имплементировать dns-резолвер будешь как-то отлично от протокола и рекомендаций стандарта? Что он отрезолвит в таком случае?
Рекомендация в RFC - не спецификация! Спецификация - это четкое описание и доказательство корректности.
По ссылке все подробности
//inbox.sourceware.org/libc-alpha/20260320194250.1089143-1-carlos@redhat.com/
"""
The answer section boundary was previously ignored, and the code in
getanswer_ptr would iterate past the last resource record, but not
beyond the end of the returned data. This could lead to subsequent data
being interpreted as answer records, thus violating the DNS
specification. Such resource records could be maliciously crafted and
hidden from other tooling, but processed by the glibc stub resolver and
acted upon by the application. While we trust the data returned by the
configured recursive resolvers, we should not trust its format and
should validate it as required. It is a security issue to incorrectly
process the DNS protocol.
The processed hostname in getanswer_ptr should be correctly checked to
avoid invalid characters from being allowed, including shell
metacharacters. It is a security issue to fail to check the returned
hostname for validity.
These two issues are considered distinct CVEs, but are fixed in one
commit to make the update process easier, given that they change the
same file and function.
Regression tests are added for invalid metacharacters and response
section crossing.
"""
| | |
|
|
|
|
|
| 2.32, Ivan_83 (ok), 14:28, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– |
 Чувак, ты сам то осиль DNS хотя бы без рекурсера и кеша, потом поговорим.
| | |
| |
| 3.35, Аноним (4), 14:46, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Чувак, ты сам то
Чувак, если у тебя не получается - не парь пятую точку, зачем ты это продолжаешь делать? Тебе посчитать, сколько в этой гр3банной функции найдено багов со времен придумывания протокола днс?
> потом поговорим.
Я тебе в каждой новости про баги в gethostbyaddr буду напоминать!
| | |
|
|
| 1.6, openssh_user (ok), 12:33, 25/07/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > CVE-2026-4046 - аварийное завершение приложений, использующих функцию iconv(), при перекодировании специально оформленных данных в кодировках IBM1390 и IBM1399
Зачем эти legacy кодировки нужны?
| | |
| |
| |
| 3.41, Аноним (41), 17:57, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– |
Это понятно. Удивляет то, что в 2026 году где-то могут храниться данные в кодировках IBM1390, IBM1399. И которые надо преобразовать в читаемый вид.
| | |
|
|
| 1.9, Аноним (9), 12:45, 25/07/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Это хорошо конечно что работают над улучшением базовой библиотеки, плохо когда у тебя полностью настроенная среда разработки с собранными либами из исходников, специфичными инструментами которые требуют свежей glibc после обновления, а этот дистрибутив уже не обновляется. Приходится выкручиваться и решать вопросы с glibc.
Потом аноним все же разобрался с этими вот требованиями свежей glibc для рабочих инструментов.
| | |
| |
| 2.13, Аноним (9), 12:58, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– |
И как то, Аноним случайно узнал что под Windows нет glibc.
Нет glibc - нет проблем.
Такая вот история со счастливым финалом.
| | |
| |
| 3.17, llolik (ok), 13:27, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> И как то, Аноним случайно узнал что под Windows нет glibc.
UCRT (MSVCRT ранее) куда-то подевался чтоли?
| | |
| |
| |
| 5.22, llolik (ok), 13:46, 25/07/2026 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Он ничего не говорил про либц, у тебя всё хорошо?
Всё тоже самое, что написано в стартовом сообщении, характерно и для UCRT. Да и вообще для любого libc (не только glibc).
| | |
| |
| 6.29, Аноним (19), 14:14, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– |
Да, всё ПО для венды собирали 15 летним вдк как раз чтобы была совместимость. Но речь была о глибц, у неё нет такого готового дистрибутива для сборки.
| | |
| 6.42, Аноним (42), 18:44, 25/07/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Всё тоже самое, что написано в стартовом сообщении, характерно и для UCRT
Нет, "нужен свежий libc, а дистр не обновляется" - это сугубо линуксячья проблема, и к Винде (у которой лучшая обратная совместимость среди всех ОС) с ее UCRT отношения никакого не имеет.
| | |
|
|
|
|
|
|
